Fix SSL Certificate Errors Guide

What Causes NET::ERR_CERT_AUTHORITY_INVALID SSL Errors?

NET::ERR_CERT_AUTHORITY_INVALID appears when the browser cannot build a trusted path from your certificate to a root it trusts. The most common cause is a missing intermediate certificate, so check what your server actually sends. A self-signed certificate or a certificate from a private CA the browser does not know produces the same error.

Root Cause Analysis

A server must send its own (leaf) certificate plus the intermediate certificates that connect it to a trusted root. If it sends only the leaf, some clients cannot complete the trust path and show the error.

See what the server sends with OpenSSL:

openssl s_client -connect example.com:443 -servername example.com

The "Certificate chain" section lists each certificate the server sent, numbered from 0. Each certificate's issuer (i:) should be the subject (s:) of the next one. If only certificate 0 appears, the server is sending no intermediates. Add -showcerts to print the certificates themselves. Browsers that have seen the intermediate before may cache it, so one browser can work while another fails, which is why this test matters.

For background on what each browser message means, see what an SSL error is and how to fix it. Get the missing intermediates from the issuing authority; they usually come as a "bundle" file with the certificate.

Use SSL Checker for a quick check of a public site's certificate, and the OpenSSL commands here for chain details.

Impact on Site Uptime

Browsers block or warn when they cannot validate a certificate, so for visitors the site is unavailable even though the server is running. Test the affected URL in a browser and with openssl s_client to find out which certificate is wrong.

Administrators can correct the served certificate bundle in the web server's certificate configuration (see "Chain Order Importance" below). Check the configuration before reloading, for example with nginx -t.

How Do Name Mismatch Errors Arise in SSL Certificates?

Name mismatch errors occur when the requested hostname is not covered by the certificate. Check www, non-www and other names actually used by visitors, along with SNI configuration.

Domain Variant Checks

A certificate covering example.com does not necessarily cover www.example.com. List the names in the certificate (the Subject Alternative Name list) and compare them with every hostname your visitors use:

openssl x509 -noout -text -in certificate.crt | grep -A1 "Subject Alternative Name"

When you request a certificate, include every name the service uses as a SAN, such as example.com and www.example.com. Some CAs add the www variant automatically; check the issued certificate to be sure.

A wildcard such as *.example.com matches one level only. It covers www.example.com but not a.b.example.com, and it does not cover the bare example.com unless that name is listed too.

Use DNS Checker to confirm each hostname resolves to the server you think is presenting the certificate. A name that points at the wrong host will show that host's certificate.

SNI lets the client send the hostname it wants during TLS negotiation. Without it, a server with several certificates on one IP address can only present its default certificate.

SNI Configuration Fixes

SNI supports different certificates for hostnames that share an address. In nginx, give each site its own server block with its own server_name, ssl_certificate and ssl_certificate_key. Without a match, nginx presents the default server's certificate. To check that your nginx build supports SNI, run nginx -V and look for "TLS SNI support enabled". To see which certificate a given hostname gets, request it by name:

openssl s_client -connect 203.0.113.10:443 -servername www.example.com

Test the hostname visitors request, including redirects and domain variants, and verify the certificate each returns. If SNI is not an option, a certificate that lists every hostname in its SAN list, or a separate IP address per site, are the alternatives.

What Defines an Incomplete Certificate Chain in SSL Setup?

An incomplete chain is missing certificates needed to establish a trust path, usually the intermediate between your leaf certificate and the root. Check which certificates the server sends with openssl s_client -connect host:443 and add the missing intermediates in the right order.

Chain Order Importance

Leaf certificates connect through intermediates to a trusted authority. The order in your certificate file matters: the server's own certificate comes first, followed by the CA's bundle of intermediates.

For nginx, concatenate the certificate and the bundle, then point ssl_certificate at the combined file:

cat www.example.com.crt bundle.crt > www.example.com.chained.crt

server {
    listen              443 ssl;
    server_name         www.example.com;
    ssl_certificate     www.example.com.chained.crt;
    ssl_certificate_key www.example.com.key;
}

If the files are concatenated in the wrong order, nginx fails to start with key values mismatch, because it tries to match the private key against the first certificate in the file, which is then not your server certificate.

For Apache 2.4.8 and later, put the intermediates in the SSLCertificateFile itself, leaf first, then intermediates. SSLCertificateChainFile is deprecated.

SSLCertificateFile    "/path/server-with-intermediates.crt"
SSLCertificateKeyFile "/path/server.key"

A missing intermediate is a configuration problem, and it can hide behind browsers that cache intermediates. After fixing the file, run openssl s_client again and confirm the intermediates appear.

Validation Tools

SSL Monitoring checks the certificate with a real TLS connection: expiry, whether the chain is trusted, and whether it matches the hostname. An incomplete or untrusted chain fails that check. It does not audit protocols or ciphers, so use a separate tool for those.

Qualys SSL Labs tests a public server's certificate, protocol support, key exchange and cipher strength and gives a grade from A+ to F. An incomplete certificate chain limits the grade to B, and an untrusted certificate gets a "T".

To verify a chain locally, give OpenSSL the root as trusted and the intermediate as untrusted:

openssl verify -CAfile root.pem -untrusted intermediate.pem leaf.pem

Read the actual result: OK means the leaf chains to the root through the intermediate you supplied. Obtain the required chain from the issuing authority and configure renewal tooling for the server.

How to Detect SSL Certificate Expiry Before It Causes Errors?

Monitor certificate expiry and renewal failures. Monitoring tools send reminders before the expiry date; check which reminder days each service uses and change them if you need more warning.

Expiry Alert Thresholds

UptimeRobot's SSL certificate monitoring is on paid plans only. Its default reminders are 30, 14, 7 and 1 days before expiry, and you can change them. Its free plan covers 50 monitors at 5-minute checks. A paid Solo plan starts at $13/month ($12 billed annually) for 10 monitors with 60-second checks.

A failed renewal can leave a certificate approaching expiry without anyone noticing, so an external reminder is a useful backstop.

Visual Sentinel's Solo plan starts at $15/month with 10 monitors. Uptime checks run every 5 minutes on Solo and Starter, and every minute on Business and Agency. Expiry reminders default to 13, 3 and 1 days before expiry, with optional 20- and 6-day reminders.

See Uptime Monitoring for how the certificate check runs with each uptime check.

Automated Renewal Strategies

Most Certbot installations come with automatic renewal already set up. A scheduled job runs certbot renew, which usually does nothing until a certificate is due, so it is normally run twice a day. Since Certbot 4.0.0 a certificate is renewed when less than a third of its lifetime remains; before that the threshold was a fixed 30 days.

A renewed certificate only helps if the server loads it. Use a deploy hook to reload the web server after a successful renewal, and test the setup with a dry run:

sudo certbot renew --deploy-hook "systemctl reload nginx"
sudo certbot renew --dry-run

Automation can renew certificates, but inspect failures and confirm the renewed certificate is the one being served.

Which SSL Protocols Trigger Compatibility Errors?

Clients that only speak SSL 3.0, TLS 1.0 or TLS 1.1 fail against a server that has disabled those protocols, and you should disable them. RFC 8996 says TLS 1.0 and TLS 1.1 must not be used, and RFC 7568 says the same for SSL 3.0. Use TLS 1.2 as the minimum and TLS 1.3 where available.

Protocol Disablement Steps

In nginx, set the protocols explicitly:

ssl_protocols TLSv1.2 TLSv1.3;

nginx's documented default for ssl_protocols is TLSv1.2 TLSv1.3 (TLSv1.3 has been in that default since 1.23.4), so check what your version and distribution use.

On Windows Server, protocols are controlled by Schannel settings under HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols, for example TLS 1.0\Server, where a DWORD value Enabled of 0 disables the version. Microsoft recommends using Group Policy or other Windows tools instead of editing the registry directly when you can. Validate changes with the clients that must connect, and restart the application or service so it picks them up.

Use Website Checker for availability. Use a separate TLS test, such as SSL Labs, to see the protocols and ciphers a server offers.

Cipher Suite Recommendations

Cipher suites decide how the connection is encrypted. In nginx the default is ssl_ciphers HIGH:!aNULL:!MD5, which keeps the strong suites and excludes suites without authentication and MD5-based suites.

ssl_ciphers HIGH:!aNULL:!MD5;

SSL Labs scores cipher strength by averaging the strongest and weakest ciphers a server offers, so removing weak suites raises the grade.

Test compatibility on the clients the service needs to support. If a client fails with a TLS error, check the exact error: it usually names the protocol or cipher it could not agree on.

How to Verify Private Key Matches SSL Certificate?

A certificate only works with the private key it was issued for. Compare the public key in the certificate with the public key derived from the private key; a mismatch stops the server from establishing TLS connections.

OpenSSL Command Walkthrough

For an RSA key, compare the modulus of the certificate and the key. openssl x509 -noout -modulus -in certificate.crt prints the modulus of the certificate's public key, and openssl rsa -noout -modulus -in private.key prints the key's. The two outputs must match exactly.

openssl x509 -noout -modulus -in certificate.crt | openssl sha256
openssl rsa  -noout -modulus -in private.key     | openssl sha256

Piping to openssl sha256 gives short hashes that are easy to compare. For any key type, including EC keys, compare the public keys instead:

openssl x509 -noout -pubkey -in certificate.crt | openssl sha256
openssl pkey -pubout -in private.key            | openssl sha256

If the hashes differ, the certificate was issued for a different key. Use the key that matches, or reissue the certificate from a new certificate signing request generated from the key on the server. Use a key type and size supported by the deployment.

Server-Specific Fixes

nginx reports key values mismatch when the certificate and key do not belong together or when the bundle was concatenated in the wrong order (see "Chain Order Importance"). Check the certificate binding for the requested hostname and port on the actual server.

Use nginx -t to test the configuration before reloading, and read the nginx error log, commonly at /var/log/nginx/error.log, for the exact message.

On servers with a management interface, such as IIS, rebind the certificate to the site and port using the server's management tools, then check that the service answers on that binding.

What Steps Fix Common SSL Certificate Errors on Servers?

Match the fix to the error: add the missing intermediates for an authority-invalid error, request a certificate that lists the right names for a name mismatch, renew an expired certificate, or install the matching key for a key mismatch. Then confirm the result with a certificate check.

Reinstallation Process

Install the server certificate and required intermediates in one file, leaf first, using the issuer's bundle and your server's certificate configuration.

Include every hostname you serve when requesting the certificate, such as example.com and www.example.com as SANs. Verify the issued names.

Renew expired certificates with the configured renewal client. Check the reload hook and the certificate subsequently served.

Visual Sentinel supplies scheduled certificate-validity and expiry checks.

Post-Fix Validation

Run openssl s_client -connect host:443 -servername host after changes and check the chain. Run an SSL Labs test to check chain, protocols and ciphers.

Visual Monitoring compares screenshots of your pages, which is a separate check from the certificate.

Check the connection result and the server logs for the hostname you fixed.

How Do SSL Monitoring Tools Compare for Error Detection?

Visual Sentinel provides scheduled certificate checks: expiry, trust chain and hostname. UptimeRobot's certificate monitoring is on its paid plans. Pingdom (SolarWinds) offers a free trial and, per our comparison page, starts at $16.50 a month per product on annual billing. The table compares Visual Sentinel with UptimeRobot.

See Pricing for current Visual Sentinel plans.

What Role Does Visual Sentinel Play in SSL Troubleshooting?

Visual Sentinel checks the certificate your server presents with each uptime check: expiry, whether the chain is trusted, and whether it matches the requested hostname. It detects expired certificates, hostname mismatches, and trust failures such as a self-signed or incomplete chain, and it records the issuer, subject, validity dates and fingerprint so you can see when the certificate changes. It does not do cipher or revocation checks and is not a protocol audit, and it cannot tell you whether your private key matches.

Setup for Web Admins

Add the site in the dashboard; its first check runs right away, with no card.

Solo includes 10 monitors at $15/month. Uptime, SSL, performance and DNS monitoring are included on every plan. Visual checks cover 1 site on Solo and 5 on Starter, and content change monitoring starts on Starter.

Side-by-side pages: Visual Sentinel vs UptimeRobot and Visual Sentinel vs Pingdom.

Visual Sentinel's default expiry reminders are 13, 3 and 1 days before expiry.

vs Competitors

UptimeRobot offers 1-minute intervals on its paid plans, and its free tier covers 50 monitors.

Qualys SSL Labs is a test you run on demand against a public server, not a monitor that alerts you. Visual Sentinel supplies scheduled certificate observations.

Read More articles on SSL best practices.

If you are fixing a certificate error right now, run openssl s_client first, fix the bundle or names, then add SSL Monitoring so the 13, 3 and 1 day reminders warn you before the next expiry. Your first site check needs no card, and the 7-day trial after it needs one. Use Website Checker to check availability.

Run a website of your own? Read about keeping watch over your own website, so an alert tells you when something on it breaks.