How to remediate – SSL/TLS Certificate RSA Keys Less Than 2048 bits

1. Introduction

SSL/TLS Certificate RSA Keys Less Than 2048 bits refers to using SSL/TLS certificates with RSA keys shorter than 2048 bits for encrypting network traffic. This is a security weakness because smaller key sizes are easier to break, potentially allowing attackers to decrypt communications and impersonate servers. Systems affected include web servers, email servers, and any service using TLS encryption. A compromised certificate impacts confidentiality, integrity, and availability of data in transit.

2. Technical Explanation

The issue occurs when a server is configured with an SSL/TLS certificate that uses an RSA key length below the 2048-bit standard recommended by the CA/B Forum since January 1, 2014. Attackers can exploit this by attempting to decrypt intercepted traffic or by exploiting weaknesses in older implementations that don’t properly validate key strength. The preconditions are a vulnerable server and an attacker capable of intercepting network communications.

• Root cause: the use of RSA keys shorter than 2048 bits for SSL/TLS certificates.
• Exploit mechanism: An attacker intercepts encrypted traffic, then attempts to break the encryption using techniques like factoring attacks, which are easier with smaller key sizes.
• Scope: Web servers (Apache, Nginx, IIS), email servers, and any service utilising TLS 1.2 or earlier.

3. Detection and Assessment

You can confirm if a system is vulnerable by checking the certificate details and verifying the RSA key length. A quick check involves using a web browser to inspect the certificate.

• Quick checks: Use your browser’s developer tools (usually F12) to view the certificate chain for a website. Check the “Key Size” field; if it’s less than 2048 bits, the server is vulnerable.
• Scanning: OpenSSL can be used to scan certificates. Example command: openssl s_client -connect example.com:443 and inspect the certificate details in the output.
• Logs and evidence: Server logs may not directly indicate this issue, but monitoring for SSL renegotiation attempts or certificate errors could provide clues.

openssl s_client -connect example.com:443 | openssl x509 -noout -text

4. Solution / Remediation Steps

Replace the vulnerable certificate with one using an RSA key of 2048 bits or greater, and reissue any certificates signed by the old certificate.

4.1 Preparation

• Ensure you have a valid Certificate Signing Request (CSR) ready for generating the new certificate. Roll back involves restoring the original certificate files and restarting the service.
• A change window may be required depending on your environment, with approval from the security or infrastructure team.

4.2 Implementation

1. Step 1: Generate a new CSR using OpenSSL or your web server’s tools. Ensure it specifies at least a 2048-bit RSA key length.
2. Step 2: Submit the CSR to your Certificate Authority (CA) and request a new certificate.
3. Step 3: Download the newly issued certificate from your CA.
4. Step 4: Install the new certificate on your server, configuring it in your web server’s settings.
5. Step 5: Restart the web server service to apply the changes.

4.3 Config or Code Example

Before

# Example Apache configuration (vulnerable)
SSLCertificateFile /etc/ssl/certs/old_certificate.pem
SSLCertificateKeyFile /etc/ssl/private/old_key.pem

After

# Example Apache configuration (secure)
SSLCertificateFile /etc/ssl/certs/new_certificate.pem
SSLCertificateKeyFile /etc/ssl/private/new_key.pem

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue.

• Practice 1: Regular certificate audits ensure that certificates are valid and meet current standards, including key length requirements.
• Practice 2: Secure configuration management helps enforce consistent settings across servers, preventing the use of weak configurations.

4.5 Automation (Optional)

Ansible can automate certificate replacement.

---
- name: Replace SSL Certificate
  hosts: webservers
  tasks:
    - copy:
        src: /path/to/new_certificate.pem
        dest: /etc/ssl/certs/new_certificate.pem
        owner: root
        group: root
        mode: 0644
    - service: name=apache2 state=restarted

5. Verification / Validation

Confirm the fix by re-inspecting the certificate details in your web browser and verifying that the RSA key length is now at least 2048 bits.

• Post-fix check: Use your browser’s developer tools to view the new certificate chain. The “Key Size” field should show a value of 2048 or greater.
• Re-test: Run the OpenSSL command from step 3 again (openssl s_client -connect example.com:443 | openssl x509 -noout -text) and confirm that the key length is now at least 2048 bits.
• Smoke test: Verify that your website loads correctly and HTTPS connections are established without errors.
• Monitoring: Monitor server logs for SSL-related errors, particularly certificate validation failures.

openssl s_client -connect example.com:443 | openssl x509 -noout -text

6. Preventive Measures and Monitoring

Regularly update security baselines and incorporate checks into your CI/CD pipelines.

• Baselines: Update your server security baseline to require a minimum RSA key length of 2048 bits for all SSL/TLS certificates.
• Pipelines: Add static analysis tools (SAST) or automated configuration checks in your deployment pipeline to identify and reject configurations using weak keys.
• Asset and patch process: Implement a regular certificate review cycle, at least annually, to ensure compliance with current standards.

7. Risks, Side Effects, and Roll Back

Replacing the certificate may cause temporary service disruption if not done carefully.

• Risk or side effect 2: Compatibility issues with older clients that don’t support newer key exchange algorithms. Mitigation: Monitor for client compatibility issues and consider offering fallback options if necessary.
• Roll back: Restore the original certificate files (old_certificate.pem and old_key.pem) to their previous locations, then restart the web server service.

8. References and Resources

• Vendor advisory or bulletin: Check your CA’s documentation for specific guidance on key length requirements.
• NVD or CVE entry: CWE-326
• Product or platform documentation relevant to the fix: Refer to your web server’s documentation for instructions on installing and configuring