Self-signed certificate

Your site is serving an SSL certificate that signed itself rather than being issued by a trusted certificate authority. Browsers reject these for any public-facing site.

Symptom

• DomainDash marks the SSL check as Down with error code self_signed
• Visitors see a browser warning like "Your connection is not private" or NET::ERR_CERT_AUTHORITY_INVALID
• Running openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject shows the same value for both issuer and subject

What it means

SSL certificates are normally issued by a certificate authority (CA) — a trusted third party that vouches for your identity. A self-signed certificate is one where the server issued the certificate to itself. There's nothing technically wrong with the certificate's cryptography, but browsers have no way to verify the server is who it claims to be, so they refuse to trust it. Self-signed certs are fine for local development, but never for production.

Common causes

• A dev/staging certificate leaked into production. Local development tools (mkcert, openssl req -x509, vite preview defaults) often generate self-signed certs that someone copied to production by accident.
• A default fallback certificate is serving. Your web server has a hard-coded default ("snake oil") cert that responds when no proper cert is configured for the hostname being requested.
• Your reverse proxy or load balancer is terminating TLS with a default cert because the real certificate hasn't been uploaded or attached.
• A new server was provisioned and the SSL automation hasn't run yet, so the placeholder cert is still in place.
• The renewer or provisioner failed silently and a previous self-signed cert is still being served.

How to fix

1. Confirm it's self-signed. Run:

   openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject

   If issuer= and subject= are identical, the cert is self-signed.

2. For Let's Encrypt with certbot, issue a real certificate:

   sudo certbot --nginx -d example.com -d www.example.com

   (Replace --nginx with --apache if you use Apache.) Reload the web server after.

3. For hosted providers, open the SSL/TLS section of the dashboard and trigger certificate provisioning for your custom domain. This typically takes a few minutes.

4. Check your web server config to find where the self-signed cert is being served. For nginx:

   sudo nginx -T | grep -E "ssl_certificate|server_name"

   Replace any reference to a self-signed cert file (often named default.pem, snakeoil.pem, localhost.pem) with the path to your real certificate.

5. If you can't immediately replace the cert (e.g. you need it briefly for an internal-only environment), at minimum stop the public DNS pointing at it so visitors aren't sent to it.

How to verify

1. Re-run the issuer/subject check from step 1. The issuer= should now reference a real CA (Let's Encrypt, DigiCert, Sectigo, etc.) and differ from the subject.
2. Open the site in an incognito window. The padlock should appear cleanly.
3. Click "Check now" in DomainDash. Status should flip to Healthy.

Related

• Certificate signed by an untrusted authority — similar trust issue with a different cause
• Hostname doesn't match certificate — the wrong cert may be serving entirely
• Visitors see a security warning — symptom-driven entry point
• SSL certificates — how DomainDash checks SSL