Copy the link to a markdown format of this article for ChatGPT, Claude, Gemini, or your favorite AI.
An SSL error is the web’s version of a closed door with no sign on it. Your visitor wants in, the browser refuses, and a red warning page does the talking. For a WordPress site, that warning costs you traffic, trust, and rankings in the time it takes to read this sentence.
The good news: most SSL errors fall into a handful of categories, and each one has a fix you can apply today. This guide walks through what these errors are, how to diagnose them, and how to clear them for good. It also covers how Pressable handles the worst of this for you, so you spend less time reading certificate chains and more time running your site.
There is also a deadline you should know about before we start. The rules for how long a certificate can live just changed, and they keep tightening through 2029. More on that below, because it turns “you should automate renewals” into “you no longer have a choice.”
SSL and TLS are the protocols that encrypt the connection between a browser and your server. SSL is the older name. TLS is what actually runs today, though almost everyone still says “SSL” out of habit. When the padlock shows in the address bar, TLS did its job. A certificate, issued by a trusted authority, proves your site is who it claims to be and sets up the encrypted channel.
An SSL error means that handshake broke down somewhere. The break usually happens in one of two places.
Connection-level errors happen during the handshake itself. The browser and server cannot agree on a protocol version or cipher, so the encrypted session never starts. These show up as handshake failures or protocol errors.
Certificate validation errors happen when the handshake works but the certificate fails inspection. It might be expired, issued for the wrong domain, or signed by an authority the browser does not trust. The connection could be encrypted, but the browser refuses to vouch for it.
Either way, the cost is real. Google treats HTTPS as a ranking signal, and a broken certificate can pull pages out of search results. Browsers throw full-screen warnings that most visitors will not click past. And every error chips away at the trust you spent years building. SSL is not a nice-to-have. It is table stakes.
Before the error catalog, one industry shift now sits underneath every renewal you will ever do.
In April 2025, the CA/Browser Forum (the body that sets the rules for trusted certificate authorities) voted to slash how long a certificate can live. The old ceiling was 398 days, roughly a year. That ceiling is collapsing in stages:
A 47-day certificate means roughly eight renewals a year, every year, for every domain you run. The validation data behind those certificates expires faster too, shrinking toward a 10-day reuse window by 2029. Manual renewal at that cadence is not hard. It is impossible to sustain without something forgetting and a site going dark.
This reframes the rest of this guide. Every fix below is a one-time repair. The renewal cadence is the part that will actually bite you, and it now bites eight times a year.
Three certificate errors account for the bulk of what site owners actually see.
Expired certificate (ERR_CERT_DATE_INVALID). Certificates now expire fast, and getting faster. When one lapses, every visitor hits a warning. The quick check: click the padlock (or the warning), open the certificate details, and look at the validity dates. If the “valid until” date is in the past, you found your culprit. This is the most common SSL issue by far, and almost always the result of a renewal that did not fire.
Untrusted or self-signed certificate (ERR_CERT_AUTHORITY_INVALID). Browsers trust certificates that trace back to a known root authority through a chain of intermediate certificates. If that chain is broken, or if the certificate is self-signed, the browser cannot verify it. Self-signed certificates are fine for local testing. In production, they trigger this error every time. The fix usually involves installing the missing intermediate certificate, which we cover below.
Hostname mismatch (ERR_CERT_COMMON_NAME_INVALID). Here is the part most guides get wrong. The error name mentions Common Name, but modern browsers ignore the Common Name field entirely. Chrome has matched hostnames against the Subject Alternative Name (SAN) list only since version 58 in April 2017. The error name is a fossil that nobody renamed. What it really means: the hostname your visitor typed is not in the certificate’s SAN list. So if a visitor reaches www.yoursite.com but the certificate’s SAN list only covers yoursite.com, the browser objects. This catches people who add a subdomain or switch between www and non-www without reissuing the certificate.
One more cause of this exact error has nothing to do with your certificate. If a visitor sits behind a captive portal (hotel or airport Wi-Fi) or a corporate proxy that intercepts TLS, that middlebox serves its own certificate, which obviously does not list your hostname. The tell: the error shows up on one network and vanishes on cellular data. If a visitor reports a mismatch you cannot reproduce, ask what network they were on before you touch your config.
Before you change anything, gather evidence. Guessing at SSL errors wastes hours.
Start with the browser. The error code itself (those ERR_CERT_ strings) tells you the category. Open the developer console and the certificate viewer to see the issuer, the validity dates, and which names the certificate covers. Five minutes here often points straight at the problem.
Next, inspect the certificate directly. The openssl command-line tool is the standard. This one-liner connects and prints the SAN list, which is the field that actually decides a hostname match:
echo | openssl s_client -connect yoursite.com:443 -servername yoursite.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
That shows you the issuer, the validity window, and every hostname the certificate covers, in one pass. If you prefer a browser, online SSL checkers like SSL Labs give you the same picture with a friendlier interface. They flag missing intermediates, weak protocols, and expiry dates in one report.
Then check the server logs. Handshake failures usually leave a trail. Look for TLS alert messages, cipher negotiation failures, or protocol version errors in your web server logs. These tell you whether the problem is the certificate or the configuration around it.
This is the point where managed hosting earns its keep. On Pressable, certificate provisioning, renewal, and chain installation are handled at the platform level using free Let’s Encrypt certificates on every plan. The diagnostic steps above still help you understand what is happening, but you rarely have to run them, because the conditions that cause these errors are managed before they reach your visitors.
Once you know the category, the fix is straightforward.
Renewing or reissuing an expired certificate. Issue a new certificate and install it. The real fix is making sure this never happens again. Set up automated renewal through ACME (the protocol behind Let’s Encrypt) or your provider’s automation. A certificate that renews itself well before expiry will never lapse. With the validity window dropping toward 47 days, manual renewal is no longer a “you might forget” risk. It is a “you will forget, repeatedly” certainty.
Installing missing intermediate certificates. When you get an “untrusted” error and the certificate itself looks valid, the chain is almost always the problem. Your server needs to present not just your certificate but the intermediate certificates that link it to the trusted root. Concatenate the intermediate certificates into your certificate bundle in the correct order, then reload your server. An SSL checker will confirm the chain is complete.
Correcting hostname and SAN mismatches. If the certificate covers the wrong names, reissue it with the right ones. Put every hostname you serve into the SAN list: www and non-www variants and any subdomains. The Common Name field no longer matters for hostname matching, so do not rely on it. Generate a fresh Certificate Signing Request (CSR) with the full SAN list, submit it to your certificate authority, install the reissued certificate, and the mismatch disappears.
Pressable issues and installs certificates that cover the right hostnames automatically, with renewal built in. The most common cause of all three of these errors, a renewal or installation that did not happen, is taken off your plate entirely.
Not every SSL error is about the certificate. Plenty come from the protocol settings around it.
Wrong or unsupported TLS version. Older protocols like SSL 3.0, TLS 1.0, and TLS 1.1 are deprecated and disabled in modern browsers for good reason. If your server only offers an old version, or a client only supports one, the handshake fails. The fix is to disable the old protocols and enable TLS 1.2 and TLS 1.3. This both clears the error and closes known security holes.
Cipher suite misconfiguration. The browser and server have to agree on a cipher to encrypt the session. If your server’s cipher list does not overlap with what clients support, you get a handshake failure. Use a modern cipher suite that favors strong, current algorithms while keeping enough compatibility for the browsers your visitors actually use. Do not hand-roll this. Mozilla’s SSL Configuration Generator produces a tested config for Nginx, Apache, and most other servers. Start there.
Verification after changes. Never assume a config change worked. After editing your TLS settings, run a syntax test (nginx -t for Nginx, apachectl configtest for Apache), reload the service, and re-scan with an SSL checker. Confirm the protocols and ciphers you intended are the ones actually being served.
Tuning protocols and ciphers by hand is exactly the kind of task that goes wrong at the worst possible time. Pressable maintains current TLS configurations across the platform, so your sites serve modern protocols without you editing a single config file.
Sometimes the certificate and server are fine, and the problem sits on the visitor’s end. These are worth knowing because they save you from chasing a server bug that does not exist.
The most common culprit is a wrong local clock. SSL validation depends on the current date, so a device with the wrong time will reject perfectly good certificates. Browser caches can also serve a stale certificate after you have already fixed one. Antivirus software and corporate firewalls sometimes intercept SSL traffic with their own certificates, which breaks the chain. And network middleboxes or proxies can interfere with the handshake before it ever reaches your server.
These causes cross platforms. Mobile devices, desktops, and tablets each have their own clock and cache quirks. A CDN or reverse proxy in front of your site adds another layer where a certificate has to be configured correctly. When an error shows on one device but not another, an environmental cause is usually the reason.
Here is a checklist to work through whenever an SSL error appears:
That last step matters more than any single fix, and the new validity rules make it non-negotiable. Most SSL emergencies are quiet failures that nobody noticed until a visitor did.
SSL errors are solvable, but they keep coming back because certificates expire, chains break, and protocols age out. Every item on that list is a recurring maintenance task, and every one is a chance for something to slip. With certificate lifetimes heading toward 47 days, those chances now arrive eight times a year per domain.
That is the case for not doing it yourself. Pressable provisions free Let’s Encrypt certificates, installs the full chain, renews automatically, and keeps TLS configurations current across the platform. The errors in this guide are the ones we work to prevent before they ever reach your visitors. You get the padlock, the rankings, and the trust, without the renewal calendar.
Understand SSL errors well enough to recognize them. Then let your host carry the weight of preventing them.
Yes. Pressable provisions free Let’s Encrypt certificates on every plan, installs the full certificate chain, renews automatically, and keeps TLS protocol and cipher configurations current — so the errors covered in this guide are largely prevented before they reach visitors.
Most SSL errors come from one of two places: a failed handshake (the browser and server can’t agree on a protocol or cipher) or a failed certificate check (the certificate is expired, mismatched to the domain, or issued by an untrusted authority).
An expired certificate (ERR_CERT_DATE_INVALID) is the most frequent cause. It happens when a renewal doesn’t fire in time. Check the certificate’s “valid until” date in your browser’s certificate details to confirm.
The chain linking your certificate to a trusted root authority may be broken. Browsers need the intermediate certificates installed alongside your certificate, not just the certificate itself. Missing intermediates trigger an “untrusted” or ERR_CERT_AUTHORITY_INVALID error.
Modern browsers check the certificate’s Subject Alternative Name (SAN) list, not the Common Name field the error references. If a visitor reaches a hostname (like www.yoursite.com) that isn’t in the SAN list, the browser blocks the connection. Reissuing the certificate with every hostname variant in the SAN list fixes this.
Maximum validity is shrinking on a set schedule from the CA/Browser Forum: 200 days as of March 2026, 100 days starting March 2027, and 47 days starting March 2029. That’s roughly eight renewals a year per domain by 2029.
This usually points to a client-side or network cause rather than a certificate problem: a wrong system clock, a stale browser cache, antivirus or corporate software intercepting traffic, or a captive Wi-Fi portal serving its own certificate. If the error disappears on another network or device, start there before touching your server config.
How do I increase conversions? This is a question that is near top-of-mind for all business owners with a WordPress website. One of the best strategies is to A/B test landing pages in WordPress. A/B […]
Feeling like your website isn’t as fast as it should be? Learn how to accurately measure network performance in our how-to guide.
In this article, we’ll show you to to run your own benchmarks against your WordPress site and introduce you to a few tools to help you along your journey.