The most common issues with TLS/SSL certificates and their configurations stem from:
- A lack of appropriate signatures (no root or leaf certificate in chain, self-signed certificate, expired certificate).
- The enablement of insecure ciphers.
Commands for checking and verifying that a TLS/SSL Certificates or TLS/SSL Configurations finding is remediated:
- Identifying Findings
- Verifying Configuration and Certificate Details
- Checking Configurations (Ciphers)
- Checking the Size of the Diffie-Hellman Prime Key (Cipher)
- Verifying an Updated Certificate:
Identifying Findings
- TLS/SSL Certificates: When viewing TLS/SSL Certificate findings, use the Certificate Serial Number as the finding identifier.
- TLS/SSL Configurations: When viewing TLS/SSL Configuration findings, refer to the finding identifier or rolled up ID.
Verifying Configuration and Certificate Details
See a certificate’s details and its configurations, including:
- Expiration date
- Certificate signers/providers
- The certificate chain
openssl s_client -connect IP Address:port -servername domain.com < /dev/null | openssl x509 -in /dev/stdin -text -noout
-servername domain.com
is optional depending on the test being performed.
Checking Configurations (Ciphers)
This command outputs all ciphers enabled in the server which you can use to get a general glance at the configurations.
sslscan --tlsall IP Address:port
You can test by version instead of testing all ciphers at once by specifying a version; replace --tlsall
with the appropriate version:
--ssl2
(for SSLv2)--ssl3
(for SSLv3)--tls10
(for TLSv1.0)--tls11
(for TLSv1.1)--tls12
(TLSv1.2).
If a result is not returned, either the server doesn’t support it or the cipher is not enabled.
Checking the Size of the Diffie-Hellman Prime Key (Cipher)
Get key size details of any configured DHE keys on the listed asset, including the bit size of the public key.
Though DH
is the most common instance, you can use different key values as needed; Replace DH
with EDH
or ECDH
depending on the type of Diffie-Hellman configuration.
openssl s_client -connect IP address:port -cipher "DH" | grep "Server Temp Key"
Verifying an Updated Certificate
Updating a certificate generates a new finding. It does not replace the previous finding.
- The newer certificate is assigned its own serial number distinguishing it from the previous certificate.
- The previous finding is no longer updated and remains until it completes its lifetime.
Learn how the TLS/SSL Certificates risk vector is observed.
Identifying Assets with TLS/SSL Certificates Findings
If you’ve recently updated or replaced your certificates, check for affiliated assets and use the Certificate Serial Number as the finding identifier to check if new findings have appeared.
To incorporate IP/domain information into your internal processes:
- When viewing TLS/SSL Certificate findings, go into the Details tab to see where it was observed. The IP or Domain is listed under Key Evidence.
- Refer to the Certificate Subject Alternate field in Findings.
- Refer to the
details.diligence_annotations.certchain.dnsName
field for the Bitsight API.
Identifying the Active Certificate
To identify the newest certificate, refer to the Serial Number of Certificate 1 in the certificate chain [Findings ➔ Finding Details ➔ Certificate Chain ➔ Certificate 1 ➔ Serial Number].
The serial number is formatted in decimal. If viewing in a browser or other tools, the certificate serial number may be in hexadecimal.
- May 29, 2024: Certificate Serial Number replaces Finding Identifier as the TLS/SSL Certificates finding identifier; Identifying Findings section.
- November 29, 2023: New Updated Certificate section.
- September 27, 2022: Published.
Feedback
0 comments
Please sign in to leave a comment.