How to remediate – SSL Certificate Cannot Be Trusted

1. Introduction

The SSL Certificate Cannot Be Trusted vulnerability means a website’s security certificate isn’t properly verified by your computer or browser. This happens when there’s a problem with how the certificate was issued, is configured, or has expired. It affects web servers and any services using HTTPS. A broken trust chain can allow attackers to intercept communications, compromising confidentiality, integrity, and availability of data exchanged with the server.

2. Technical Explanation

This vulnerability occurs because the server presents an SSL certificate that your system doesn’t recognise as trustworthy. This usually means there’s a problem in the chain of certificates used to verify the server’s identity. An attacker could exploit this by performing a man-in-the-middle attack, intercepting and potentially modifying data sent between users and the server. The preconditions for exploitation are that a user attempts to connect to the affected service using HTTPS, and their system is unable to validate the certificate chain.

• Root cause: The server’s X.509 certificate chain is invalid, either due to an unknown Certificate Authority (CA), expired certificates, or signature verification failure.
• Exploit mechanism: An attacker intercepts HTTPS traffic and presents a fraudulent certificate that the user’s system accepts because of the broken trust chain. This allows them to decrypt and modify data in transit. For example, if a user connects to a website with an invalid certificate, the attacker can display a fake login page and steal credentials.
• Scope: Web servers using HTTPS are affected. Specific versions aren’t directly applicable as it depends on the certificate configuration.

3. Detection and Assessment

You can check if a system is vulnerable by examining the SSL certificate details in your browser or using command-line tools. A quick check involves looking at the certificate error message in your web browser. A thorough method uses an SSL checker tool to analyse the entire certificate chain.

• Quick checks: In most browsers, clicking on the padlock icon next to the website address will show details about the certificate and any trust issues.
• Scanning: Nessus can identify this vulnerability with signature ID 16289. This is an example only; other scanners may use different IDs.
• Logs and evidence: Web server logs might contain errors related to SSL certificate validation failures, but these are not always present.

openssl s_client -connect yourwebsite.com:443

4. Solution / Remediation Steps

The solution is to obtain and install a valid SSL certificate for the service. This involves purchasing one from a trusted Certificate Authority or generating a self-signed certificate (not recommended for production). Ensure the full chain of certificates is correctly installed on the server.

4.1 Preparation

• Ensure you have access to the server’s configuration files and the ability to restart the web service. A roll back plan involves restoring the original configuration files and restarting the service.
• A change window may be required, depending on your organisation’s policies. Approval from a senior IT administrator might be needed.

4.2 Implementation

1. Step 1: Purchase an SSL certificate from a trusted Certificate Authority (CA).
2. Step 2: Generate a Certificate Signing Request (CSR) on your server.
3. Step 3: Submit the CSR to the CA and obtain the signed certificate.
4. Step 4: Install the signed certificate on your web server, including any intermediate certificates provided by the CA.
5. Step 5: Restart the web service to apply the new certificate.

4.3 Config or Code Example

Before

#Example Apache configuration with missing intermediate certificates
SSLCertificateFile /etc/ssl/certs/yourdomain.crt
SSLCertificateKeyFile /etc/ssl/private/yourdomain.key

After

#Example Apache configuration with correct intermediate certificates
SSLCertificateFile /etc/ssl/certs/yourdomain.crt
SSLCertificateKeyFile /etc/ssl/private/yourdomain.key
SSLCertificateChainFile /etc/ssl/certs/intermediate.crt

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue. Regularly renewing SSL certificates is important. Using a reputable Certificate Authority ensures the certificate chain of trust is maintained. Implementing secure configuration management helps avoid misconfigurations that could lead to certificate validation errors.

• Practice 1: Regular certificate renewal prevents expired certificates, which are a common cause of this issue.
• Practice 2: Using trusted Certificate Authorities ensures the validity and authenticity of your SSL certificates.

4.5 Automation (Optional)

#Example Ansible task to renew Let's Encrypt certificate
- name: Renew Let's Encrypt certificate
  command: certbot renew --non-interactive --agree-tos --email [email protected]
  become: true

5. Verification / Validation

Confirm the fix by checking that the SSL certificate is valid and trusted in your browser. Re-run the earlier detection methods to ensure the vulnerability is resolved. Perform a simple service smoke test to verify functionality.

• Post-fix check: Open the website in your browser and confirm the padlock icon is present and shows a valid certificate with no errors.
• Re-test: Run `openssl s_client -connect yourwebsite.com:443` again; it should show a complete and trusted certificate chain without any warnings or errors.
• Smoke test: Verify that you can access key website pages (e.g., the homepage, login page) without any SSL-related errors.
• Monitoring: Monitor web server logs for SSL certificate validation errors as an example of regression detection.

openssl s_client -connect yourwebsite.com:443 | grep "Verify return code"

6. Preventive Measures and Monitoring

Update security baselines to include requirements for valid SSL certificates and trusted Certificate Authorities. Implement automated checks in CI/CD pipelines to validate certificate configuration during deployment. Establish a regular patch or config review cycle to identify and address potential vulnerabilities.

• Baselines: Update your security baseline with CIS control 14, which covers secure configurations for web servers.
• Pipelines: Add checks in CI/CD pipelines using tools like SSL Labs’ SSL Server Test to automatically validate certificate configuration during deployment.
• Asset and patch process: Implement a quarterly review of all SSL certificates to ensure they are valid and correctly configured.

7. Risks, Side Effects, and Roll Back

• Risk or side effect 2: Using an untrusted CA can compromise security. Mitigation: Only use certificates from reputable Certificate Authorities.
• Roll back: Restore the original web server configuration files and restart the service.

8. References and Resources

Link only to sources that match this exact vulnerability.