Expired or Invalid SSL/TLS Certificate

SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration
SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration

All Entries

Scan Your Site

Check your website for this issue

Run an automated scan and see whether your site is affected — with plain-language findings and fixes.

Start Scanning
Category Cryptographic / Transport Layer Misconfiguration
Typical Severity High
OWASP A02:2021 – Cryptographic Failures; A05:2021 – Security Misconfiguration
CWE CWE-297 – Improper Validation of Certificate with Host Mismatch; CWE-298 – Improper Validation of Certificate Expiration; CWE-295 – Improper Certificate Validation
Also known as Untrusted Certificate, Self-Signed Certificate Warning, Certificate Expiry Error, TLS Certificate Mismatch
Affected systems Any HTTPS-enabled web server, API endpoint, mail server (STARTTLS/SMTPS), load balancer, or CDN terminating TLS
Relevant standards RFC 5280 (X.509 PKI), RFC 8446 (TLS 1.3), CA/Browser Forum Baseline Requirements

Overview

SSL/TLS certificates are X.509 digital documents issued by a Certificate Authority (CA) that bind a public key to an identity (typically a domain name or organisation). They underpin the authentication and encryption provided by HTTPS and other TLS-protected protocols.

A certificate becomes invalid for one or more of the following reasons:

  • Expiration: Every certificate has a notAfter field; once the current date exceeds it, the certificate is expired. As of 2020, the CA/Browser Forum mandates a maximum validity of 398 days for publicly trusted certificates.
  • Hostname mismatch: The Subject Alternative Name (SAN) or Common Name (CN) does not match the domain the client is connecting to (e.g., certificate issued for www.example.com used on api.example.com).
  • Untrusted issuer: The certificate is self-signed or issued by a CA not present in the client's trust store.
  • Revocation: The CA has revoked the certificate via CRL or OCSP before its stated expiry date, typically due to key compromise or mis-issuance.
  • Weak or broken cryptography: The certificate uses deprecated signature algorithms (e.g., MD5, SHA-1) or insufficient key sizes (e.g., RSA-1024) that modern clients reject.

Sensagraph continuously scans HTTPS endpoints and flags certificates that are expired, expiring soon, mismatched, self-signed, or otherwise untrusted.

How it works

During the TLS handshake, the server presents its certificate chain to the client. The client (browser, API consumer, mobile app) performs a series of validation checks before establishing the encrypted session:

  1. Chain validation: Each certificate in the chain must be signed by the next, terminating at a trusted root CA in the client's trust store.
  2. Validity period check: The client compares the current time against the certificate's notBefore and notAfter fields.
  3. Hostname verification: The client matches the server's hostname against the SAN extension (or CN as a fallback, though this is deprecated per RFC 6125).
  4. Revocation check: If OCSP stapling or CRL distribution points are configured, the client may verify the certificate has not been revoked.

When any check fails, modern browsers display a blocking interstitial warning (NET::ERR_CERT_DATE_INVALID, NET::ERR_CERT_COMMON_NAME_INVALID, etc.) and prevent the user from loading the page without an explicit bypass. Non-browser clients (mobile apps, microservices) may either reject the connection outright or, critically, be misconfigured to skip validation entirely — creating a silent vulnerability.

  • An attacker positioned on the network (MITM) can present a fraudulent certificate; without valid certificate pinning or CA trust, the client has no mechanism to detect the substitution when validation is disabled.
  • Expired certificates do not inherently break encryption, but they signal to clients that the operator cannot be trusted to manage infrastructure, and browsers will block the connection.
  • Wildcard certificates (*.example.com) cover only one subdomain level; using them for deeper subdomains causes a hostname mismatch.

Business impact

An expired or invalid certificate has immediate and compounding consequences:

  • Service disruption: Browsers block access entirely, rendering the site or API unreachable for users who do not manually override the warning — most will not.
  • Data interception risk: In environments where certificate validation is suppressed (e.g., misconfigured mobile apps or internal services), encrypted traffic can be intercepted and decrypted by a MITM attacker.
  • Regulatory and compliance exposure: PCI DSS (Requirement 4), HIPAA, and GDPR all require protection of data in transit. An invalid certificate constitutes a control failure and can result in fines or audit findings.
  • Reputational damage: Browser warnings erode user trust instantly. Studies show the vast majority of users abandon sites displaying certificate errors, associating them with phishing or compromise.
  • Search engine impact: Search engines deprioritise or delist sites with persistent HTTPS errors.
  • Supply chain risk: Third-party integrations (payment processors, identity providers) may reject connections from services presenting invalid certificates, causing cascading failures.

How to fix it

  1. Renew the certificate immediately if it is expired or within 30 days of expiry. For publicly trusted domains, use an ACME-compatible CA (e.g., Let's Encrypt) or a commercial CA. Let's Encrypt certificates are free and valid for 90 days with automated renewal.
  2. Automate certificate lifecycle management. Use ACME clients (Certbot, acme.sh, cert-manager for Kubernetes) to automate issuance and renewal. Set renewal to trigger at 60–30 days before expiry. Never rely solely on manual processes.
  3. Correct hostname mismatches by ensuring the certificate's SAN list includes every hostname the service is accessed under. Issue a new certificate with the correct SANs or add the missing domain to the existing certificate scope.
  4. Replace self-signed certificates in production with certificates issued by a publicly trusted CA. Reserve self-signed certificates only for isolated development or internal-only environments where every client's trust store is explicitly managed.
  5. Implement monitoring and alerting. Track certificate expiry dates across all endpoints. Configure alerts at 60, 30, and 7 days before expiry. Tools such as Prometheus with the blackbox exporter, or dedicated certificate monitoring services, can automate this.
  6. Enable OCSP Stapling on your web server (Nginx: ssl_stapling on;, Apache: SSLUseStapling on) to allow clients to efficiently check revocation status without querying the CA directly.
  7. Use strong cryptography. Issue certificates with RSA-2048 or RSA-4096 (minimum), or ECDSA P-256/P-384. Use SHA-256 or stronger for the signature algorithm. Avoid SHA-1, MD5, and RSA key sizes below 2048 bits.
  8. Audit internal/private CAs. For internal services using a private CA, ensure every consuming client's trust store includes the private root CA certificate and that the private CA's own certificates do not expire unnoticed.
  9. Enforce certificate validation in all clients. Audit application code to ensure TLS certificate validation is not disabled (e.g., verify=False in Python requests, rejectUnauthorized: false in Node.js). These disablements should never reach production.

References

Frequently asked questions

Not necessarily. An expired certificate means the cryptographic trust relationship has lapsed, causing browsers to block access with an error. It does not by itself indicate an active attack, but it removes a key protection that would allow clients to detect a man-in-the-middle attack. The risk of interception exists for any clients that bypass or ignore the certificate error.

Most modern browsers display a full-page blocking warning (e.g., NET::ERR_CERT_DATE_INVALID in Chrome) and require users to manually click through an 'Advanced' bypass — which many users will not do. API clients and non-browser applications will typically fail with a connection error unless they have been explicitly configured to ignore certificate validation errors.

An expired certificate was once issued by a trusted CA but has passed its notAfter date. A self-signed certificate was never issued by a trusted CA — it was signed by its own private key — so it is untrusted from the moment it is presented to any standard client. Both cause trust failures, but for different reasons.

The CA/Browser Forum caps publicly trusted certificate validity at 398 days. Let's Encrypt certificates are valid for 90 days and should be renewed every 60 days using automated tooling. Best practice is to automate renewal and alert when certificates are within 30 days of expiry to allow time to resolve any automation failures.

It can be acceptable if every client that connects to the service has the self-signed certificate's CA explicitly added to its trust store, and if the certificate and its private key are properly protected. However, managing this manually at scale is error-prone. A better approach for internal services is to operate a private internal CA (e.g., using HashiCorp Vault PKI or cfssl) and distribute the private root CA certificate to all internal clients.

Online Certificate Status Protocol (OCSP) stapling allows a web server to proactively include a signed, time-stamped OCSP response from the CA in the TLS handshake, proving the certificate has not been revoked. Without stapling, the client must contact the CA's OCSP responder directly, which adds latency and a privacy concern. Stapling is supported in Nginx, Apache, and most modern web servers and should be enabled alongside certificate deployment.