TLS Errors and SSL/TLS Misconfigurations: How to Check Your HTTPS Setup and Fix Them
The padlock in the address bar tells visitors their connection is encrypted. It does not tell them — or you — whether that encryption is configured well. Plenty of websites with a valid certificate still support outdated protocols, weak ciphers or broken redirects that quietly undermine the protection HTTPS is supposed to give.
This guide explains the most common SSL/TLS misconfigurations we find on small business websites, how to check your own HTTPS setup in a few minutes, and how to fix each problem.
SSL vs TLS: a quick clarification
SSL is the old name. Every version of SSL is long broken and disabled in modern browsers; what secures websites today is TLS (Transport Layer Security). People still say “SSL certificate” out of habit, and that is fine — but your server should only be speaking TLS 1.2 and TLS 1.3.
How to check your HTTPS setup
- In the browser: click the padlock, open the certificate details and check the issuer, the domain names covered and the expiry date.
- With a free SSL test: public SSL testing services grade your server’s configuration, list supported protocols and ciphers, and flag known weaknesses. Aim for an A grade.
- From a terminal:
openssl s_client -connect yourdomain.com:443 -servername yourdomain.comshows the certificate chain and negotiated protocol.
Common TLS errors and what they mean
Most TLS errors that visitors see in the browser trace back to one of the misconfigurations below. If someone sends you a screenshot of a warning on your site, this table tells you where to start.
| Error you see | What it usually means | Where to fix it |
|---|---|---|
NET::ERR_CERT_DATE_INVALID / “certificate expired” | The certificate has expired, or the visitor’s device clock is wrong | Renew the certificate and turn on automatic renewal (#4) |
NET::ERR_CERT_COMMON_NAME_INVALID / “name mismatch” | The certificate does not cover the hostname being visited, often www or a subdomain | Add every hostname to the certificate (#5) |
NET::ERR_CERT_AUTHORITY_INVALID / “unable to get local issuer certificate” | Self-signed certificate, or the server is not sending the intermediate certificate | Install a trusted certificate with its full chain (#3) |
ERR_SSL_VERSION_OR_CIPHER_MISMATCH | Server and browser share no protocol version or cipher, typically because the server only offers obsolete ones | Enable TLS 1.2 and 1.3 with a modern cipher profile (#1, #2) |
ERR_SSL_PROTOCOL_ERROR / “handshake failure” | The TLS handshake broke: wrong certificate on the port, a misconfigured CDN or proxy, or a firewall interfering | Test the server directly with an SSL test or openssl s_client, then check CDN/proxy settings |
| “Not secure” or a broken padlock on an HTTPS page | Mixed content: the page loads some resources over plain HTTP | Switch all resource URLs to HTTPS (#8) |
| Site works in the browser but an app, payment provider or API call fails with a TLS error | Incomplete chain or an old protocol that the client refuses | Install the full chain and allow only TLS 1.2+ (#3, #1) |
If the error appears only for one visitor, check their side first: a wrong system clock, an outdated operating system or antivirus software that inspects HTTPS traffic can all cause TLS errors on a correctly configured site.
The 8 most common TLS misconfigurations
1. Old protocols still enabled (TLS 1.0 and 1.1)
TLS 1.0 and 1.1 are formally deprecated and contain known weaknesses. Modern browsers have dropped them, but if your server still accepts them, an attacker in a position to interfere with traffic may be able to force a downgrade. Fix: allow only TLS 1.2 and 1.3.
2. Weak cipher suites
Ciphers are the algorithms used inside TLS. Old ones such as RC4, 3DES, export-grade ciphers or suites without forward secrecy should be disabled. Fix: use your host’s or web server’s “modern” or “intermediate” recommended profile rather than hand-picking ciphers.
3. Incomplete certificate chain
Your certificate is signed by an intermediate certificate, which must also be sent by the server. Some browsers fill the gap themselves, so the site looks fine on your laptop, while other clients, payment integrations or mobile apps fail with errors. Fix: install the full chain (often called “fullchain”) supplied by your certificate authority.
4. Expired or soon-to-expire certificates
An expired certificate turns your site into a full-page browser warning that drives visitors away. It usually happens when renewal is manual or an automated renewal silently failed. Fix: use automatic renewal and set up an expiry alert at least 14 days ahead.
5. Certificate does not cover all hostnames
A certificate for yourdomain.com does not automatically cover www.yourdomain.com, shop.yourdomain.com or mail.yourdomain.com. Visitors who reach an uncovered name see a warning. Fix: list every hostname you use on the certificate, or use a wildcard where appropriate.
6. HTTP not redirected to HTTPS
If http:// pages still load without redirecting, visitors who follow old links or type the address by hand never get encryption. Fix: permanently (301) redirect every HTTP URL to its HTTPS equivalent, for both the bare domain and www.
7. No HSTS
Even with a redirect, the very first request can be made over plain HTTP and intercepted. The Strict-Transport-Security header tells browsers to use HTTPS automatically on every future visit. Fix: add HSTS once your whole site works over HTTPS. See our guide to HTTP security headers.
8. Mixed content
A page served over HTTPS that loads scripts, images or fonts over plain HTTP undermines its own encryption, and browsers may block those resources or downgrade the padlock. Fix: update all resource URLs to HTTPS; the upgrade-insecure-requests directive in Content-Security-Policy can help during the transition.
“A padlock in the address bar does not always mean your encryption is sound. It means a certificate exists — nothing more.”
NyorsoftExternal Security Review
Where to fix it
- Shared hosting: most control panels offer free automatic certificates and a “force HTTPS” switch. Protocol and cipher settings are controlled by the host — if your scan shows old protocols, ask support to disable them.
- Cloudflare or another CDN: set the minimum TLS version to 1.2, enable “Always Use HTTPS”, and use the full/strict encryption mode so traffic between the CDN and your server is encrypted and verified too.
- Your own server: use a well-maintained configuration generator for Nginx or Apache with an “intermediate” profile, automated certificate renewal, and re-test after every change.
A 5-minute HTTPS health check
- Run a free SSL server test and note the grade.
- Confirm only TLS 1.2 and 1.3 are offered.
- Confirm the certificate covers every hostname you use and renews automatically.
- Type the
http://versions of your domain andwwwand confirm they redirect to HTTPS. - Check that the Strict-Transport-Security header is present.
TLS is one of the first areas we examine in a Public Website Security Check, together with headers, exposed files and email security. For a full picture, see our 15-point website security checklist.
Frequently asked questions
How do I check if my SSL/TLS configuration is secure?
Use a free online SSL server test, which grades your configuration and lists supported protocols, ciphers and certificate issues. Aim for TLS 1.2 and 1.3 only, a complete certificate chain, automatic renewal and HSTS.
What causes TLS errors on a website?
The most common causes are an expired certificate, a certificate that does not cover the hostname being visited, a missing intermediate certificate, or a server that only offers outdated protocols and ciphers. Less often, the cause is on the visitor’s side, such as a wrong system clock or antivirus software that intercepts HTTPS.
How do I fix a TLS handshake error?
Run an SSL server test against your domain to see which protocols, ciphers and certificates the server actually offers. Make sure TLS 1.2 and 1.3 are enabled, the full certificate chain is installed and any CDN or proxy in front of the site is set to a strict, verified encryption mode.
Should I disable TLS 1.0 and TLS 1.1?
Yes. Both are deprecated and no longer supported by modern browsers. Leaving them enabled adds risk without benefiting real visitors.
Is a free SSL certificate as secure as a paid one?
For encryption, yes. Free automated certificates use the same cryptography as paid ones. Paid certificates may add organisation validation or support, but they do not make the connection more secure.
What is an incomplete certificate chain?
It means the server sends your certificate without the intermediate certificate that links it to a trusted root. Some browsers compensate, but other clients fail with errors. Installing the full chain fixes it.
What is mixed content?
Mixed content occurs when an HTTPS page loads scripts, images or other resources over plain HTTP. It weakens the page’s security and browsers may block those resources.
Sources and further reading
- IETF RFC 8996: Deprecating TLS 1.0 and TLS 1.1 – the standard that formally retires the old protocol versions.
- NIST SP 800-52 Rev. 2 – US government guidelines for selecting and configuring TLS.
- Mozilla SSL Configuration Generator – recommended “modern” and “intermediate” server configurations for Apache, Nginx and others.
- Qualys SSL Labs: SSL Server Test – a free test that grades your HTTPS configuration.
- MDN: Strict-Transport-Security header – how HSTS works and how to set it.
Not sure what your website exposes?
Our Public Website Security Check looks at your site the way an attacker does — TLS, security headers, email authentication and exposed services — and gives you a short, ranked list of what to fix.
Pavol brings IT analysis experience from banking and financial-sector projects to Nyorsoft’s external security reviews for small businesses. About our team