How to remediate – SSL Certificate Signed Using SHA-1 Algorithm

1. Introduction

An SSL certificate signed using the SHA-1 algorithm presents a security risk. This means a website’s digital identity may be vulnerable to attackers creating fake certificates. Systems affected are typically web servers and any service presenting an SSL/TLS certificate, including email servers and VPN gateways. A successful attack could compromise confidentiality, integrity, and availability of services by allowing man-in-the-middle attacks.

2. Technical Explanation

The vulnerability occurs because SHA-1 is a cryptographically weak hashing algorithm. It’s susceptible to collision attacks where an attacker can create two different inputs that produce the same hash value. This allows them to forge certificates signed with a compromised or valid certificate authority (CA). An attacker could then present this fake certificate to users, appearing as legitimate. The plugin reports certificates expiring between January 1, 2016 and December 31, 2016 due to Google’s SHA-1 sunsetting policy.

• Root cause: Use of the SHA-1 hashing algorithm for certificate signing.
• Exploit mechanism: An attacker generates a rogue certificate with the same hash as a legitimate one and presents it during an SSL/TLS handshake.
• Scope: Web servers, email servers, VPN gateways using certificates signed with SHA-1.

3. Detection and Assessment

• Quick checks: Use OpenSSL to inspect the certificate chain. Run openssl s_client -showcerts <hostname>:443 and look for SHA1 in the certificate details.
• Scanning: Nessus plugin ID 62895 can identify certificates signed with SHA-1. Other vulnerability scanners may have similar checks.
• Logs and evidence: Examine web server logs for SSL handshake events. Look for certificate errors related to SHA-1 validation failures, though these are not always logged.

openssl s_client -showcerts example.com:443

4. Solution / Remediation Steps

These steps detail how to fix the issue by replacing SHA-1 certificates with newer ones.

4.1 Preparation

• Ensure you have a valid replacement certificate signed using SHA-256 or higher. A roll back plan is to restore the original backup certificate.
• Change windows should be planned during off peak hours and require approval from security teams.

4.2 Implementation

1. Step 1: Obtain a new SSL certificate signed with SHA-256 or higher from a trusted Certificate Authority.
2. Step 2: Stop the web server service (e.g., Apache, Nginx, IIS).
3. Step 3: Replace the old SSL certificate files with the new ones in the appropriate directory (e.g., /etc/ssl/certs/).
4. Step 4: Restart the web server service.

4.3 Config or Code Example

Before

SSLEngine on
SSLCertificateFile /etc/ssl/certs/old_certificate.pem
SSLCertificateKeyFile /etc/ssl/private/old_key.pem

After

SSLEngine on
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 and similar vulnerabilities.

• Practice 1: Patch cadence – Regularly update software, including web servers and SSL libraries, to benefit from the latest security fixes.

4.5 Automation (Optional)

If using configuration management tools like Ansible, you 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
    - service:
        name: apache2 # or nginx, iis etc.
        state: restarted

5. Verification / Validation

Confirm the fix by checking the new certificate and performing a smoke test.

• Post-fix check: Run openssl s_client -showcerts <hostname>:443 again. The output should show SHA256 as the signature algorithm, not SHA1.
• Re-test: Re-run the Nessus scan (plugin ID 62895) to confirm the vulnerability is no longer detected.
• Smoke test: Access the website via HTTPS and verify it loads correctly without certificate errors.
• Monitoring: Monitor web server logs for any SSL handshake failures or certificate validation issues.

openssl s_client -showcerts example.com:443 | grep SHA256

6. Preventive Measures and Monitoring

Update security baselines and add checks to your CI/CD pipeline to prevent this issue in the future.

• Baselines: Update security baselines (e.g., CIS benchmarks) to require SHA-256 or higher for SSL certificates.
• Pipelines: Add Static Application Security Testing (SAST) tools to your CI/CD pipeline to scan code and configuration files for insecure settings, including the use of SHA-1.
• Asset and patch process: Review certificate configurations during regular security audits.

7. Risks, Side Effects, and Roll Back

Replacing certificates can cause brief service interruptions. Always have a roll back plan.

• Risk or side effect 1: Service interruption during certificate replacement. Mitigation: Schedule changes during off-peak hours.
• Roll back: 1) Restore the original SSL certificate files. 2) Restart the web server service.

8. References and Resources

• Vendor advisory or bulletin: https://blog.chromium.org/2014/09/gradually-sunsetting-sha-1.html
• NVD or CVE entry: Not applicable for this informational report.
• Product or platform documentation relevant to the fix: https://tools.ietf.org/html/rfc3279