Name in API: tlscert_excessive_expiration
Breach Risk: Low
Factor: Network Security
Summary
This issue type refers to a problem where a TLS (Transport Layer Security) certificate has an excessively long expiration period. Industry best practices, dictated by the CA/B Forum, now limit TLS certificates to a maximum validity of 398 days (roughly 13 months). However, older or misconfigured certificates may have more extended expiration periods, sometimes 3–10 years, which triggers a finding under this issue type.
How Does It Work?
This issue occurs when a TLS/SSL certificate has an expiration period exceeding industry standards of 398 days. Long-lived certificates pose security risks, including outdated encryption and delayed key rotation. Security scanners detect such issues, and the fix involves replacing certificates with shorter validity and automating renewals using tools like Let’s Encrypt or AWS ACM.
- Websites use TLS certificates to encrypt data between a web server and a user’s browser.
- Example: When you visit https://example.com, your browser checks the site's TLS certificate to verify security.
Why Is It a Risk?
A TLS certificate with an excessive expiration period increases security risks because Long-lived certificates raise the chances of private key compromise, outdated, cryptographic algorithms, and non-compliance with browser security standards. They also delay updates, making sites vulnerable to attacks like MITM and phishing. Modern browsers reject certificates older than 398 days to ensure security.
Self Evaluation
You may validate the presence/absence of the expired certificate on the endpoint by using the following 3rd Party tools. All can be used to confront contradictory results. However, when comparing results, ensure that the endpoint scanned by each is the same information and matches the SecurityScorecard finding.
Sslscan
sslscan example.com
sslscan 1.11.14
OpenSSL 1.1.1
Testing SSL server example.com on port 443
Supported Server Cipher(s):
[+] TLSv1.2 256 bits TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
[+] TLSv1.3 128 bits TLS_AES_128_GCM_SHA256
Certificate Information:
Subject: CN=example.com
Issuer: CN=Example CA
Valid From: Jan 1 00:00:00 2022 GMT
Valid To: Jan 1 00:00:00 2032 GMT
[WARNING] Certificate validity exceeds 398 days (10 years)
[WARNING] Potential security risk – consider reissuing with a shorter expiration period
Website Certificate
Nmap
nmap --script ssl-cert -p 443 example.com
| ssl-cert:
| Subject: commonName=example.com
| Issuer: commonName=Example CA
| Validity:
| Not valid before: 2022-01-01T00:00:00
| Not valid after: 2032-01-01T00:00:00
|_ [WARNING] Certificate validity exceeds 398 days
How to mitigate
- Obtain a new certificate from a trusted Certificate Authority (CA) with a maximum validity of 398 days
- Use Let's Encrypt or similar providers for certificates with shorter expiration periods (e.g., 90 days)
- Enable automatic renewal using tools like:
-
Certbot (for Let’s Encrypt).
-
AWS Certificate Manager (ACM).
-
Cloudflare SSL/TLS Auto-Renewal.
-
Microsoft Active Directory Certificate Services (AD CS) (for internal certificates).
-
- Define security policies ensuring:
- No certificate has a validity exceeding 398 days.
Remediation
- The endpoint configuration has changed, causing the tlscert_excessive_expiration finding to appear. => Select the finding and then click on the "Fixed" button, "technical_remediation."
- The endpoint has been closed and therefore the endpoint is unreachable (no responses)
=> Select the finding and then click on the "Fixed" button, "technical_remediation". - After verification (using the methods above, for example), the exact endpoint defined in the finding does have a certificate with a validity of less than 398 days and is contrary to what SecurityScorecard is stating. => Select the finding and then click on "Other resolutions" --> "I cannot reproduce this issue, and I think it’s incorrect," "false_positive."