Common TLS Certificate and Handshake Errors: What They Mean and How to Fix Them

Note: Although the modern protocol is Transport Layer Security (TLS), the industry still commonly refers to TLS certificates as “SSL certificates.”

TLS errors can be frustrating because browsers often reduce a complex certificate or handshake failure to a short message such as “Your connection is not private” or “SSL protocol error.”

The important thing to understand is that these errors do not all mean the same thing. An expired certificate requires a different fix from a hostname mismatch, an incomplete certificate chain, or a TLS protocol negotiation failure.

In this guide, we’ll explain the most common TLS certificate and handshake errors, what causes them, and the practical steps you can take to fix them.

1. Understanding Common TLS Certificate and Handshake Errors

TLS establishes an encrypted connection while allowing the client to verify the identity of the server. During the TLS handshake, the client validates the server’s certificate, builds a chain of trust, and negotiates compatible protocol and cryptographic parameters.

When one of these checks fails, the browser or other TLS client may terminate the connection and display an error.

Expired TLS Certificate

An expired certificate has passed the end of its validity period. Browsers and other clients will generally reject it rather than establish a connection that cannot be validated as currently trusted.

As public certificate lifetimes continue to shrink to 47 days by 2029, failed renewals are becoming an increasingly important operational risk. The solution is to automate certificate renewal and make sure renewed certificates are actually deployed to every relevant server, load balancer, CDN, and other TLS endpoint.

TLS Certificate Not Trusted

A certificate can be rejected because the client cannot establish a trusted certification path.

Common causes include:

• A self-signed certificate being used where public trust is required
• An unknown or untrusted root CA
• An incomplete certificate chain
• A private CA that is not installed in the client’s trust store
• Certificate revocation
• CA distrust or other certificate-policy failures

For example, major browsers have previously removed trust in certificates associated with the Symantec CA infrastructure following serious compliance and security concerns.

Domain Name Mismatch

A hostname mismatch occurs when the hostname requested by the client does not match a DNS name listed in the certificate’s Subject Alternative Name (SAN) extension.

For example, a certificate issued for www.example.com does not normally authenticate api.example.com unless that hostname is also covered by the certificate.

The fix is to obtain or configure a certificate containing all required hostnames and make sure the correct certificate is presented for each hostname.

Incomplete Certificate Chain

Public TLS certificates are normally issued through an intermediate CA rather than directly from a trusted root CA. The server therefore needs to provide the certificate chain necessary for the client to connect the website certificate to a trusted root.

If a server sends only the leaf certificate and omits a required intermediate certificate, some clients may be unable to build a valid trust path and will reject the connection.

The usual fix is to configure the server with the leaf certificate followed by the required intermediate certificates supplied by the CA.

The trusted root certificate generally does not need to be sent by the server because clients maintain their own trusted root stores.

TLS Protocol or Cipher-Suite Mismatch

Not every TLS error is strictly a certificate error. A connection can also fail because the client and server cannot agree on a compatible TLS protocol version or cipher suite.

For example, modern clients may reject servers that support only obsolete TLS versions or cryptographic algorithms. Conversely, a server configured to require TLS 1.3 may prevent older clients that do not support TLS 1.3 from connecting.

Browser messages such as ERR_SSL_VERSION_OR_CIPHER_MISMATCH can therefore indicate a TLS negotiation problem rather than a problem with the certificate itself.

2. How to Fix Common TLS Errors

Because different TLS errors have different causes, the first step is to identify exactly which part of the TLS connection is failing.

Fixing an Expired Certificate

Check the certificate’s Not Before and Not After validity dates and confirm that the certificate currently deployed to the production endpoint is the renewed one. You can use Free SSL Certificate tool or use OpenSSL

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -dates

If the certificate has expired:

1. Renew or reissue the certificate.
2. Install the new certificate on the relevant server, load balancer, CDN, or reverse proxy.
3. Reload or restart the service if required.
4. Verify that the new certificate is actually being served to clients.
5. Confirm that all redundant or geographically distributed endpoints have been updated.

Automated renewal is preferable to manual renewal because it reduces the risk of an otherwise preventable expiration outage.

Fixing an Untrusted Certificate

Start by determining why the client does not trust the certificate.

Check whether:

• the certificate was self-signed.
• the issuing CA is trusted by the client.
• the certificate chain contains all required intermediates.
• the certificate has been revoked.
• the client itself has an outdated or incorrectly configured trust store.

For a public website, use a certificate issued by a CA trusted by the target clients. For an internal application, make sure the organization’s private root CA is correctly distributed to the clients that need to trust it.

Fixing a Domain Name Mismatch

Verify the hostname the client is requesting and compare it with the certificate’s Subject Alternative Name (SAN) entries.

If the hostname is missing:

1. Obtain a certificate containing the required hostname.
2. Install the correct certificate on the appropriate TLS endpoint.
3. Make sure the server selects that certificate when the hostname is requested.
4. Test both the canonical hostname and any aliases that users may access.

When multiple websites share the same IP address, verify that Server Name Indication (SNI) is configured correctly. SNI allows a client to identify the hostname it wants during the TLS handshake so that the server can select the appropriate certificate.

SNI does not itself fix a certificate mismatch. The certificate must still contain the requested hostname.

Fixing an Incomplete Certificate Chain

Download the correct certificate-chain bundle from your CA and configure the server to present:

1. the website’s leaf certificate; and
2. the required intermediate certificate or certificates.

Do not normally append the root certificate to the server’s certificate chain. The root should already exist in the client’s trust store.

After updating the configuration, test the endpoint from multiple client environments. A chain that works on one operating system or browser may still expose problems for another client if the server is relying on certificates that are not universally available.

Fixing TLS Protocol or Cipher-Suite Errors

Review the server’s TLS configuration and compare the protocols and cipher suites it offers with those supported by the client.

Disable obsolete TLS versions and legacy cryptographic algorithms where they are no longer required.

For TLS 1.2 and earlier, cipher-suite configuration is an important part of the server’s security posture. Modern authenticated-encryption suites such as AES-GCM and ChaCha20-Poly1305 are preferred over obsolete algorithms.

TLS 1.3 uses a different and much more limited cipher-suite model, so configuration directives designed for older TLS versions should not automatically be applied to TLS 1.3.

The objective is to support modern clients securely while retaining only the compatibility that the application actually requires.

3. Preventing TLS Certificate and Handshake Problems

Fixing an individual TLS error is important, but preventing the next one is even more valuable. Reliable TLS operations depend on automation, consistent configuration, and independent verification.

Automate Certificate Renewal and Deployment

Manual certificate renewal becomes increasingly risky as certificate lifetimes get shorter.

For many environments, the ACME (Automated Certificate Management Environment) protocol provides a straightforward way to automate certificate issuance and renewal. Automated Certificate Authorities such as Let’s Encrypt support ACME and can issue certificates without the manual workflow traditionally associated with commercial certificates.

Cloud platforms and CDNs can also manage certificates automatically. These services can greatly reduce the risk of expiration and deployment errors, although automation does not eliminate every possible failure mode.

Organizations with large or complex certificate estates may additionally use Certificate Lifecycle Management (CLM) platforms to inventory certificates, enforce policies, coordinate renewals, and provide centralized visibility.

A dedicated CLM platform is not necessarily required for every environment. The important requirement is reliable automation and visibility across the certificate lifecycle.

Monitor the Certificates Actually Being Served

Certificate monitoring should not stop at checking when a certificate expires.

An effective monitoring system should verify the certificate that is actually presented to users and can check:

• expiration dates.
• hostname and SAN coverage.
• certificate-chain completeness.
• trust-path validity.
• TLS protocol compatibility.
• certificate consistency across multiple endpoints.
• relevant revocation information.

This distinction matters because a certificate may have been successfully renewed but never deployed to the production endpoint.

Use Independent TLS Monitoring

Even when certificate issuance and renewal are automated, failures can still occur. DNS changes, API failures, deployment problems, configuration errors, rate limits, and other infrastructure issues can prevent a renewed certificate from reaching the production endpoint.

Independent TLS monitoring provides an additional layer of protection. Rather than relying exclusively on the same infrastructure responsible for renewal, an external monitoring system can periodically verify the certificates actually being served to users.

Alerts can notify engineering or operations teams through email, Slack, SMS, or incident-management systems when a certificate is approaching expiration or when a renewal or deployment process has failed.

Understand Certificate Revocation

When a certificate is compromised or otherwise needs to be invalidated before its normal expiration date, the issuing CA can revoke it.

Historically, clients could use mechanisms such as the Online Certificate Status Protocol (OCSP) to obtain revocation information. With OCSP stapling, the server can provide a CA-signed OCSP response during the TLS handshake rather than requiring the client to contact the CA directly.

The revocation landscape is evolving. Let’s Encrypt discontinued its OCSP service in 2025 and moved to publishing revocation information exclusively through Certificate Revocation Lists (CRLs).

This change is specific to Let’s Encrypt rather than a universal rule for every CA. Organizations should understand the revocation mechanisms used by their particular CA and TLS ecosystem.

4. Troubleshooting TLS Errors Systematically

When a TLS error occurs in production, troubleshooting is easier when the investigation follows a consistent sequence.

Step 1: Check the Certificate

Inspect the certificate currently being served and verify:

• the expiration date.
• the subject and SAN entries.
• the issuing CA.
• the certificate chain.
• the certificate currently deployed to the production endpoint.

Step 2: Check the Hostname

Confirm that the hostname users are accessing is covered by the certificate.

Pay particular attention to:

• example.com versus www.example.com
• subdomains such as api.example.com
• wildcard certificates.
• alternate domains.
• redirects between HTTP and HTTPS hostnames.

Step 3: Check the Certificate Chain

Verify that the server is returning the required intermediate certificates and that clients can build a trusted path to an appropriate root CA.

A chain problem can behave differently across browsers and operating systems because trust stores are not identical.

Step 4: Check TLS Compatibility

If the certificate itself appears valid, investigate the TLS handshake.

Check the supported:

• TLS versions.
• cipher suites.
• elliptic curves and key-exchange parameters where applicable.
• other server-side TLS settings.

Step 5: Check Every Production Endpoint

Do not assume that every server is configured identically.

A website may terminate TLS at multiple locations, including:

• CDNs.
• load balancers.
• reverse proxies.
• web servers.
• API gateways.
• regional or failover infrastructure.

A certificate can be correct on one endpoint and expired or misconfigured on another.

Conclusion

TLS errors are not all the same. An expired certificate, untrusted certificate, hostname mismatch, incomplete certificate chain, and TLS protocol negotiation failure each have different causes and require different fixes.

The most effective troubleshooting approach is therefore to identify the specific validation or handshake step that failed, then address that layer rather than treating every browser warning as a generic “SSL problem.”

Longer term, the best defense is automation. Certificate issuance, renewal, deployment, validation, and monitoring should be treated as part of the normal operational lifecycle of every TLS-enabled service.

With automated certificate management, correctly configured certificate chains, modern TLS settings, and independent monitoring, organizations can significantly reduce the risk of certificate-related outages and maintain secure, reliable TLS connections.