Dr.Who
← blog

Self-signed certificate browser warning: how to fix it properly

· tls · ssl · certificates · self-signed · acme

tlssslcertificatesself-signedacme

A browser shows a warning like NET::ERR_CERT_AUTHORITY_INVALID because a self-signed certificate chains to no trusted certificate authority — it vouches only for itself, so the client cannot verify who it is talking to. The proper fix depends on the audience: for anything reachable on the public internet, replace it with a free, automatically-issued CA certificate (Let's Encrypt or any ACME provider); for internal-only services, add the certificate or your private root CA to the device trust store instead. Clicking "proceed anyway" is never the fix.

Why the warning happens

TLS clients trust a certificate only if it builds a chain up to a CA already in their trust store. A self-signed cert is its own issuer, so there is no chain to a trusted root:

openssl x509 -in cert.pem -noout -subject -issuer
subject= CN = internal.example.com
issuer=  CN = internal.example.com

When subject and issuer are identical and that CN is not a trusted root, the client refuses the cert. This is distinct from an incomplete chain, where the certificate is from a real CA but the server forgot to send the intermediate — that produces a different error and a different fix (send the missing intermediate, not a new cert).

The right fix for public services: ACME

For any host the public can reach, get a real CA certificate. Domain-validated certificates from Let's Encrypt and other ACME CAs are free and fully automatable, so there is no reason to ship self-signed in production. A typical issuance:

certbot certonly --webroot -w /var/www/html -d example.com -d www.example.com

ACME clients renew automatically (Let's Encrypt certs last 90 days), so once configured the warning is gone for good and you never touch it manually. Make sure the server then sends the full chain — leaf plus intermediates — to avoid the incomplete-chain problem above.

The right fix for internal-only services

When a service is genuinely internal (a lab box, an appliance, a private CI host) and cannot get a public DV cert, do not click through — install trust explicitly:

  • Run a small internal CA (an offline root + an issuing intermediate), and distribute the root certificate to every device's trust store via MDM, group policy, or a config-management tool.
  • Then issue normal leaf certs from that internal CA. Browsers trust them because they now chain to a root the device trusts.
  • Avoid distributing bare self-signed leaf certs per-host; a single trusted internal root scales far better.

Never train users to bypass warnings

The one fix to rule out is teaching people to ignore the warning. A click-through habit destroys the only signal that distinguishes a misconfiguration from an active man-in-the-middle. Fix the trust path — a real CA outside, your own root inside — so the warning means something again.

Check what your server is presenting →

Further reading