Certificate Transparency
Certificate transparency is a framework designed to bring visibility to the certificate ecosystem and prevent misissuance.
Modern browsers now require not only an X.509 document for HTTPS connections, but also a signed certificate timestamp (SCT) from a Certificate Transparency (CT) log, confirming that the certificate has been submitted to a public ledger.
This framework and accompanying browser requirements have two notable effects on the Censys certificates data set.
Effect No. 1: Pre-certificates
As a result of CT requirements, many Certificate Authorities (CA) now submit a pre-cert to CT logs in order to obtain the log’s signed certificate timestamp (SCT).
A pre-cert contains all of the same information as a certificate, but it has an X.509 "poison" extension (OID: 1.3.6.1.4.1.11129.2.4.3) that is marked critical, which prohibits the pre-cert from being trusted.
After a CA receives the SCT from the CT log, the timestamp is added to the certificate via the X.509 "SCT" extension (OID: 1.3.6.1.4.1.11129.2.4.2), the poison extension is removed, and then the certificate is signed and issued to the requester. Some CAs, such as Let’s Encrypt, submit the signed certificate to the CT log as well, while many others do not.
Because of these differences, the searchable Censys certificate repository can contain records for:
-
A signed certificate
In the case where both documents were submitted to a CT log or in the case where the pre-cert was submitted to a CT log and the corresponding certificate was observed during a Censys scan of the Internet.
In the case where only the signed certificate was submitted to a CT log and the SCT is being presented to browsers via some mechanism other than the SCT extension.
In the case where the certificate was found during a Censys scan of the Internet.
-
Just a pre-cert with no signed certificate
In the case where only the pre-cert was submitted to a CT log and the corresponding certificate has not been observed during a Censys scan of the Internet.
|
Important
|
When the certificate repository contains records for both a certificate and its pre-certificate, the search index contains only the certificate record. You can still view/look up the correlated pre-certificate using its SHA-256 fingerprint. |
Effect No. 2: A Handful of Fingerprints
As stated above, the information contained in a pre-cert, certificate pair is identical. Only the poison extension on the pre-cert and the SCT extension on the certificate (respectively) distinguish them.
Importantly, however, these extensions result in disparate fingerprints (identifiers), because a fingerprint is just a hash algorithm that has been applied to the certificate data in order to make it smaller.
A compounding factor is that different Internet browsers use different hash values, so there are several identifiers in the Censys data set:
-
fingerprint_sha256 -
fingerprint_sha1 -
fingerprint_md5
Censys indexes its records on fingerprint_sha256, so this is the value that must be used to view a certificate, although you can search using any of the identifiers above.
Searching Across Certs and Pre-certs in the Censys Repository
In order to make finding a document easier when you don’t know what kind of record is in the Censys repository, Censys calculates a SHA-256 fingerprint for the intersection of a pre-cert and cert, called tbs_noct_fingerprint.
This field provides a hash value for the content of a pre-cert/ certificate pair so that you can search across both types of records.
Comments
0 comments
Please sign in to leave a comment.