1. Home
  2. Web App Vulnerabilities
  3. How to remediate – SSL/TLS Certificate Lifetime Greater Than 398 Days
Searching...

How to remediate – SSL/TLS Certificate Lifetime Greater Than 398 Days

Contents

1. Introduction

2. Technical Explanation

  • Exploit mechanism: A user with an affected browser attempts to connect to a server using the vulnerable certificate and receives a connection error or warning, potentially leading them to avoid the site.

3. Detection and Assessment

You can check certificate details using OpenSSL or your browser’s developer tools. Thorough assessment involves checking all public-facing certificates.

  • Quick checks: Use the following command to view a certificate’s expiry date: openssl x509 -in certificate.pem -noout -dates
  • Scanning: Qualys SSL Labs (https://www.ssllabs.com/ssltest/) can identify certificates with long lifetimes as part of a broader SSL assessment.
  • Logs and evidence: Web server logs may show connection errors related to certificate validation failures, though this is not specific to this issue.
openssl x509 -in certificate.pem -noout -dates

4. Solution / Remediation Steps

Replace the existing certificate with a new one having a validity period of 398 days or less.

4.1 Preparation

  • Ensure you have access to your Certificate Authority (CA) account and can generate a new Certificate Signing Request (CSR). A roll back plan is to restore the original certificate and restart the service.
  • Change windows may be required for production systems, with approval from the security team or system owner.

4.2 Implementation

  1. Step 1: Generate a new Certificate Signing Request (CSR) using your web server’s tools (e.g., `openssl req -newkey rsa:2048 -nodes -keyout key.pem -out csr.pem`).
  2. Step 2: Submit the CSR to your CA and obtain a signed certificate.
  3. Step 3: Install the new certificate on your web server, configuring it with the correct private key.
  4. Step 4: Restart the web server service to apply the changes.

4.3 Config or Code Example

Before

# Example Apache configuration (may vary)
SSLCertificateFile /path/to/old_certificate.pem

After

# Example Apache configuration (may vary)
SSLCertificateFile /path/to/new_certificate.pem

4.4 Security Practices Relevant to This Vulnerability

Regular certificate renewal is a key security practice. Maintaining an up-to-date inventory of certificates and automating the renewal process can help prevent this issue.

  • Practice 1: Implement a robust certificate management process, including automated renewals where possible.
  • Practice 2: Regularly review your server configuration to ensure all certificates are valid and properly configured.

4.5 Automation (Optional)

Let’s Encrypt with Certbot can automate certificate issuance and renewal. This example assumes a basic Linux setup.

# Install Certbot
sudo apt update
sudo apt install certbot python3-certbot-apache
# Obtain and install a certificate for your domain
sudo certbot --apache -d yourdomain.com

5. Verification / Validation

Confirm the new certificate is installed correctly and has a validity period of 398 days or less. Test connectivity from affected browsers.

  • Post-fix check: Use `openssl x509 -in certificate.pem -noout -dates` to verify the expiry date is within the acceptable range.
  • Re-test: Run the initial OpenSSL command again to confirm the new certificate has a shorter validity period.
  • Smoke test: Access your website via HTTPS from multiple browsers, including those known to be affected by the long-certificate issue (e.g., older versions of Safari).
openssl x509 -in certificate.pem -noout -dates

6. Preventive Measures and Monitoring

For example, update your security baselines to include a maximum certificate validity period of 398 days. Implement automated monitoring to alert on certificates nearing expiry or exceeding the limit.

  • Baselines: Update server hardening guides or configuration policies to enforce a maximum certificate lifetime of 398 days.
  • Pipelines: Integrate certificate validation checks into your CI/CD pipeline to prevent deployment of servers with long-lived certificates.
  • Asset and patch process: Review all TLS certificates quarterly as part of regular security assessments.

7. Risks, Side Effects, and Roll Back

Replacing a certificate can cause brief service interruption if not handled carefully. Incorrect configuration may lead to connection errors or SSL warnings. A roll back involves restoring the original certificate.

  • Risk or side effect 1: Brief service downtime during certificate replacement. Mitigation: Perform the change during off-peak hours and test thoroughly in a staging environment first.
  • Risk or side effect 2: Incorrect configuration leading to SSL errors. Mitigation: Double-check all configuration settings and use a tool like Qualys SSL Labs to verify the installation.
  • Roll back: 1) Stop the web server service. 2) Restore the original certificate file. 3) Restart the web server service.

8. References and Resources

  • Vendor advisory or bulletin: Not applicable – this is a general industry issue.
  • NVD or CVE entry: Not applicable – no specific CVE for this configuration issue.
  • Product or platform documentation relevant to the fix: https://blog.mozilla.org/security/2020/07/09/reducing-
Updated on December 27, 2025

Was this article helpful?

Yes No

Related Articles