1. Home
  2. Network Vulnerabilities
  3. How to remediate – SSL Certificate Fails to Adhere to Basic Constraints / Key Usa…
Searching...

How to remediate – SSL Certificate Fails to Adhere to Basic Constraints / Key Usa…

Contents

1. Introduction

An X.509 certificate used by a service fails to meet basic constraints and key usage requirements, known as SSL Certificate Fails to Adhere to Basic Constraints / Key Usage extensions. This means the certificate authority may have incorrectly signed the certificate. Incorrectly configured certificates can be rejected by some software, potentially disrupting connections. This impacts confidentiality if connections are blocked, integrity if a misconfigured certificate is used maliciously, and availability if services become unreachable.

2. Technical Explanation

The issue occurs when an X.509 certificate does not correctly follow the rules defined in RFC 5280 regarding basic constraints and key usage extensions. This usually happens during certificate creation or signing, often due to oversight or misconfiguration. An attacker could potentially exploit this by presenting a certificate that is incorrectly signed, leading to trust issues or denial of service if software rejects it.

  • Root cause: The certificate’s basic constraints and/or key usage extensions do not match the intended purpose of the certificate.
  • Exploit mechanism: An attacker provides a server with an incorrectly signed certificate, causing client applications to reject the connection. This could be part of a man-in-the-middle attack or simply disrupt service availability.
  • Scope: Any system using X.509 certificates for TLS/SSL connections is potentially affected, including web servers (Apache, Nginx), email servers, and VPN gateways.

3. Detection and Assessment

You can confirm the vulnerability by examining the certificate chain presented by a service. A quick check involves using OpenSSL to view the certificate details. For thorough assessment, use a dedicated SSL testing tool.

  • Quick checks: Use OpenSSL to examine the certificate chain. Example command: openssl s_client -connect yourdomain.com:443 and review the output for any errors related to certificate validation or extension constraints.
  • Scanning: SSL Labs’ SSL Server Test (https://www.ssllabs.com/ssltest/) can identify certificate chain issues. Qualys SSL Labs provides a detailed report, including any violations of RFC 5280.
  • Logs and evidence: Check server logs for errors related to certificate validation failures or TLS handshake problems. The specific log location varies by service (e.g., Apache access/error logs, Nginx error logs).
openssl s_client -connect yourdomain.com:443

4. Solution / Remediation Steps

The solution involves correcting the certificate extensions and having it re-signed by a Certificate Authority. This requires careful attention to detail to ensure proper configuration.

4.1 Preparation

  • Ensure you have access to the certificate signing request (CSR) used to generate the original certificate. A roll back plan involves restoring the backed-up certificates and restarting the service.
  • Change windows should be planned during off-peak hours with approval from relevant IT stakeholders.

4.2 Implementation

  1. Step 1: Examine the existing certificate using OpenSSL to identify the incorrect extensions.
  2. Step 2: Generate a new CSR with corrected basic constraints and key usage extensions, ensuring they align with the certificate’s intended purpose.
  3. Step 3: Submit the new CSR to your Certificate Authority for signing.
  4. Step 4: Once signed, install the new certificate on the affected server.
  5. Step 5: Restart the service to load the updated certificate.

4.3 Config or Code Example

Before

[ req ]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
[ req_distinguished_name ]
C  = UK
ST = England
L  = London
O  = Example Ltd
OU = IT Department
CN = yourdomain.com
[ v3_req ]
basicConstraints = critical,CA:FALSE # Incorrect for a leaf certificate
keyUsage = digitalSignature, keyEncipherment

After

[ req ]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
[ req_distinguished_name ]
C  = UK
ST = England
L  = London
O  = Example Ltd
OU = IT Department
CN = yourdomain.com
[ v3_req ]
basicConstraints = CA:FALSE # Correct for a leaf certificate
keyUsage = digitalSignature, keyEncipherment

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue. Least privilege ensures that certificates are only used for their intended purpose. Input validation during CSR generation prevents incorrect values from being submitted. Safe defaults in certificate templates reduce the risk of misconfiguration.

  • Practice 1: Implement least privilege by ensuring each certificate is issued with only the necessary permissions and key usages.
  • Practice 2: Validate input data when generating Certificate Signing Requests to prevent incorrect or malicious values from being included.

4.5 Automation (Optional)

If using a configuration management tool, automate CSR generation and certificate installation. This reduces manual errors.

# Example Ansible task for generating a CSR
- name: Generate CSR
  openssl_csr:
    path: /etc/ssl/certs/yourdomain.com.csr
    key_file: /etc/ssl/private/yourdomain.com.key
    data:
      countryName: UK
      stateOrProvinceName: England
      localityName: London
      organizationName: Example Ltd
      organizationalUnitName: IT Department
      commonName: yourdomain.com
    basic_constraints: "CA:FALSE"
    key_usage: "digitalSignature, keyEncipherment"
  become: true

5. Verification / Validation

Confirm the fix by examining the new certificate chain and verifying that it adheres to RFC 5280. A negative test involves attempting a connection with an older, vulnerable certificate.

  • Post-fix check: Use OpenSSL again: openssl s_client -connect yourdomain.com:443. The output should no longer show errors related to certificate validation or extension constraints.
  • Re-test: Re-run the SSL Labs’ SSL Server Test (https://www.ssllabs.com/ssltest/) and confirm that it reports no issues with the certificate chain.
  • Smoke test: Verify that users can still access HTTPS websites using your service without any connection errors.
  • Monitoring: Monitor server logs for TLS handshake success events to ensure connections are being established correctly.
openssl s_client -connect yourdomain.com:443

6. Preventive Measures and Monitoring

Update security baselines to include certificate validation rules. Implement checks in CI/CD pipelines to prevent incorrectly configured certificates from being deployed. A regular patch review cycle ensures timely updates of TLS libraries.

  • Baselines: Update your security baseline or policy to require all X.509 certificates adhere to RFC 5280 standards.
  • Asset and patch process: Implement a regular review cycle for TLS libraries and certificate configurations, typically every 3-6 months.
Updated on December 27, 2025

Was this article helpful?

Yes No

Related Articles