Common Certificate Errors & Fixes

Certificate errors are among the most common issues in production deployments. Each error maps to a specific misconfiguration. Below are the errors you will encounter most frequently, along with their root causes and practical fixes.

ERR_CERT_AUTHORITY_INVALID

What It Means

The client cannot build a chain from the server certificate to a trusted root CA. The signing authority is not recognized.

Common Causes

• Self-signed certificate not installed in the client trust store.
• Missing intermediate certificate in the server's TLS configuration.
• Internal CA root not distributed to client machines.

How to Fix

Ensure the server sends the complete chain (leaf + all intermediates). For self-signed or internal CA certs, install the root CA in the client's trust store. On Linux, add it to /usr/local/share/ca-certificates/ and run update-ca-certificates.

ERR_CERT_DATE_INVALID

What It Means

The certificate is outside its validity window — either not yet valid or expired.

Common Causes

• Certificate expired and was not renewed.
• Server clock is wrong (NTP not configured).
• Certificate Not Before date is in the future (deployment before cert becomes valid).

How to Fix

Renew the certificate. Automate renewal with certbot or ACME clients. Verify server time with timedatectl and ensure NTP is running.

ERR_CERT_COMMON_NAME_INVALID / Hostname Mismatch

What It Means

The hostname the client connected to does not match any name in the certificate's Subject Alternative Name (SAN) extension.

Common Causes

• Certificate was issued for www.example.com but the client connects to example.com.
• Connecting via IP address but the SAN only contains DNS names (no IP SAN).
• Certificate uses only the Subject CN without a SAN extension (deprecated behavior).

How to Fix

Reissue the certificate with the correct SANs covering all hostnames and IP addresses clients use to connect. For wildcard certs, remember that *.example.com does not match example.com itself.

UNABLE_TO_VERIFY_LEAF_SIGNATURE

What It Means

The TLS library (often Node.js or OpenSSL) cannot verify the leaf certificate's signature against any known CA.

Common Causes

• Intermediate certificate not included in the server response.
• Node.js using its bundled CA list, which may differ from the OS trust store.

How to Fix

Ensure the server sends the full chain. In Node.js, you can set NODE_EXTRA_CA_CERTS to include additional CA certificates. In .NET's HttpClient, use HttpClientHandler.ServerCertificateCustomValidationCallback for diagnostics (not to skip validation).

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

What It Means

The client and server cannot agree on a TLS version or cipher suite.

Common Causes

• Server only supports TLS 1.0/1.1, which modern browsers have disabled.
• Certificate key type incompatible with configured cipher suites (e.g., ECDSA cert with RSA-only ciphers).
• Server configured with export-grade or obsolete ciphers only.

How to Fix

Enable TLS 1.2 and TLS 1.3 on the server. Use Mozilla's SSL Configuration Generator to select appropriate cipher suites. Verify with openssl s_client -connect host:443.

NET::ERR_CERT_REVOKED

What It Means

The certificate has been revoked by its issuing CA, typically via OCSP or CRL.

Common Causes

• The private key was compromised and the CA revoked the certificate.
• The certificate was mis-issued and revoked by the CA.
• Organization requested revocation (e.g., domain transfer).

How to Fix

A revoked certificate cannot be un-revoked. Request a new certificate from your CA. If you suspect key compromise, generate a new key pair before requesting the replacement.

openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null | \
  openssl x509 -noout -text