[Update 2/23/2014: The previous version of CTPyClient monitor.py was not accurately parsing subjectAltName extension data from retrieved certificates. This has been fixed in the latest commit.]
Since my last post, I’ve finished up the first version of my CTPyClient utilities. My primary focus was to first understand how to answer the basic question: how can I determine if a certificate has been issued by a CA other than the one that I purchased my certificate from? Recall from past CA mis-issuance incidents (ComodoHacker, Diginotar), the goal of CT is to provide a means for site owners to determine if a CA has accidentally or as a result of a compromise, issued an unauthorized certificate for their domains.
The /ct/v1/get-entries log client method is used to fetch log entries from a CT log server. Each log entry has 2 parts: a MerkleTreeLeaf structure and an extra_data structure which contains a certificate chain. The MerkleTreeLeaf structure is a composite data structure that contains a timestamp which indicates when the certificate was submitted to the log server as well as a copy of the end entity certificate that was submitted. The structure is encoded as a Base64 encoded byte string. Within this byte string, the actual certificate is encoded in DER format, using the same structure as required by the TLS specification (RFC 5246). The extra_data structure consists of the certificates that were used to issue the end entity certificate with the exception of the root certificate. These certificates are also encoded using the format specified by TLS.
The get-entries method does not provide ‘request/response’ mechanism to determine if a given certificate is present in the log. Rather, the get-entries method expects the submitter to specify a range of log entries to fetch. It is the job of the submitter to parse the results of get-entries to look for certificates of interest. This design decision makes sense, since the log server is designed to be just that, a log. The protocol is designed for efficient data retrieval, not for supporting queries. It is expected that as CT’s use grows, other interested parties will build out databases that contain issued certificates, using one or more CT log servers as input.
In order to specify a range of log entries to request, you first have to ask the log server for the number of log entries that are present. This can be accomplished by using the /ct/v1/get-sth method. This method will return the number of log entries present in the log server since the last time that a signed tree head (STH) was generated. You can then specify the range of log entries to retrieve based on an offset from this number.
The monitor.py utility that is part of CTPyClient implements this flow. Feel free to download the utility and kick the tires!
Next time, I’ll explore some of the other CT log client functions and discuss how they can be used to further detect missuance events.