How to remediate – SSL/TLS Certificate Contains Wildcard Entries

1. Introduction

The SSL/TLS Certificate Contains Wildcard Entries vulnerability means a server is using an SSL certificate that covers multiple subdomains with a wildcard character. This can increase the risk of compromise if the private key for the certificate is stolen, as it would allow an attacker to impersonate any subdomain covered by the certificate. Systems affected are typically web servers and services using SSL/TLS for encryption, such as email servers or VPN gateways. Impact on confidentiality is likely high, integrity medium, and availability low.

2. Technical Explanation

The vulnerability occurs when a server administrator uses a wildcard certificate instead of issuing separate certificates for each subdomain. This simplifies certificate management but expands the blast radius if the private key is compromised. An attacker gaining access to the private key could intercept traffic and potentially steal sensitive information from any subdomain covered by the certificate. There isn’t a specific CVE associated with simply *using* a wildcard certificate, however misuse of them can lead to exploits like domain takeover or man-in-the-middle attacks.

• Root cause: The use of wildcard characters in the Subject Alternative Name (SAN) field of an SSL/TLS certificate.
• Exploit mechanism: An attacker compromises the private key associated with the wildcard certificate, allowing them to generate valid certificates for any subdomain covered by the wildcard. They could then intercept traffic intended for those subdomains. For example, if a certificate covers *.example.com and the private key is stolen, an attacker can create a fake certificate for mail.example.com.
• Scope: Web servers (Apache, Nginx, IIS), email servers, VPN gateways, any service using SSL/TLS certificates with wildcard entries.

3. Detection and Assessment

You can confirm the presence of a wildcard certificate by examining the certificate details in your browser or using command-line tools. A thorough assessment involves reviewing all installed SSL certificates for wildcard entries.

• Quick checks: Open the website in a web browser, view the certificate details (usually via a padlock icon), and check the “Subject Alternative Name” field for wildcard characters (*).
• Scanning: Qualys SSL Labs’ SSL Server Test (https://www.ssllabs.com/ssltest/) will report certificates with wildcards. Nessus plugin ID 10429 can also identify wildcard certificates.
• Logs and evidence: Web server logs may show the certificate being used for various subdomains. Event IDs are not typically associated directly with this issue, but monitoring certificate renewal events could be helpful.

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

4. Solution / Remediation Steps

The best solution is to replace wildcard certificates with individual certificates for each subdomain. This limits the impact of a compromised key.

4.1 Preparation

• Ensure you have access to your Certificate Authority (CA) account. A roll back plan involves restoring the original backup certificates if issues occur.
• A change window may be required, depending on service criticality. Approval from a senior IT manager might be needed.

4.2 Implementation

1. Step 1: Generate Certificate Signing Requests (CSRs) for each subdomain requiring an SSL certificate.
2. Step 2: Submit the CSRs to your CA and obtain individual certificates for each subdomain.
3. Step 3: Install the new, specific certificates on your web server or affected service.
4. Step 4: Remove the wildcard certificate from the server configuration.
5. Step 5: Restart the web server or affected service to apply the changes.

4.3 Config or Code Example

Before

server {
    listen 443 ssl;
    ssl_certificate /path/to/wildcard.crt;
    ssl_certificate_key /path/to/wildcard.key;
}

After

server {
    listen 443 ssl;
    ssl_certificate /path/to/mail.crt;
    ssl_certificate_key /path/to/mail.key;
}
server {
    listen 443 ssl;
    ssl_certificate /path/to/www.crt;
    ssl_certificate_key /path/to/www.key;
}

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help mitigate the risks associated with SSL certificates.

• Practice 1: Least privilege – only issue certificates for services that absolutely require them, and limit their scope as much as possible.
• Practice 2: Secure key storage – protect private keys using hardware security modules (HSMs) or strong access controls.
• Practice 3: Patch cadence – keep your web server software up to date with the latest security patches.

4.5 Automation (Optional)

Ansible can be used to automate certificate renewal and deployment.

---
- name: Renew SSL certificates
  hosts: webservers
  tasks:
    - name: Check if certificate is about to expire
      command: openssl x509 -in /path/to/certificate.crt -noout -dates
      register: cert_dates
    - name: Renew certificate if necessary (example using certbot)
      command: certbot renew --non-interactive --webroot -w /var/www/html
      when: cert_dates.stdout contains "notAfter=" and cert_dates.stdout | date +%s | awk '{print $1}' < $(date +%s) + 30*24*60*60 # Check if expiring in 30 days
      become: true

5. Verification / Validation

Confirm the fix by verifying that individual certificates are being used for each subdomain and that the wildcard certificate is no longer present.

• Post-fix check: Run `openssl s_client -connect example.com:443 | openssl x509 -noout -text` on each subdomain and confirm it shows a specific certificate, not one with a wildcard.
• Re-test: Re-run the quick check from Section 3 to ensure no wildcards are present in any certificate details.
• Monitoring: Monitor web server logs for SSL-related errors or warnings. A simple query could look for certificate renewal failures.

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

6. Preventive Measures and Monitoring

Proactive measures can help prevent the use of wildcard certificates in the first place.

• Baselines: Update your security baseline to discourage or prohibit the use of wildcard SSL certificates.
• Asset and patch process: Regularly review installed SSL certificates as part of a vulnerability management program, at least every six months.

7. Risks, Side Effects, and Roll Back

Replacing certificates can cause temporary service disruptions if not done carefully.

• Risk