SSL Version or Cipher Mismatch: ERR_SSL_VERSION_OR_CIPHER_MISMATCH Fix

What is the SSL version or cipher mismatch error (ERR_SSL_VERSION_OR_CIPHER_MISMATCH)?

The SSL version or cipher mismatch error is a Chrome and Edge message saying that your browser and the server share no TLS version or cipher suite for HTTPS. It appears as ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Typical causes are server settings, disabled legacy protocols, or a certificate that misses the domain. The page never loads.

First, the two sides run a handshake before any secure page loads. Then the browser lists the TLS versions and cipher suites it supports, and the server picks one of them. If the lists share nothing, no connection starts. In other words, you are not looking at a broken page, only at a connection that never began.

If you want a primer on what the certificate itself does, read our guide on what an SSL certificate is. This article focuses on finding the layer that causes the error and fixing it. Mixed content warnings and connection resets are different problems, so we leave them out here.

Who should fix it: the visitor, the site owner, or the server admin?

Most of the time the site side is responsible, because many visitors see the error at once. However, an outdated device or a security tool in the middle can cause it for one person only. The table below shows what each role controls and where to look first.

In a small business, one person often holds all four roles. Even so, keep the order. First find out whether everyone sees the error or only you, then check the layers from the outside in.

What are TLS versions and cipher suites, and how do browser and server agree?

TLS is the protocol that encrypts traffic between a browser and a server. The version number tells you the generation of the protocol. For example, a cipher suite is the bundle of key exchange, authentication and encryption algorithms used on that connection. Both sides need at least one option in common.

During the handshake, the browser sends a ClientHello message that lists what it supports. The server then answers with its choice. If nothing matches, the server closes the connection with an alert. The current version, TLS 1.3, is defined in RFC 8446. In addition, it keeps the list of cipher suites much shorter than before.

That is why the SSL version or cipher mismatch can come from two directions. A server with a very narrow list leaves even a modern browser without a match. On the other hand, a very old browser cannot use the server's current list. There is also a third case: the server cannot present the right certificate for the hostname, and the browser shows the same error screen.

What causes the SSL version or cipher mismatch error?

The causes fall into a few groups. The list below follows the order in which you should check them. It is not a statistic, only a practical roadmap.

• A certificate that does not cover the domain or subdomain being visited.
• A CDN that has not activated a certificate for the domain yet, or a record that is not proxied.
• Legacy TLS versions or a very narrow cipher list on the server.
• Legacy TLS versions switched off by the server or CDN, while the visitor's device does not know the new ones.
• An expired certificate, or the wrong certificate file in place.
• An antivirus tool or corporate proxy that sits in the middle and connects with an old TLS version.

The first two items are especially common right after you add a new domain or subdomain. Legacy-version causes, however, usually appear after a security hardening change. In both cases, remembering what changed last speeds up the diagnosis.

How do browsers show this error?

The name of the error differs by browser, but the meaning stays the same. Chromium-based browsers such as Chrome and Edge usually say the site cannot provide a secure connection and print ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Firefox, for example, reports the same situation with its own error code. The wording can change between versions, so look at the behavior instead.

• The page stays blank and no content appears.
• Every refresh brings the same error back.
• There is no way to click through with a "proceed anyway" option, because no connection exists.
• HTTPS works fine on other sites, so the problem is the target site and not your network.

The last point is valuable for diagnosis. It lets you stop blaming your internet connection and focus on the site. Moreover, the error code is the clearest piece of information you can give your provider when you open a support ticket.

Which cause matches which fix?

As the diagnosis moves forward, matching symptoms to fixes gets easier. Therefore, use the table as a summary, and read the details in the next sections. Each row shows what to check first and what to change next.

Do not mix up the third and fourth rows. In one, the server cannot offer new versions. In the other, the client does not know them. Consequently, the fixes are opposites.

In what order should you start the diagnosis?

The right order moves from the cheapest test to the most expensive one. First narrow down the scope, then look at the certificate, and only then at the server settings. That way, you avoid creating new problems with needless configuration changes.

1. Open the site in another browser, on another device, and on mobile data.
2. If everyone sees the error, check the certificate scope and expiry date.
3. Verify the DNS records and whether the domain uses a CDN.
4. Test which TLS versions the server accepts from the command line.
5. Review the protocol and cipher lines in the Nginx or Apache configuration.
6. Apply the change, test it, and confirm the result with more than one client.

Also, our tools can help with the first steps. The SSL checker shows the validity of the certificate. The DNS lookup tool shows which address the domain resolves to, so you can tell whether traffic goes to a CDN or straight to the server.

Why were TLS 1.0 and 1.1 turned off?

The IETF formally deprecated TLS 1.0 and 1.1 in March 2021. RFC 8996 says these two versions must not be used. The reason is that they lack support for current cryptographic algorithms. The table below summarizes where each version stands.

As a result, the major browsers followed this decision. First they showed warnings, then they removed support for the old versions. Today a server that offers only TLS 1.0 or 1.1 triggers this error in modern browsers right away. In short, the problem is the age of the server, not the browser.

So when you see the error, do not think "let me turn the old version back on." That lowers security and goes against the standards. The correct path is to update the server so that it offers TLS 1.2 and 1.3.

What happens if the server's OpenSSL version is old?

TLS support depends not only on the server software but also on the crypto library underneath. The Nginx documentation says the TLSv1.3 parameter works only with OpenSSL 1.1.1 or later. Also, the Apache documentation states the same condition for TLSv1.3. So on an old operating system, TLS 1.3 stays unavailable even when the configuration is correct.

This has two consequences, and neither is trivial. First, changing a single configuration line may not be enough. Second, if a very old server cannot offer even TLS 1.2, the real fix is to update the operating system and packages. A system administrator who knows the package sources should do that work.

Still, using current stable releases is the sturdiest path here. We do not name version numbers, because they go stale quickly. Instead, check the vendor's official support status for your operating system. If it is past its support period, plan an upgrade with your hosting provider.

How do you test which TLS versions your server accepts?

The OpenSSL command-line tool can force a connection with a specific version. In the examples below, replace example.com with your own domain. A successful connection in the output means that version is on, while an error means it is off.

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

At least one of these commands should succeed, because a server must offer at least one modern version. If both fail, the server does not offer modern versions. You can try the -tls1_1 flag to probe old versions. However, some OpenSSL builds disable that version already, so the command may fail regardless of the server.

You can run a similar test with curl:

curl -vI --tlsv1.2 --tls-max 1.2 https://example.com

This command tries to connect with TLS 1.2 only. The verbose output also shows the negotiated version and cipher suite. If the connection works, the problem probably sits in the certificate scope or the CDN setting, not in the server protocols.

How do you set ssl_protocols and ssl_ciphers in Nginx?

According to the Nginx documentation, the default value of the ssl_protocols directive is TLSv1.2 TLSv1.3. TLSv1.3 has been part of the default since version 1.23.4. On a very old installation, or with an old hand-written line, the list may differ.

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_protocols TLSv1.2 TLSv1.3;
}

You usually do not need to write the cipher list (ssl_ciphers) by hand, because the Nginx default does the job. If you need a custom list, Mozilla's SSL configuration generator produces a current example for your server software. After any change, check the syntax with nginx -t, and then reload the configuration.

If you publish a Next.js or Node.js app behind Nginx, also look at the certificate steps in our guide to deploying Next.js on a VPS.

How do you set SSLProtocol and SSLCipherSuite in Apache?

According to the Apache 2.4 documentation, the default for SSLProtocol is all -SSLv3. That leaves every version except SSLv3 open. As a result, TLS 1.0 and 1.1 may still be on in an older setup. To harden it, you can switch them off explicitly.

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

TLS 1.3 cipher suites use a separate syntax. The Apache documentation says you can use the TLSv1.3 specifier in the SSLCipherSuite line with OpenSSL 1.1.1 and later. Still, for most sites the safest choice is to find the default list good enough and leave it alone.

Before you apply a change, check the syntax with the apachectl configtest command. Also keep in mind that you can change this setting on your own VPS, but not on shared hosting. If you wonder about other server software, see our OpenLiteSpeed and Nginx comparison.

Could the certificate fail to cover your domain?

Yes, and it is one of the most common causes of the SSL version or cipher mismatch error. A certificate covers only the names inside it. For example, a certificate issued for example.com does not automatically cover www.example.com or blog.example.com. The browser reports this mismatch with the same error screen.

You can see which names the certificate covers with the command below. It uses the -ext option, which works with OpenSSL 1.1.1 and later:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -dates -ext subjectAltName

The subjectAltName line in the output lists every name the certificate is valid for. So if the address you need is missing, renew the certificate and add the missing name. A wildcard certificate covers one level only; read our wildcard SSL guide for details.

What is SNI, and can it cause the wrong certificate to appear?

SNI (Server Name Indication) is a TLS extension that lets the browser tell the server which domain it wants during the handshake. A server that hosts several sites on one IP address uses this information to pick the right certificate. In short, SNI is the foundation of multi-site hosting on a single IP.

If SNI does not work properly, the server may send its default certificate. That certificate belongs to another domain, and the browser rejects the connection. Suppose you add a new site to the server and only that site fails. In that case, check the virtual host block and the certificate path.

When you test, do not forget the -servername flag in the OpenSSL command. Without it, the command sends no SNI, so you see the server's default certificate. As a result, you could judge a healthy site as broken by looking at the wrong answer.

What should you check if you use Cloudflare or another CDN?

According to the Cloudflare documentation, this error appears when a certificate does not cover your domain or subdomain. The page lists four main causes. All of them can be fixed in the CDN panel, so you do not need to touch the server.

• Activation of the Universal SSL certificate can take 15 minutes to 24 hours after you add a domain.
• Universal and Advanced certificates cover only proxied records, not "DNS only" records.
• If you use a custom certificate, it may have expired.
• Universal SSL covers only the apex domain and one level of subdomain, so names such as dev.docs.example.com stay outside by default.

The fixes follow in the same order: wait until the status shows Active, switch the record to Proxied, upload a new certificate, and use Total TLS or an Advanced certificate for multi-level names. For details, see Cloudflare's troubleshooting page.

There is also the Minimum TLS Version setting. Cloudflare describes it as a filter that rejects visitors who do not support the selected version or newer. Therefore, if you raise it without need, old but legitimate clients may see an error. Read the minimum TLS version documentation for the details.

Can the cipher list conflict with the certificate type?

Yes, and it happens mostly with hand-written cipher lists. The name of a cipher suite also tells you which certificate type it expects for authentication. If the server certificate is ECDSA and the list holds only suites that expect an RSA certificate, no common option is left.

This usually happens in one scenario: someone copies an old cipher list from the internet and pastes it into the configuration. Later, the certificate is renewed or its type changes. As a result, the list no longer matches the new certificate. So the SSL version or cipher mismatch starts suddenly, while the certificate seems to work as before.

The fix is simple. Remove the hand-written cipher list and return to the default of your server software or to a current ready-made example. If you are unsure about the certificate type, ask the company that issued it. Also, avoid changing the list and the certificate separately without thinking about both.

Why does the error appear on old devices and browsers?

Old operating systems and browsers may not know TLS 1.2 at all. Instead, these devices try to connect with TLS 1.0 or 1.1 only. The server, in line with the standards, does not accept those versions. As a result, no common version exists, and the error appears.

In such a case, the right fix is to update the client. The visitor should upgrade the operating system or the browser. Turning TLS 1.0 back on at the server, by contrast, weakens security for every visitor. For that reason, we do not recommend it at all.

So how many of your visitors use old devices? Instead of guessing, look at your analytics. The technology reports in GA4 show the browser and operating system mix. If the share of old devices is small, you need no extra step. However, if it is large, you can prepare a short info page that suggests an update to your customers.

Can antivirus, corporate proxies and browser settings trigger it?

Yes, they can. Some antivirus programs and corporate security gateways re-encrypt HTTPS traffic with their own intermediate certificates. If this middle layer runs an old TLS version, the browser and the server may lack a common version. The error then shows up only on that network or computer, so nobody should blame the server first.

On the visitor side, follow this order:

1. Try to open the site on another network, for example on mobile data.
2. Compare the result with another browser and another device.
3. Install the operating system and browser updates.
4. Turn off the HTTPS scanning of the antivirus for a moment and try again.
5. If you are on a corporate network, tell your IT team.

If the error does not show on another network or device, the problem is probably on your side. Therefore, making this distinction before you touch the server saves hours.

How does this error affect SEO and sales?

If a visitor cannot open the page, they cannot see your content. Likewise, search engine crawlers cannot read the page if they cannot connect to the HTTPS address. A lasting error can show up as an access problem in Search Console. For this reason, you should take the certificate and TLS setup seriously.

In e-commerce, the effect is more direct, because a customer who cannot reach the checkout page cannot finish the purchase. If you want a wider view of the topic, read our article on e-commerce trust signals.

No team can promise zero downtime. Still, monitoring certificate renewals and testing after every configuration change lowers the risk noticeably. These checks come first in a technical health review, and we cover them routinely in our SEO consulting work.

When should you not do it yourself and leave it to your hosting provider?

We are a digital marketing and web team, not a hosting company. So the commands in this article rest on official documentation, and they may not give the same result in every server environment. In the cases below, it is safer to leave the job to your hosting provider.

• You use shared hosting and have no access to the server configuration files.
• The hosting panel manages the certificate automatically, and manual changes could break that setup.
• You do not fully understand what you are changing in the configuration file.
• You are about to change a live e-commerce site without a backup.
• The problem sits in the connection mode between the CDN and the server, and you do not manage both sides.

If you work on your own VPS, take a backup first. Our website backup strategy guide is a good start. When you choose a provider, also look at the support criteria in how to choose web hosting.

What information should you give your provider when you ask for support?

The clearer the support request, the faster the answer. Therefore, collect a few facts before you write. The list below answers the first questions your hosting provider or CDN admin will ask.

• The full text of the error message and the domain or subdomain where it appears.
• When the error began and what changed right before it.
• Whether everyone sees it or only certain devices and networks.
• The output of your OpenSSL or curl command.
• Whether you use a CDN and who manages the certificate.

With these facts, the provider narrows the problem down faster. Besides, the date shows whether an automatic certificate renewal or a configuration update was the trigger. In short, a well-prepared request cuts down the back-and-forth.

What should you verify after the fix?

The error going away is not enough on its own. You need to confirm that the fix is lasting and that it broke nothing else. If you touched a configuration file, run the checks below in order.

1. Open the www and non-www addresses, and every subdomain you use.
2. Try the home page and a checkout or form page in more than one browser and on a mobile device.
3. Confirm with the OpenSSL command that TLS 1.2 and 1.3 connections work.
4. Note the certificate expiry date from the SSL checker, and add a reminder to your calendar.
5. Make sure the server error log has no new error lines.

A wrong setting can also keep the server from starting at all. In that case, the diagnosis order in our 500 Internal Server Error guide helps. To be able to roll back, keep a copy of the old configuration file.

What are the most common mistakes when fixing this error?

The mistakes below add new problems instead of solving the old one. They all come from hasty changes. So moving slowly and in order is often the fastest way.

• Turning old TLS versions back on breaks both security and standards compliance.
• Pasting long cipher lists copied from the internet can create a certificate mismatch.
• Changing settings in two places without knowing whether the cause sits in the CDN or the server hides the real cause.
• Reloading the configuration without testing it can take the whole site down.
• Seeing a cached old result and thinking the fix failed leads to needless changes.

Take the last item seriously. After a fix, test in a private window and on a different network. Redirect chains can create a similar confusion, and our article on redirect chains gives more detail.

What is the short roadmap for the SSL version or cipher mismatch?

First define the scope: does everyone see it, or only you? If everyone does, check that the certificate covers the domain and look at the CDN status. Then test that the server offers TLS 1.2 and 1.3, and fix the protocol line if needed.

If the error shows only on old devices, update the client and do not turn old versions back on against the standards. If a layer is out of your reach, ask your hosting provider or CDN admin for help. That way, you protect both security and availability.