SSL error: how to find the cause and fix it

Published Sources checked By helps.wiki editorial team

An "SSL error" means your browser or tool could not validate the server's certificate, or the secure handshake did not finish. As a visitor, check the device clock, try another network and update your system. If you run the site, the usual culprits are a missing intermediate certificate, an expired certificate, or a name that the certificate does not cover.

Applies to:Chrome, Edge, Firefox, Safaricurl and other API clientsnginx
On this page

What it means

"SSL error" is a broad label, not one fault. SSL is the old name for what is now called TLS, the layer that encrypts a connection and proves the server is who it claims to be. When the client cannot check that proof, or the handshake cannot complete, you get an error.

Chrome's generic "Your connection is not private" page says the problem could be with the site, the network, or your device. The specific code on the page (for example NET::ERR_CERT_DATE_INVALID) tells you which, so read it before trying anything.

The first three fixes below are for people visiting a site. The rest are for whoever manages the server, with nginx examples. If the error appears on a streaming stick, see SSL certificate error on Fire TV Stick.

Symptoms and causes

You are likely dealing with this problem if:

  • Chrome shows NET::ERR_CERT_AUTHORITY_INVALID, NET::ERR_CERT_DATE_INVALID or NET::ERR_CERT_COMMON_NAME_INVALID.
  • curl or another OpenSSL-based tool reports "unable to get local issuer certificate", "unable to verify the first certificate", "certificate has expired" or "self-signed certificate".
  • The site opens in a browser but fails in curl or an API client.
  • nginx refuses to start with "SSL_CTX_use_PrivateKey_file(...) failed ... key values mismatch".

The usual causes, most common first:

Incomplete certificate chain on the server
The server sends its own certificate but not the intermediate one. Browsers sometimes cope because they cache intermediates, while curl and other clients fail. Let's Encrypt names this as the most common cause on modern platforms.
Expired certificate or wrong clock
A missed renewal, or a device whose date and time are wrong. OpenSSL compares the certificate's validity dates with the system time.
Self-signed or untrusted issuer
The certificate is self-signed or issued by a CA the client does not trust. This also happens when a proxy, corporate filter or antivirus re-signs HTTPS traffic. OpenSSL trusts a self-signed certificate only if it is in the trust store.
Outdated trust store on the client
An old device or OS may not know the root certificate the site depends on.
Hostname mismatch
The address you typed is not covered by the names in the certificate, which produces the COMMON_NAME_INVALID family of errors.
nginx file mistakes
The certificate file was joined in the wrong order, or the private key does not belong to that certificate.

How to fix it

Work through these in order. They start with the quickest, safest checks and move to deeper repairs; stop as soon as the problem is gone.

1.Check the device date, time and time zone

Easy

Certificates are valid only between two dates, so a wrong clock makes a good certificate look expired or not yet valid.

  1. Open your system's date and time settings.
  2. Turn on automatic date and time, and confirm the time zone is correct.
  3. Restart the browser and reload the page.

2.Try another network and look for HTTPS interception

Easy

If the error disappears on a different network or device, something between you and the site (a proxy, corporate filter or security software that re-signs traffic) is replacing the certificate.

Before you start: If you briefly turn off HTTPS scanning in third-party security software to test, turn it back on straight afterwards.

  1. Load the same page on mobile data or another Wi-Fi network.
  2. If it works there, check your security software or work/school network settings, or ask the network administrator.
  3. Do not click through the warning. Chrome states that only the site owner can fix a problem on the site's side.

3.Update the operating system and browser

Easy

Trusted root certificates ship with the OS and the browser, and Let's Encrypt documents that some of its roots are trusted only from specific OS and browser releases.

  1. Install pending operating system updates.
  2. Update your browser to the latest version and reload the page.

4.Inspect what the server really sends

Moderate

This shows whether the intermediate certificate is missing, the most common server-side cause, and which certificate is served for the name you use.

  1. From any machine with OpenSSL, connect to the site, replacing the host name in both places. The -servername option sends the name you want, so a server hosting several sites returns the right certificate. </dev/null makes the command exit instead of waiting for input.
    Terminal
    openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null
  2. Look at the Certificate chain section. Entry 0 is the server certificate. If it is the only entry, the intermediate is missing.
  3. Find the Verify return code line near the end of the output. 0 (ok) means the chain verified; any other value comes with a short reason that points to the problem.
  4. For a second opinion, run the SSL Labs Server Test, which Let's Encrypt recommends for chain problems.

5.Build the chained certificate file in nginx

ModerateChanges settings

nginx sends only what is in the file you point it to, so the server certificate must come first, followed by the CA bundle.

Before you start: Keep a copy of the current certificate files and nginx configuration before changing them.

  1. Join the server certificate and the CA bundle, in that order.
    Terminal
    cat www.example.com.crt bundle.crt > www.example.com.chained.crt
  2. Point the server block at the chained file and the matching key.
    nginx.conf
    ssl_certificate     www.example.com.chained.crt;
ssl_certificate_key www.example.com.key;
  3. Test the configuration, then reload nginx the way you normally do on your system.
    Terminalneeds sudo / root
    nginx -t

6.Fix a hostname mismatch (COMMON_NAME_INVALID)

Moderate

The certificate lists the names it is valid for, and the address in the browser must be one of them. A certificate for example.com does not automatically cover www.example.com, or the other way round.

  1. Check which names the certificate covers. Open the certificate details in the browser, or print the names with OpenSSL.
    Terminal
    openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName
  2. If you only mistyped the address, use a name that appears in that list.
  3. If you manage the site, ask your CA to reissue the certificate with every name visitors use as a subject alternative name (SAN), including both www.example.com and the bare example.com.
  4. Install the new certificate, test the configuration with nginx -t, reload, and check again with the command above.

7.Replace or properly trust a self-signed or private-CA certificate

AdvancedChanges settings

A self-signed certificate, or one issued by a private CA, fails on every client that does not have that certificate or CA in its trust store.

Before you start: Back up the current certificate and key before replacing them. Never use curl -k or similar switches as the fix, because they turn verification off.

  1. For a public site, replace the certificate with one from a publicly trusted CA, then install it with its full chain (see the chain fix above).
  2. For internal use, keep the private CA and install its root certificate on each client that must trust it, using that system's certificate import tools.
  3. For a single curl command or script, point curl at the CA certificate file instead of disabling checks.
    Terminal
    curl --cacert /path/to/internal-ca.pem https://intranet.example.com/
  4. If the issuer shown is your security software or a work proxy, the certificate is being re-signed on the way. Follow the network steps earlier or contact the administrator.

8.Fix a "key values mismatch" error

ModerateChanges settings

nginx will not start if the private key does not belong to the certificate, or if the certificate file is in the wrong order.

Before you start: Do not paste or share the private key anywhere. Back up the files before replacing them.

  1. Confirm the server certificate is the first certificate in the file you configured.
  2. Compare the public key derived from the certificate with the one derived from the private key. This works for both RSA and ECDSA keys. The two outputs must be identical.
    Terminal
    openssl x509 -noout -pubkey -in www.example.com.crt
openssl pkey -pubout -in www.example.com.key
  3. For RSA keys only, the older modulus comparison also works (nginx describes it as supplementary). The two hashes must match.
    Terminal
    openssl x509 -noout -modulus -in www.example.com.crt | openssl md5
openssl rsa -noout -modulus -in www.example.com.key | openssl md5
  4. If they differ, you have the wrong key or certificate. Use the matching pair, then run nginx -t and reload. This check is only for nginx's key mismatch error, and it has no bearing on Chrome's COMMON_NAME_INVALID error, which is a name problem.

9.Renew an expired certificate

ModerateChanges settings

An expired certificate fails on every client, whatever the chain looks like.

Before you start: Back up the current certificate and key before replacing them.

  1. Check the expiry date of the certificate the server presents, using the openssl s_client output or the SSL Labs report.
  2. Renew or reissue the certificate with your CA, and install it together with its chain.
  3. Test the configuration with nginx -t, reload the server, then recheck the site.

Check that it worked

  • The page opens in the browser without a certificate warning.
  • openssl s_client shows the server certificate plus its intermediate in the Certificate chain section, and Verify return code is 0 (ok).
  • curl and other API clients connect without a verification error.
  • nginx -t reports the configuration is fine and the server starts.

If it still fails

  • Note the exact error code or message, because each points to a different cause. Search for that code on its own.
  • If the error appears only on a work or school network, contact its administrator about HTTPS inspection.
  • If you manage the server, rerun the SSL Labs Server Test and read its chain and name findings.
  • Handshake failures such as protocol or cipher mismatch and client-certificate (mutual TLS) setups are not covered here. Check your server software's documentation for those.

Questions

Can I just click through the warning?

Not as a fix. Chrome says only the site owner can resolve a problem on the site's side, and continuing means the connection is not verified.

Should I use curl -k to get past the error?

No. It switches off verification and hides the real problem. Fix the chain or trust issue instead.

Why does the site work in my browser but fail in curl?

That pattern typically means the server omits the intermediate certificate, which browsers can sometimes work around and other clients cannot.

Sources

  1. Fix "Your connection is not private" (Chrome Help)Official · Google
  2. Configuring HTTPS serversOfficial · nginx.org
  3. Certificate CompatibilityOfficial · Let's Encrypt
  4. openssl-verification-optionsOfficial · OpenSSL

Browse