How to remediate – TLS Web Server Authentication Extension Not Supported

1. Introduction

The TLS Web Server Authentication Extension Not Supported vulnerability means a server’s TLS certificate doesn’t confirm it’s allowed to identify itself as that specific website. This can allow attackers to impersonate websites, leading to man-in-the-middle attacks and data theft. Systems using TLS certificates for web services are usually affected, including web servers, load balancers, and reverse proxies. A successful exploit could compromise confidentiality, integrity, and availability of the service.

2. Technical Explanation

This vulnerability occurs because the server’s TLS certificate lacks an Extended Key Usage (EKU) extension specifying the id-kp-serverAuth OID. This means clients can’t verify the server is authorised to use that certificate for web authentication. An attacker could present a valid, but incorrectly configured, certificate and trick users into connecting to a malicious site.

• Root cause: The TLS certificate does not include the id-kp-serverAuth OID in its Extended Key Usage (EKU) extension.
• Exploit mechanism: An attacker presents a valid TLS certificate without the correct EKU, and a client fails to validate it properly. This allows them to intercept and potentially modify traffic.
• Scope: Web servers using TLS 1.0 or later are affected if their certificates lack this EKU extension. Apache, Nginx, IIS, and other web server software can be vulnerable depending on certificate configuration.

3. Detection and Assessment

You can check for the vulnerability by examining the TLS certificate presented by your web server. A quick check is to use a command-line tool like openssl. More thorough assessment involves scanning with a vulnerability scanner.

• Quick checks: Use openssl to examine the certificate and look for the EKU extension.
• Scanning: Nessus, OpenVAS, or Qualys can detect this issue using signature IDs such as 148593 (Nessus). These are examples only.
• Logs and evidence: Check web server logs for TLS handshake errors related to certificate validation failures. Event IDs will vary depending on the server software.

openssl s_client -connect yourdomain.com:443 | openssl x509 -noout -text | grep "Extended Key Usage"

4. Solution / Remediation Steps

Replace the existing TLS certificate with a new one that includes the id-kp-serverAuth OID in its Extended Key Usage (EKU) extension. This ensures clients can properly validate the server’s identity.

4.1 Preparation

• Ensure you have a valid new certificate from a trusted Certificate Authority (CA). A roll back plan is to restore the original certificate and restart the service.
• A change window may be needed depending on your organisation’s policies. Approval from a security or infrastructure team might be required.

4.2 Implementation

1. Step 1: Obtain a new TLS certificate with the id-kp-serverAuth EKU extension from your CA.
2. Step 2: Stop the web service (e.g., Apache, Nginx, IIS).
3. Step 3: Replace the old certificate file with the new certificate file in the appropriate server configuration directory.
4. Step 4: Update any associated private key references if necessary.
5. Step 5: Restart the web service.

4.3 Config or Code Example

Before

subjectAltName = @alt_names
[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_ca

After

subjectAltName = @alt_names
[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_ca
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth

4.4 Security Practices Relevant to This Vulnerability

Regular certificate validation and management are essential. Least privilege can limit the impact if a certificate is compromised. Secure configuration practices help prevent misconfigurations like missing EKUs.

• Practice 1: Implement a regular TLS certificate review process to ensure certificates are valid, correctly configured, and renewed on time.
• Practice 2: Use least privilege principles when granting access to certificate management tools and private keys.

4.5 Automation (Optional)

If using configuration management tools like Ansible, you can automate the certificate replacement process.

---
- name: Replace TLS Certificate
  hosts: webservers
  tasks:
    - name: Stop Web Service
      service:
        name: nginx
        state: stopped
    - name: Copy New Certificate
      copy:
        src: /path/to/new_certificate.pem
        dest: /etc/nginx/ssl/yourdomain.com.crt
    - name: Restart Web Service
      service:
        name: nginx
        state: started

5. Verification / Validation

Confirm the fix by examining the new certificate presented by your web server using openssl. Re-run the earlier detection method to verify the issue is resolved. Perform a basic service smoke test to ensure functionality remains intact.

• Post-fix check: Run `openssl s_client -connect yourdomain.com:443 | openssl x509 -noout -text | grep “Extended Key Usage”` and confirm the output includes “serverAuth”.
• Re-test: Re-run the initial openssl command to verify the EKU extension is now present.
• Smoke test: Access your website via HTTPS in a web browser to ensure it loads correctly. Check key functionality like login or form submission.
• Monitoring: Monitor web server logs for TLS handshake errors, looking for any new certificate-related issues.

openssl s_client -connect yourdomain.com:443 | openssl x509 -noout -text | grep "Extended Key Usage"

6. Preventive Measures and Monitoring

• Baselines: Update your security baseline to require the id-kp-serverAuth OID in TLS certificates.
• Pipelines: Add checks to CI/CD pipelines using SAST tools to validate certificate configurations and identify missing EKUs.
• Asset and patch process: Review TLS certificate configurations at least quarterly, or more frequently for high-risk systems.

7. Risks, Side Effects, and Roll Back

Replacing a TLS certificate can cause brief service downtime if not handled carefully. Incorrect configuration could lead to connection errors. A roll back plan is to restore the original certificate file and restart the web service.

• Risk or side effect 1: Brief service interruption during certificate replacement. Mitigation: Perform the change during a maintenance window with minimal user impact.
• Roll back: Step 1: Stop the web service. Step 2: Restore the original certificate file. Step 3: Restart the web service.