Bridge SSL
SSL errors: every browser code explained and fixed
An SSL certificate error is the browser refusing a connection it could not verify: either the site's certificate failed a check, or the TLS handshake broke before any certificate was checked. The browser stops before the page loads instead of carrying on quietly, and the code on the screen names the check that failed. Firefox and Safari word it their own way when the connection could not be set up at all, as Secure Connection Failed and Safari can't establish a secure connection.
The first useful question is not what the error means but who can fix it. A few causes sit on the visitor's device or network. The rest belong to the site owner, and nothing a visitor does in the browser will clear them. Command-line tools and libraries report the same faults in their own words, for example as SSL handshake failed or unable to get local issuer certificate.
Find your code
Chrome and Firefox show different codes for the same underlying problem. Yours is on the error screen, below the message or behind an Advanced control. If you cannot see one, start with what "your connection is not private" means, which covers how to reveal the code in Chrome and Firefox. The heading above the code narrows it down. Chrome shows "Your connection is not private" for a certificate fault [2], and "This site can’t provide a secure connection" when the handshake failed before any certificate was checked, as with ERR_SSL_PROTOCOL_ERROR and ERR_SSL_VERSION_OR_CIPHER_MISMATCH [3].
| Code | Underlying problem | Who fixes it | On Bridge SSL |
|---|---|---|---|
ERR_ | certificate not from a trusted authority | usually the owner | removed |
ERR_ | certificate does not cover this name | usually the owner | partly |
ERR_ | expired certificate, or a wrong device clock | either | partly |
ERR_ | certificate was withdrawn by its authority | the owner | removed |
ERR_ | TLS handshake failed, with no more specific code | either | partly |
ERR_ | no shared protocol version or cipher | the owner | partly |
SEC_ | Firefox equivalent of authority invalid | usually the owner | removed |
SSL_ | Firefox equivalent of name mismatch | usually the owner | partly |
SEC_ | Firefox equivalent of expired | either | partly |
Reading the table
ERR_CERT_COMMON_NAME_INVALID and SSL_ERROR_BAD_CERT_DOMAIN are the same fault seen through different browsers: Chromium describes a certificate whose name "did not match the host name", Firefox a "requested domain name" that "does not match the server’s certificate" [1] [4]. A fix described for one applies to the other.
"Usually the owner" follows Firefox's own wording for unknown-issuer and name faults: "The issue is most likely with the website" [4]. In the last column, three of the nine codes are removed, because on Bridge SSL the certificate and its chain are issued, replaced and served by the same layer. Six are marked partly. A name deeper than the *.example.com wildcard is not covered and still produces a name mismatch, and the wildcard itself is issued only when the domain's DNS is on Bridge DNS. A wrong clock on a visitor's own device is never the site's to fix. An outdated client can still fail to agree a protocol version or cipher, and the edge cannot answer for a broken origin or for a middlebox on the visitor's path.
The four things that actually go wrong
Behind every code in that table is one of four situations. Recognising which one you are looking at is most of the diagnosis.
The certificate does not cover the name you asked for. A certificate lists its names in the Subject Alternative Name extension (RFC 5280, section 4.2.1.6) [5]. A visit to a name not on the list fails, however valid the certificate is otherwise.
www.example.comandexample.comare two names, and each has to be listed.The certificate is not trusted. Either it was not issued by an authority the browser trusts, or the server did not send the intermediate certificates that connect it to one, so the browser cannot build the path to a trusted root (RFC 5280, section 6) [5]. From the outside, both look the same.
The certificate is out of date. Expired, not yet valid, or revoked. A certificate is valid only between the two dates written in it (RFC 5280, section 4.1.2.5) [5], so a wrong device clock makes a valid certificate look expired [1]. That is why this error can appear on one machine and nowhere else.
The connection failed before certificates were reached
The handshake can break before the server sends its certificate: no shared protocol version or cipher, plain HTTP answering on the HTTPS port, or a server that ends the handshake with an alert. Chrome gives version and cipher failures their own code and maps TLS failures that have no specific code to ERR_SSL_PROTOCOL_ERROR [6]. Firefox shows these failures on its Secure Connection Failed page, each with an error code of its own [4]. In Chrome they produce the vaguest codes, and they need the most elimination.
If you are a visitor
Three checks cover the causes that sit on your side.
Check your device clock. If it is wrong, certificates look expired or not yet valid on every site at once. A site failing on your machine while working elsewhere points here first. Chrome has a screen for this, headed "Your clock is behind" or "Your clock is ahead" [2], and Firefox one headed "Your Computer Clock is Wrong" [4].
Sign in to the network, or try another one. A public Wi-Fi network that wants you to sign in can send your connection to its login page first. Chromium lists this among the causes of a name mismatch, and Chrome has a "Connect to Wi-Fi" screen for it [1] [2]. If the site loads on mobile data, the first network was in the way.
Check security software. When antivirus or firewall software interferes with the connection, Chrome shows "An application is stopping Chrome from safely connecting to this site" [2]. Firefox suggests turning off the feature "often called “web scanning” or “https scanning”" [4].
When the fault is at the site
If none of those changes anything, the problem is at the site. For unknown-issuer and name faults, Firefox says so on the screen: "there is nothing you can do to resolve it" [4]. Chrome and Firefox let you continue past a certificate warning, but not on a site that uses HSTS, and Chrome also refuses for a revoked certificate [2] [4]. Continuing is a bad idea on any page where you would type anything: Chrome's own warning names "passwords, messages, or credit cards".
If you own the site
As the site owner, follow a fixed order that finds the cause fastest: check what certificate is actually being served, then whether it covers the name, then whether it has expired or is not yet valid, then whether the chain is complete.
The chain is the check that a test from your own browser can miss. When the server leaves out its intermediate certificate, some browsers fill the gap themselves. A certificate can carry the address of its issuer's certificate in its Authority Information Access field (RFC 5280, section 4.2.2.1) [5], and desktop Firefox preloads the intermediate certificates that public authorities disclose [7]. A client that does neither shows the warning, which is why "it works for me" is not evidence.
Each code's page lists its own causes and the fix for each.
Why the browser refuses instead of warning
When a certificate check fails, the browser cannot tell an attack from a mistake. Chromium's own notes on a name mismatch open with two possibilities: an attacker who has redirected the traffic, and a misconfigured server [1]. An unverified connection is the condition an interceptor needs, so the browser stops in both cases. Stopping is what makes the check real. A warning icon on a loaded page would leave that decision to the visitor, on every site, at the moment it matters most.
Sites can take the choice away completely. A site that uses HSTS tells browsers to accept only verified HTTPS connections, and RFC 6797 requires the browser to end the connection on any error while setting up the secure connection (section 8.4) and advises doing it with "no user recourse" (section 12.1) [8].
It also explains why a certificate problem takes a site down completely rather than degrading it. There is no partial state between verified and unverified, so a forgotten renewal produces an outage.
Errors that are not certificate problems
Two errors that can look like SSL errors are not certificate faults, and this section does not cover them.
ERR_TOO_MANY_REDIRECTS is a redirect loop: Chromium defines it as a load that "resulted in too many redirects" [1]. The cause is redirect configuration, not anything cryptographic.
ERR_CONNECTION_CLOSED and ERR_CONNECTION_RESET mean the connection was closed or reset at the TCP level [1]. Chrome shows them under "This site can’t be reached" and suggests checking the proxy and the firewall [3]. The connection ended before anything about certificates was decided.
Fix certificates with Bridge SSL
Bridge SSL is the certificate layer of Bridge CDN: the platform issues a certificate through the ACME protocol when a hostname needs one, serves it and renews it. ACME hands over the certificate together with its chain, as PEM by default (RFC 8555, section 7.4.2) [9]. Two causes on this page then no longer depend on someone remembering: an expiry nobody noticed, and a chain that was never installed and fails for some visitors and not others.
FAQ
What does an SSL error mean?
An SSL error means the browser could not verify that the connection is what it claims to be, so it stopped. The specific code names which check failed: the names in the certificate, its validity dates, the chain back to a trusted root, or the ability to agree on a protocol at all.
How do I fix an SSL error?
Find the code on the error screen first. As a visitor, check the device clock, sign in to the Wi-Fi or try another network, and check security software that scans HTTPS. If the site fails the same way everywhere, only its owner can fix it, starting with the certificate the server actually sends.
Can I fix an SSL error as a visitor?
Sometimes. Three causes sit on your side: a wrong device clock, a network that wants you to sign in first, and security software that scans HTTPS. If none of those applies, the fault is at the site, and clearing your cache will not change it.
Is it safe to click through the warning?
Not on any page where you would type anything. The warning states that the identity of the other end could not be confirmed, which is the condition an interceptor needs to read what you send. On a page you only read, the risk is lower, but the certificate is still unverified.
Why does the site work for the owner but not for me?
One cause is a missing intermediate certificate. Some browsers fill that gap themselves, from an address in the certificate or from a list they keep, so the owner sees a working page while visitors with other clients see a warning. A wrong clock or security software on your own device is the other possibility.
Why do browsers show different codes?
Because each browser names the same underlying checks in its own vocabulary. ERR_CERT_COMMON_NAME_INVALID and SSL_ERROR_BAD_CERT_DOMAIN describe one fault: the certificate does not cover the name being visited.
Sources
Chromium, net/base/net_error_list.h (CERT_COMMON_NAME_INVALID, CERT_DATE_INVALID, CERT_AUTHORITY_INVALID, CERT_REVOKED, TOO_MANY_REDIRECTS, CONNECTION_CLOSED, CONNECTION_RESET).
Chromium, components/security_interstitials_strings.grdp (privacy error, clock, Wi-Fi login, interfering software, HSTS and revoked screens).
Chromium, components/error_page_strings.grdp and components/error_page/common/localized_error.cc (error page headings and suggestions).
Firefox, toolkit/locales/en-US/toolkit/neterror/netError.ftl, certError.ftl and nsserrors.ftl (error page texts and codes); toolkit/content/aboutNetError.mjs (which errors get which page).
IETF, RFC 5280, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, sections 4.1.2.5, 4.2.1.6, 4.2.2.1 and 6.
Chromium, net/ssl/openssl_ssl_util.cc (how TLS errors map to net error codes).
Mozilla Security Blog, Preloading Intermediate CA Certificates into Firefox.
IETF, RFC 6797, HTTP Strict Transport Security (HSTS), sections 8.4 and 12.1.
IETF, RFC 8555, Automatic Certificate Management Environment (ACME), section 7.4.2.