Name in API: tlscert_no_revocation
Severity: Low
Factor: Network Security
Summary
A TLS Certificate Without Revocation Control lacks mechanisms like CRL or OCSP to verify its validity. Without these checks, compromised certificates remain trusted, enabling attackers to impersonate websites.
How Does It Work?
- Revocation Mechanism: A Certificate Authority (CA) includes URLs in certificates for revocation checks (CRL or OCSP).
- CRL (Certificate Revocation List): The CA publishes a list of revoked certificates, which clients can download to check validity.
- OCSP (Online Certificate Status Protocol): Clients query the CA’s server in real-time to verify if a certificate has been revoked.
- Revocation Reasons: Certificates may be revoked for key compromise, domain decommissioning, or mis-issuance.
- Client Validation: Before accepting a certificate, clients (browsers, applications) verify if it’s revoked by checking CRLs or OCSP responses.
- Connection Blocked: If the certificate is revoked, the connection is refused or marked insecure by the client.
Why Is It a Risk?
Issuing certificates without revocation controls is a security risk because it prevents clients from detecting compromised or invalid certificates. Without revocation checks, a certificate that has been stolen, misused, or rendered obsolete could still be trusted, allowing attackers to impersonate legitimate servers. This exposes users to potential man-in-the-middle attacks, data breaches, and other security vulnerabilities.
Self Evaluation
You may validate the presence/absence of the expired certificate on the endpoint by using the following 3rd Party tools. All can be used to confront contradictory results. However, when comparing results, ensure that the endpoint scanned by each is the same information and matches the SecurityScorecard finding.
Sslscan
sslscan --revoked example.com
Version: 2.0.15
OpenSSL 1.1.1n 15 Mar 2022
Connected to 93.184.216.34
Testing SSL server www.example.com on port 443
Supported Server Cipher(s):
TLSv1.2 256 bit ECDHE-RSA-AES256-GCM-SHA384
TLSv1.3 256 bit TLS_AES_256_GCM_SHA384
SSL Certificate:
Subject: CN=www.example.com
Issuer: CN=Example Root CA, O=Example Org
Validity:
Not Before: Mar 01 12:00:00 2024 GMT
Not After: Mar 01 12:00:00 2025 GMT
OCSP URI: None
CRL URI: None
Certificate Revocation: Not Supported
Protocols supported:
TLSv1.2
TLSv1.3
TLS Renegotiation:
Secure Renegotiation Supported
How to mitigate
Enable OCSP stapling, use trusted CAs, automate certificate renewal, regularly audit SSL/TLS configurations, and ensure revocation checks.
-
CRL - Certificate Revocation Lists
-
Configure web server to distribute CRL.
-
Ensure clients have configured to check CRL automatically.
-
-
OSCP - Online Certificate Status Protocol
-
Usage of OSCP is used to provide real-time revocation status checks.
-
-
Configure the webserver to respond to real-time OSCP requests.
Remediation
- The endpoint configuration has changed, and the certificate used on the endpoint has a CRL/OSCP URL, including in the revocation controls as mentioned above. => Select the finding and then click on the "Fixed" button, "technical_remediation".
- The endpoint has been closed, and therefore, the endpoint is unreachable(or serving a 400/404)
=> Select the finding and then click on the "Fixed" button, "technical_remediation". - After verification (using the methods above, for example), the endpoint defined in the finding does have a certificate updated and is contrary to what SecurityScorecard is stating.
=> Select the finding and then click on "Other resolutions" --> "I cannot reproduce this issue, and I think it’s incorrect," "false_positive."
Comments
0 comments
Please sign in to leave a comment.