Your connection is not private: what the warning means and how to fix it

02Which NET::ERR_CERT code do I have, and who has to fix it?

Click the error code under the warning, or open the certificate viewer, to see the exact reason. The table maps the common Chromium codes to their Firefox equivalents, the check that failed and the side that can fix it.

03What causes the warning on the visitor's side?

If many unrelated sites fail at once, the cause is the device or the network, not the sites. Three causes cover most of these cases.

A wrong clock. Validity is checked against the device's own time, so a clock that is far off makes valid certificates look expired or not yet valid. Chrome then says "Your clock is behind" or "Your clock is ahead", Firefox "Your Computer Clock is Wrong". Turn on automatic date and time and reload.

A captive portal. Hotel, airport and train Wi-Fi often intercepts the first connection to show a sign-in page, which arrives with the portal's certificate. Chromium names this case under COMMON_NAME_INVALID and can show a "Connect to Wi-Fi" page instead. Complete the sign-in, then retry.

HTTPS scanning by antivirus software or a company proxy, which re-encrypts traffic with its own certificate; if the browser does not trust that root, every site fails with AUTHORITY_INVALID. Firefox starts from Mozilla's own root store; since Firefox 120 it also imports roots added to the operating system on Windows, macOS and Android, so on Linux, or with that import switched off, it can be the only browser that complains, with a page titled "Software is Preventing Firefox From Safely Connecting to This Site". Mozilla suggests switching off the feature that scans encrypted connections, or asking IT on a managed network. A 2017 US-CERT alert, now published by CISA, warned that many such products weaken TLS security.

• Many sites fail at once: check the clock, then the network, then any HTTPS-scanning software
• Only on one Wi-Fi network: complete the network's sign-in page first
• Only in Firefox: an interception certificate the operating system trusts and Firefox does not, typically on Linux or with the import of system roots switched off
• One site fails everywhere: its certificate is the problem, so tell the owner

04What causes it on the website's side?

If one site shows the warning on every device and network, the server presents a bad certificate. Behind a CDN or reverse proxy, visitors see the edge's certificate, not the origin's, so test the public hostname. Each of these causes can be confirmed from a terminal in a minute.

• Expired certificate: renewal failed silently, or renewed a file the server never reloaded. Under CA/Browser Forum ballot SC-081, maximum lifetimes fall in steps from 398 to 47 days between March 2026 and March 2029, so manual renewal stops being realistic
• Missing name: the certificate covers example.com but the visitor opened www.example.com, or a subdomain went live before its certificate
• Incomplete chain: the server sends its certificate without the intermediate. Mozilla calls this one of the most common configuration problems; Firefox has preloaded known intermediates since version 68, so the site can work there and fail in other browsers, apps and curl
• Wrong certificate for the name: sites sharing an IP address are picked by the requested name (SNI), so a missing or mistyped server name hands out the default site's certificate
• Self-signed or private-CA certificate left on a public site after testing

05How do I test a certificate with openssl?

openssl s_client shows what a server presents and whether it verifies, independent of any browser. Pass -servername, so the server picks the certificate for that name (OpenSSL fills it in from a hostname given to -connect, but not when you connect to an IP address), and -verify_hostname, so OpenSSL checks the name as a browser does: without it, wrong.host.badssl.com verified as "0 (ok)" in testing. The results below are real, from the badssl.com hosts, which exist to fail in specific ways. s_client does not check revocation unless asked to, which explains the revoked host.

# does it verify, including the hostname? look for "Verify return code"
openssl s_client -connect example.com:443 -servername example.com \
  -verify_hostname example.com </dev/null 2>&1 | grep 'Verify return code'

# who issued it, for which names, and until when
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

# how many certificates does the server send? 1 usually means a missing intermediate
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null \
  | grep -c 'BEGIN CERTIFICATE'

# for scripts: exit status 1 instead of a printed code
openssl s_client -connect example.com:443 -servername example.com \
  -verify_hostname example.com -verify_return_error </dev/null >/dev/null 2>&1; echo $?

06How do I check for a wrong clock?

Compare the device's time with a server's. On Linux, timedatectl reports whether the clock is synchronised, and the Date header of any web server gives a second opinion. OpenSSL's -attime option shows the effect directly: the valid certificate for example.com failed as expired with the clock set to 2030 and as not yet valid with it set to 2020, which is what a browser sees on a device with a flat clock battery or a hand-set date.

# is the system clock synchronised?
timedatectl status | grep -E 'Universal time|synchronized'

# a server's idea of the time, for comparison
curl -sI https://example.com | grep -i '^date:'

# what a valid certificate looks like to a client with the wrong date
openssl s_client -connect example.com:443 -servername example.com \
  -attime $(date -d '2030-01-01' +%s) </dev/null 2>/dev/null | grep 'Verify return code'
#   Verify return code: 10 (certificate has expired)

07How do I look a certificate up in Certificate Transparency logs?

Public certificate authorities record what they issue in public Certificate Transparency logs (RFC 6962), and Chrome refuses publicly trusted certificates that do not comply with its CT policy. The logs are therefore a neutral record of what was issued for a domain. Search them in a browser at crt.sh, or from a terminal as below; each certificate usually appears twice, as a precertificate and as the final certificate.

Every hostname on a public certificate is visible in the logs, including servers you would rather keep quiet; how to hide your origin IP explains why that matters.

• The warning says expired: if the logs show a newer certificate, renewal worked and the server still presents the old file
• The warning says the name is missing: the logs show exactly which names each certificate covers
• The certificate in the browser is not in the logs at all: it probably came from a private CA, such as antivirus software, a company proxy or a test setup

curl -s 'https://crt.sh/?q=example.com&output=json&exclude=expired' \
  | python3 -m json.tool | grep -E '"(issuer_name|name_value|not_after)"'

08How do site owners stop the warning coming back?

Most certificate warnings are operational failures that recur, so fix the process as well as the certificate.

• Automate issuance and renewal, and reload the web server after every renewal
• Serve the full chain: your certificate followed by its intermediates, without the root
• Cover every name visitors type, including www, because a redirect only happens after the certificate has been accepted
• Monitor expiry from outside, for example with the openssl check and -attime set 30 days ahead
• Watch the CT logs for certificates you did not request
• Turn on HSTS only once all of this is reliable, because it removes the option to click through; the security headers guide covers the rollout