I've spent over eight years fixing WordPress sites, VPS boxes and Cloudflare setups, and nearly every SSL ticket I've handled came down to one of four things: the server isn't speaking TLS on the port it should, the certificate chain is incomplete, the protocol or cipher settings are wrong, or Cloudflare and the origin disagree about who is doing the encryption. This post goes through how to tell which one you have, working from a terminal instead of a browser.

Start with openssl s_client, not the browser

Browsers cache, retry, fall back and hide the details. openssl s_client shows you exactly what the server sends:

openssl s_client -connect example.com:443 -servername example.com </dev/null

-servername matters. Without SNI, a server hosting several sites may hand you the default certificate, and you'll end up chasing a problem that doesn't exist.

Three parts of the output are worth reading.

The certificate chain (Certificate chain). You should see your leaf certificate at depth 0 and at least one intermediate at depth 1. If only depth 0 is listed, the server isn't sending the intermediate.

The verify result near the bottom:

Verify return code: 0 (ok)

Anything other than 0 is a lead to follow.

The negotiated protocol and cipher:

New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384

If the handshake fails completely and you get something like wrong version number or unexpected eof, the problem comes before certificates. More on that below.

To verify against the same trust store that most clients use, and to check the hostname as well:

openssl s_client -connect example.com:443 -servername example.com \
  -verify_return_error -verify_hostname example.com </dev/null

Reading the verify codes

These are the codes I run into most, and what they usually mean in practice:

Code 20 is the classic one behind NET::ERR_CERT_AUTHORITY_INVALID and Firefox's SEC_ERROR_UNKNOWN_ISSUER. The confusing part is that Chrome on a desktop often still loads the page, because it can fetch missing intermediates by itself, while Firefox, Android, curl and API clients fail. So "it works for me" tells you very little.

To see which names the certificate covers and when it expires:

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

Fixing the chain on Nginx and Apache

Nginx has no separate chain directive. ssl_certificate must point to a file with the leaf certificate first and the intermediates after it. With Let's Encrypt that's fullchain.pem, not cert.pem:

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

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

If your CA sent separate files, build the bundle yourself, leaf first:

cat example_com.crt intermediate.crt > example_com_fullchain.crt

On Apache 2.4.8 and later, SSLCertificateFile can also hold the full chain. Older setups use SSLCertificateChainFile:

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on
    SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
</VirtualHost>

Check that the key actually belongs to the certificate. Mismatched pairs show up more often than you'd expect after a manual renewal:

openssl x509 -noout -pubkey -in fullchain.pem | sha256sum
openssl pkey -pubout -in privkey.pem | sha256sum

The two hashes must match. Then test the config and reload:

sudo nginx -t && sudo systemctl reload nginx
sudo apachectl configtest && sudo systemctl reload apache2

Re-run s_client afterwards. You should see depth 1 in the chain and Verify return code: 0.

When the handshake never happens: ERR_SSL_PROTOCOL_ERROR

ERR_SSL_PROTOCOL_ERROR means the browser and server couldn't even agree to talk TLS. From the server side, check these in order.

1. Is anything actually listening with TLS on 443?

sudo ss -tlnp | grep ':443'
curl -v http://example.com:443/

If plain HTTP answers on port 443, you've found it. Usually a listen 443; without ssl in Nginx, or a <VirtualHost *:443> without SSLEngine on. OpenSSL reports this as wrong version number, and Firefox shows SSL_ERROR_RX_RECORD_TOO_LONG.

2. Is mod_ssl loaded (Apache)?

apachectl -M | grep ssl
sudo a2enmod ssl && sudo systemctl restart apache2

3. Do the protocols overlap? Modern browsers only accept TLS 1.2 and 1.3. Test each one explicitly:

openssl s_client -connect example.com:443 -servername example.com -tls1_2 </dev/null
openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null

A sensible baseline for Nginx:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;

And for Apache:

SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLHonorCipherOrder off

If you've copied an old hardened config that lists only a few ciphers, either drop the custom ssl_ciphers line or generate a current one with Mozilla's SSL Configuration Generator. An overly narrow cipher list is a common reason for ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

4. Is something in between? A load balancer, a hosting panel proxy or a firewall doing TLS inspection can break the handshake before it reaches your web server. Running s_client from the server itself against 127.0.0.1 with -servername tells you whether the problem is local or upstream.

Cloudflare SSL modes and the redirect loop

With Cloudflare proxying (orange cloud), there are two TLS connections: visitor to Cloudflare, and Cloudflare to your origin. The SSL/TLS mode controls the second one:

• Flexible: Cloudflare talks to your origin over plain HTTP on port 80. The visitor sees HTTPS, but traffic to your server isn't encrypted.
• Full: Cloudflare connects over HTTPS but accepts any certificate, including self-signed or expired ones.
• Full (strict): Cloudflare connects over HTTPS and requires a valid certificate for the hostname, either from a public CA or Cloudflare's Origin CA.

Flexible mode causes most of the ERR_TOO_MANY_REDIRECTS tickets I've seen after someone "turned on SSL". Here's the loop: the origin has an HTTP-to-HTTPS redirect (in Nginx, .htaccess, or a WordPress plugin). Cloudflare requests the page over HTTP, the origin answers with a 301 to HTTPS, the browser follows it to Cloudflare, Cloudflare requests HTTP again, and it repeats forever.

You can confirm it by going straight to the origin and bypassing Cloudflare:

curl -sI --resolve example.com:80:ORIGIN_IP http://example.com/ | grep -i location
curl -sI --resolve example.com:443:ORIGIN_IP https://example.com/

The real fix is to install a certificate on the origin and switch to Full (strict). Disabling the origin redirect just to make Flexible work hides the problem and leaves the Cloudflare-to-origin leg unencrypted.

For WordPress behind Cloudflare, also make sure WordPress knows the request was HTTPS, or it may generate its own redirects and mixed-content URLs. In wp-config.php, above the "stop editing" line:

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

If you switch to Full or Full (strict) and get Error 525 (handshake failed) or 526 (invalid certificate), run the s_client checks above against the origin IP. It's the same set of problems, just with Cloudflare as the client.

The Origin CA caveat

Cloudflare's Origin CA certificates are free, can last up to 15 years, and work well with Full (strict). But only Cloudflare trusts them. Browsers don't.

That leads to a recognisable failure. Everything works until someone sets the DNS record to grey cloud (DNS only), pauses Cloudflare, or hits the origin directly through a subdomain that isn't proxied. Then every visitor gets NET::ERR_CERT_AUTHORITY_INVALID, and s_client shows an issuer like CloudFlare Origin SSL Certificate Authority.

So:

• Use Origin CA only on hostnames that are always proxied.
• For anything that might be reached directly (mail hostnames, API subdomains, staging, a site you might move off Cloudflare later), use a public certificate such as Let's Encrypt. It works in Full (strict) too.
• If you use Origin CA, consider allowing only Cloudflare IP ranges on 443, so nobody reaches the origin directly by accident.

A quick checklist

1. openssl s_client -servername against the domain, then against the origin IP.
2. Read the chain depth and the verify code before changing anything.
3. Serve fullchain, confirm the key matches, run nginx -t or apachectl configtest.
4. Allow TLS 1.2 and 1.3, and drop outdated cipher lists.
5. On Cloudflare, use Full (strict) with a real or Origin CA cert, never Flexible plus an origin redirect.
6. Keep Origin CA certificates behind the orange cloud.

Full step-by-step guides

I keep longer, error-specific walkthroughs on ErrorRescue:

• ERR_SSL_PROTOCOL_ERROR: server-side fixes
• NET::ERR_CERT_AUTHORITY_INVALID: fixing untrusted certificates
• SEC_ERROR_UNKNOWN_ISSUER in Firefox
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH
• Too many redirects after enabling SSL
• Cloudflare Error 525: SSL handshake failed