Certificate Validation

4 automated security scanners

Certificate Revocation OCSP CRL

Purpose:
The Certificate Revocation (OCSP & CRL) Scanner is designed to validate the status of certificates by checking their OCSP responders and CRL distribution points. The scanner aims to detect revoked certificates, misconfigured revocation services, and gaps in revocation checking that could allow for the use of compromised certificates, thereby creating critical security risks.

What It Detects:

OCSP Responder Validation: Extracts the OCSP responder URL from the certificate’s AIA extension, sends an OCSP request for the certificate serial number, parses the OCSP response status (good/revoked/unknown), measures the OCSP responder response time, and flags slow or unavailable services.
CRL Distribution Point Check: Extracts CRL distribution point URLs from the certificate, downloads CRLs from these points, parses them to check for the certificate serial number, validates the CRL signature and issuer, and checks the CRL’s nextUpdate time for expiration.
Revocation Status Verification: Checks if a certificate is listed as revoked in both the CRL and OCSP response, verifies that the OCSP response indicates the correct status of the certificate, flags certificates with revoked status, and detects any conflicting statuses between OCSP and CRL.
OCSP Stapling Analysis: Checks if the server supports OCSP stapling, verifies that the stapled OCSP response is current, flags missing or expired responses, and measures the performance benefit of using OCSP stapling.
Revocation Infrastructure Health: Tests the reachability of OCSP responders, validates the availability of CRL distribution points, checks the freshness of CRLs (nextUpdate timing), and flags any missing endpoints for revocation checking.

Inputs Required:

domain (string): A fully qualified domain name (e.g., ekkatha.com) is required to perform certificate validation.

Business Impact:
Certificate revocation validation failures can lead to significant security risks, including:

Revoked certificates from compromised private keys remaining trusted: This allows the use of compromised or stolen digital certificates in transactions and applications.
Missing OCSP/CRL endpoints preventing revocation checking: This results in a lack of real-time monitoring for certificate validity, potentially exposing systems to risks associated with revoked certificates.
Slow or unavailable OCSP responders causing soft-fail security bypasses: This can lead to delays in detecting compromised certificates and may result in the continued use of invalid certificates.
CRL distribution points with expired CRLs allowing revoked cert usage: This enables the reuse of certificates that have been revoked, posing a significant security threat.
OCSP stapling misconfiguration forcing clients to skip revocation checks: This can lead to unmonitored certificate statuses and potential abuse by attackers using compromised or stolen certificates.

Risk Levels:

Critical: Conditions where the OCSP responder is unreachable or returns an error, or when CRL distribution points are unavailable or have expired CRLs.
High: Conditions where the OCSP response indicates a certificate status of “revoked” but the CRL does not list it as such, indicating potential misconfigurations in revocation infrastructure.
Medium: Conditions where OCSP responders are slow to respond or there is uncertainty about the current status of the certificate due to missing or expired stapled responses.
Low: Informal findings related to minor issues like misconfigured OCSP URLs or incomplete CRL distribution points, which do not significantly impact security but should be addressed for optimal performance and compliance.
Info: General information regarding the presence of OCSP and CRL endpoints without immediate critical risks identified.

Example Findings:

A certificate with a revoked status is detected through both OCSP and CRL checks, indicating potential misconfiguration in revocation infrastructure.
An OCSP responder is unreachable due to network issues, leading to a soft-fail in revocation checking for the associated domain.

Misconfigured Intermediate CA

Purpose: The Misconfigured Intermediate CA Scanner is designed to identify misconfigured intermediate Certificate Authority (CA) certificates that fail to meet the stringent requirements set forth by the CA/Browser Forum baseline standards. This includes verifying the presence of critical extensions, ensuring proper key usage flags, path length constraints are adhered to, and policy identifiers comply with EV/OV validation criteria.

What It Detects:

Basic Constraints Validation: Ensures the CA:TRUE flag is present in intermediate certificates, checks for appropriate path length constraint settings, and verifies that the critical flag is set on basicConstraints extension.
Key Usage Extension Check: Confirms the presence of the keyCertSign bit for CA certificates and cRLSign for CRL-issuing CAs. It flags instances where digitalSignature is used instead of keyCertSign and ensures keyUsage is marked as critical.
Extended Key Usage Analysis: Alerts when prohibited Extended Key Usage (EKU) values are present in CA certificates, identifies serverAuth/clientAuth in intermediate CAs, and verifies the absence of anyEKU not present in intermediates.
Name Constraints Validation: Parses nameConstraints extension to verify permitted/excluded subtrees and ensures constraints do not allow universal issuance.
Certificate Policies Check: Extracts certificate policy OIDs, confirms appropriate policy qualifiers, and validates compliance with required policy identifiers (EV, OV, DV).

Inputs Required:

domain (string): A fully qualified domain name (e.g., ekkatha.com) used to retrieve the SSL/TLS certificate for analysis.

Business Impact: Misconfigured intermediate CAs pose significant risks to PKI security by allowing unauthorized sub-CA creation, cross-domain certificate issuance, and bypassing EV/OV validation processes. This can lead to severe vulnerabilities where leaf certificates can issue fraudulent certificates or digital signatures are improperly validated, compromising the integrity of network communications and user data.

Risk Levels:

Critical: Missing CA:TRUE constraint allows leaf certs to issue fraudulent certificates, incorrect key usage prevents proper certificate validation, missing or wrong policy identifiers bypass EV/OV validation.
High: Path length violations allow unauthorized sub-CA creation, digitalSignature used instead of keyCertSign, prohibited EKU values in CA certificates, and anyEKU not present in intermediates.
Medium: Overly permissive name constraints that enable cross-domain certificate issuance.
Low: Incorrect path length constraint settings, improper critical flag on basicConstraints, or missing extended key usage extension.
Info: Minor issues with policy qualifiers or OIDs extraction from the certificate policies extension.

Example Findings:

An intermediate CA has a misconfigured basicConstraints extension, lacking the CA:TRUE flag and critical attribute set, which could lead to unauthorized certificate issuance.
A certificate uses digitalSignature in place of keyCertSign, preventing it from being used as an intermediate CA for other certificates.

Expired Intermediate Certificate

Purpose: The Expired Intermediate Certificate Scanner is designed to detect expired intermediate certificates in the SSL/TLS certificate chain. These expired intermediates can lead to trust validation failures, causing widespread connectivity issues and browser warnings. This scanner aims to identify and report such expired certificates to help maintain secure network communications.

What It Detects:

Full Chain Expiration Analysis: Retrieves the certificate chain from a server, parses the notBefore and notAfter fields for each certificate, calculates the days until expiration for each cert, and flags any expired certificates in the chain.
Intermediate Certificate Identification: Distinguishes between leaf, intermediate, and root certificates, focuses validation on intermediate CA certificates, checks if intermediates have the CA:TRUE basic constraint, and verifies that they allow certificate signing.
Validity Period Calculation: Extracts notBefore and notAfter timestamps, calculates remaining validity in days, flags certificates expiring within a warning threshold (30 days), and identifies certificates already expired.
Cross-Certificate Detection: Checks for multiple intermediates with the same subject, detects cross-signed intermediate certificates, verifies at least one valid path to the root exists, and flags if all paths contain expired intermediates.
Temporal Ordering Validation: Verifies that the leaf certificate is issued before any intermediate expires and checks that an intermediate is issued before the root expires. It also flags backdated or future-dated certificates.

Inputs Required:

domain (string): Fully qualified domain name (e.g., ekkatha.com)

Business Impact: Expired intermediate certificates pose a significant risk to network security and reliability, as they can lead to unpredictable connectivity issues and warnings from browsers. Proper management of these certificates is crucial for maintaining trust in digital communications.

Risk Levels:

Critical: Browsers reject the entire chain when an intermediate expires, blocking all traffic. This indicates a severe risk where network operations are disrupted without warning.
High: Expired intermediates suggest poor certificate lifecycle management and can lead to systems with outdated trust stores failing validation unpredictably.
Medium: Mixed expired/valid intermediates break mobile and IoT clients, causing intermittent connectivity issues that are difficult to predict and manage.
Low: While not as critical, certificates expiring soon (within 30 days) should be monitored closely for proactive management.
Info: Informational findings regarding the validity of intermediate certificates can help in maintaining awareness about certificate health within the network.

Example Findings:

A browser has blocked access to a website due to an expired intermediate certificate, causing significant service disruption.
An IoT device failed to connect to its cloud server because the intermediate certificate had expired, leading to potential safety and operational risks.

This documentation provides a clear overview of the Expired Intermediate Certificate Scanner’s purpose, detection points, required inputs, business impact, risk levels, and example findings. It is designed to help users understand the criticality of this scanner in maintaining network security and reliability.

Broken Chain of Trust Detection

Purpose: The Broken Chain of Trust Detection Scanner is designed to validate the complete SSL/TLS certificate chain from a leaf certificate to its trusted root CA. This process involves checking for missing intermediate certificates, incorrect certificate ordering, and broken trust paths that could lead to browser security warnings and potential service outages.

What It Detects:

Complete Chain Retrieval: The scanner establishes a TLS connection to the specified domain on port 443, retrieves the full certificate chain from the server response, parses each certificate in the chain, and counts the number of certificates returned.
Chain Completeness Validation: This includes verifying that the leaf certificate is signed by an intermediate, that each intermediate is signed by its parent, and ensuring that the chain terminates at a trusted root CA. It also flags any missing intermediate certificates.
Certificate Ordering Verification: The scanner validates that the certificates are in the correct order (leaf → intermediate → root) and detects if there is reversed or scrambled chain ordering, as well as flagging if the leaf certificate is not the first in the chain.
Issuer-Subject Matching: It extracts the issuer Distinguished Name (DN) from each certificate and the subject DN from the next certificate in the chain to verify that the issuer matches the subject of the signing certificate, flagging mismatches that indicate a broken chain.
Root CA Trust Validation: The scanner checks if the root certificate is present in the system trust store, verifies that the root is self-signed, and flags chains ending in untrusted roots or custom/private CAs.

Inputs Required:

domain (string): A fully qualified domain name (e.g., ekkatha.com), which is essential for establishing a TLS connection to retrieve the certificate chain.

Business Impact: Broken SSL/TLS certificate chains can lead to significant security and availability issues, including browser rejection of connections due to incomplete chains, increased latency from fetching missing intermediates, validation breaks in strict TLS implementations, potential man-in-the-middle attacks on legacy clients, and compromised or misconfigured PKI.

Risk Levels:

Critical: Browsers reject connections with incomplete chains, leading to service outages.
High: Missing intermediate certificates force clients to fetch from Automatic Issuance Infrastructure (AIA), adding latency.
Medium: Incorrect chain ordering breaks validation in strict TLS implementations.
Low: Untrusted intermediate CAs indicate compromised or misconfigured PKI.
Info: Chain breaks enable man-in-the-middle attacks on legacy clients.

Example Findings:

A certificate chain for example.com was found to be incomplete, missing one of the required intermediate certificates.
The leaf certificate for secure.site had a reversed order in its chain, starting with an intermediate instead of the expected leaf certificate.