Fix TLS Certificate Expired or Not Yet Valid Error (2026)

The TLS handshake is failing because the server’s certificate isn’t trusted by the client, either because it’s expired or its validity period hasn’t started yet.

Common causes and fixes:

1. Clock Skew on Server:

• Diagnosis: Check the server’s system time. On Linux, run date. On Windows, check the clock settings. Compare it to a reliable time source like time.google.com.
• Fix: Synchronize the server’s clock using NTP. For Linux, ensure ntpd or chrony is running and configured. For example, with chrony, edit /etc/chrony.conf and add server time.google.com iburst. Then restart the service: sudo systemctl restart chronyd.
• Why it works: TLS certificates have strict NotBefore and NotAfter dates. If the server’s clock is significantly off, it can appear as if the certificate is not yet valid or has already expired.

2. Clock Skew on Client:

• Diagnosis: Check the client’s system time. This could be the user’s workstation, a load balancer, or another service trying to connect. Use date on Linux or check system clock settings on Windows.
• Fix: Synchronize the client’s clock using NTP. Ensure NTP clients are running and configured correctly on all connecting machines or devices.
• Why it works: The client also validates the certificate against its own system time. If the client’s clock is too far ahead or behind, it will incorrectly assess the certificate’s validity period.

3. Certificate Not Yet Valid (NotBefore in the future):

• Diagnosis: Examine the certificate’s NotBefore date. Use openssl x509 -in /path/to/your/certificate.crt -noout -dates.
• Fix: If the NotBefore date is in the future, you must wait until that date to use the certificate. If you need immediate use, you’ll need to re-issue the certificate with a NotBefore date set to the current time or earlier. Contact your Certificate Authority (CA) to request a new certificate.
• Why it works: The NotBefore field specifies the earliest point in time the certificate is valid. Attempting to use it before this time will result in an error.

4. Certificate Expired (NotAfter in the past):

• Diagnosis: Examine the certificate’s NotAfter date. Use openssl x509 -in /path/to/your/certificate.crt -noout -dates.
• Fix: Obtain a new certificate from your CA before the current one expires. Most CAs allow renewal before expiration, and the new certificate will typically have a NotBefore date set to the current time and a future NotAfter date.
• Why it works: The NotAfter field defines the latest point in time the certificate is valid. Once this date has passed, the certificate is no longer trusted.

5. Intermediate Certificate Chain Missing or Incorrect:

• Diagnosis: Use an online SSL checker tool (e.g., SSL Labs’ SSL Test) or openssl s_client -connect your.domain.com:443 -servername your.domain.com. Look for "verify error" messages related to "unable to get local issuer certificate" or "certificate chain not trusted."
• Fix: Ensure your web server is configured to serve the full certificate chain, including intermediate certificates. The order matters: usually, the server’s certificate comes first, followed by the intermediate(s), then the root (though the root is often not needed if it’s in the client’s trust store). For Apache, this is SSLCertificateChainFile or SSLCertificateFile containing the full chain. For Nginx, it’s ssl_certificate directive pointing to a file with the server cert and then intermediates.
• Why it works: Clients need to verify the authenticity of your server certificate by tracing it back to a trusted root CA. If intermediate certificates are missing, the client cannot complete this chain of trust.

6. Incorrect Certificate/Key Pair in Server Configuration:

• Diagnosis: Manually inspect the certificate and key files referenced in your web server’s SSL configuration. For example, in Apache, check SSLCertificateFile and SSLCertificateKeyFile directives in your virtual host configuration. In Nginx, check ssl_certificate and ssl_certificate_key. Ensure the files exist and have correct read permissions for the web server process.
• Fix: Correct the configuration to point to the actual, valid certificate and its corresponding private key. If you’ve recently renewed a certificate, ensure you’ve updated the server configuration to use the new file paths or content. Restart your web server (e.g., sudo systemctl restart apache2 or sudo systemctl restart nginx).
• Why it works: The server might be serving an old, expired, or even a completely different certificate if the configuration points to the wrong file or if the file itself is corrupted.

7. Certificate Revocation (CRL/OCSP Issues):

• Diagnosis: While less common for simple "expired" errors, a revoked certificate can sometimes manifest as trust issues. Check server logs for any messages related to Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP) checks.
• Fix: If the certificate has been revoked by the CA, you must obtain a new one. If the server is having trouble reaching the CA’s CRL distribution point or OCSP responder (e.g., due to network firewall rules), you may need to adjust firewall rules to allow access to these URLs.
• Why it works: Certificate revocation means the CA has invalidated the certificate before its expiry date. Clients will refuse to trust a revoked certificate.

The next error you’ll likely encounter after fixing these is a NET::ERR_CERT_COMMON_NAME_INVALID if the certificate’s Subject Alternative Name (SAN) or Common Name (CN) does not match the hostname you are accessing.