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 Invalid (a "Security problem") 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 and warn visitors away. Self-signed certs are fine for local development, but never for a public-facing site. The good news: swapping in a real, free certificate takes only a few minutes.

This is the more severe cousin of an untrusted certificate authority: both are trust-chain problems, but a self-signed cert has no chain to a CA at all, whereas an untrusted-root cert has a chain that just doesn't reach a root browsers recognise, most often because an intermediate certificate is missing from the server. If your issuer= and subject= differ, you're looking at that problem, not this one.

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. Open the site in DomainDash. It re-checks the certificate on its normal schedule, so once your real cert is live the SSL check returns to Valid on its own within a check cycle. There's nothing to click. (If the site is still in setup, you can use Retry checks to run it immediately.)

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