How to remediate – SSL Certificate ‘commonName’ Mismatch

1. Introduction

2. Technical Explanation

The root cause of this issue is a misconfiguration where an SSL certificate’s ‘commonName’ (CN) attribute does not align with the hostname used by clients to access the service. An attacker could exploit this through man-in-the-middle attacks, intercepting traffic and presenting their own malicious certificate if the client doesn’t validate the CN correctly. This is more likely when users connect using an IP address instead of a DNS name.

• Root cause: Incorrect ‘commonName’ attribute in the SSL certificate configuration for the service.
• Exploit mechanism: An attacker intercepts traffic and presents a fraudulent certificate, potentially stealing sensitive information or performing actions on behalf of the user. For example, if a server is accessed via IP address 192.168.1.10 but the certificate CN is ‘example.com’, an attacker could intercept connections to 192.168.1.10 and present a fake certificate for ‘example.com’.
• Scope: Affects any service using SSL/TLS certificates, including web servers (Apache, Nginx, IIS), email servers, VPN gateways, and other network services.

3. Detection and Assessment

You can confirm this vulnerability by checking the certificate presented when connecting to the service. A quick check is via a browser; a thorough method involves using OpenSSL.

• Quick checks: Use a web browser to access the service. Check the certificate details (usually in ‘Security’ or ‘Connection’ settings) and verify that the ‘Issued To’ field matches the hostname you used to connect.
• Scanning: Qualys SSL Labs can identify this issue, reporting it as a ‘commonName mismatch’. Nessus also has plugins for detecting SSL certificate issues.
• Logs and evidence: Web server logs may show which certificates are being served. Look for discrepancies between the requested hostname and the certificate CN.

openssl s_client -connect yourdomain.com:443 | openssl x509 -noout -subject

4. Solution / Remediation Steps

Fixing this issue involves ensuring that users connect to the service using a DNS hostname that matches the ‘commonName’ in the SSL certificate.

4.1 Preparation

• Ensure you have access to modify DNS records or reconfigure the service with a valid certificate. A roll back plan is to restore the original configuration files.
• Changes may require a change window and approval from relevant stakeholders.

4.2 Implementation

1. Step 1: Identify all hostnames used to access the service.
2. Step 2: Check the ‘commonName’ (CN) attribute of the SSL certificate using the command in section 3.
3. Step 3: If there is a mismatch, either update the DNS records so that users connect via the hostname matching the CN or obtain and install a new certificate covering all used hostnames.
4. Step 4: Restart the service to load the updated certificate.

4.3 Config or Code Example

Before

# Apache configuration example (incorrect)
<VirtualHost *:443>
  ServerName 192.168.1.10
  SSLCertificateFile /path/to/certificate.pem
</VirtualHost>

After

# Apache configuration example (correct)
<VirtualHost *:443>
  ServerName yourdomain.com
  SSLCertificateFile /path/to/certificate.pem
</VirtualHost>

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue.

• Practice 1: Least privilege – restrict access to certificate management systems to only authorised personnel.
• Practice 2: Secure defaults – ensure new services are configured with valid certificates covering the correct hostnames.

4.5 Automation (Optional)

If using a configuration management tool like Ansible, you can automate certificate updates.

# Example Ansible playbook snippet
- name: Ensure SSL certificate matches hostname
  hosts: webservers
  tasks:
    - name: Check certificate CN
      shell: openssl s_client -connect {{ ansible_fqdn }}:443 | openssl x509 -noout -subject
      register: cert_info
    - name: Fail if hostname does not match certificate CN
      fail:
        msg: "Hostname '{{ ansible_fqdn }}' does not match certificate commonName"
      when: "'CN = ' + ansible_fqdn not in cert_info.stdout"

5. Verification / Validation

• Post-fix check: Use the command `openssl s_client -connect yourdomain.com:443 | openssl x509 -noout -subject` and verify that the output includes ‘CN = yourdomain.com’.
• Re-test: Re-run the quick check from section 3 using a web browser to confirm the certificate details now match the hostname.
• Smoke test: Ensure users can still access the service via HTTPS without errors. Test key functionality like login and data submission.
• Monitoring: Monitor web server logs for SSL certificate errors or warnings, looking for any discrepancies between requested hostnames and served certificates.

openssl s_client -connect yourdomain.com:443 | openssl x509 -noout -subject

6. Preventive Measures and Monitoring

Update security baselines to include checks for SSL certificate validity and hostname matching.

• Baselines: Update a CIS benchmark or internal security policy to require valid certificates with correct hostnames.
• Asset and patch process: Review SSL certificates regularly as part of an asset management program, ensuring they are up-to-date and correctly configured.

7. Risks, Side Effects, and Roll Back

Changing the DNS records or certificate can cause temporary service disruption.

• Risk or side effect 1: Incorrect DNS changes could make the service unreachable. Mitigation is to have a tested roll back plan for DNS updates.
• Roll back: 1) Restore the original DNS records. 2) Revert to the previous SSL certificate configuration file. 3) Restart the service.

8. References and Resources

Link only to sources that match this exact vulnerability.

• Vendor advisory or bulletin: [https://support.f5.com/kb/docView?id=11069](https://support.f5.com/kb/docView?id=11069)