Certificate Transparency (CT) is pushed by Google and others as a mechanism to improve the detectability of certificate misissuances.
In CT, issued certificates are kept track of by untrusted but verifiable log servers. This additional degree of transparency in the Web PKI makes certificate misissuance and Certificate Authority (CA) malpractice detectable by site operators, system administrators, and third parties.
Read Certificate Transparency to the rescue to learn more about the basics of CT.
In a paper we recently presented at the Passive and Active Measurement Conference 2018 [PDF 652 KB], we analyzed the certificate ecosystem using CT logs. To perform this analysis we downloaded 600 million certificates from 30 CT logs. This vast certificate set gives us insight into the ecosystem itself and allows us to analyze various certificate characteristics.
Top certificate issuers
First, we investigate which CAs are issuing the most certificates found in CT logs.
Figure 1 — Non-expired certificates in CT logs by the issuing CA.
In Figure 1, we see the top five CAs by the number of issued certificates. We can derive three interesting findings from it:
- Let’s Encrypt is the dominating CA by number of certificates.
- Patterns of certificate duration are clearly visible (three months for Let’s Encrypt; up to several years for other CAs).
- There are certificates in logs from before standardization of CT began in 2012.
Certificate conformance with industry best practices
Having this vast certificate collection allows us to analyze specific certificate characteristics.
Conformance with the industry’s best practices is crucial, as demonstrated by the removal of the CA PROCERT from Mozilla’s products due to multiple security violations.
We checked how many non-expired certificates still use broken cryptographic algorithms such as 1024-bit RSA keys or a SHA-1 signature algorithm. We additionally checked how many certificates omit the mandatory Subject Alternative Name (SAN).
Figure 2 — Non-expired certificates violating industry standards.
Even though we still found thousands of certificates using broken cryptographic algorithms and omitting SAN, their number is steadily decreasing as can be seen in Figure 2. This is a clear sign that CAs are applying more rigour when issuing certificates. Note that the horizontal lines indicate the date when the respective requirement was made mandatory in Google Chrome.
To test whether your certificate is up to date with current certificate standards, you can search for your certificate at https://crt.sh/ and then run cablint or run zlint to find potential issues.
Below is the output of a Let’s Encrypt certificate without any reported issues:
CA/B Forum lint
Powered by certlint
INFO: Certificate Transparency Precertificate identified
INFO: TLS Server certificate identified
If you find warnings or even errors in your output you can contact your CA for more information.
Is your website ready for CT?
Starting 30 April 2018, Google Chrome made CT mandatory for newly issued certificates. CAs embed Signed Certificate Timestamps (SCTs) automatically into certificates. Certificates that were not issued recently might not yet contain embedded SCTs.
To check whether your website’s certificate contains embedded SCTs:
- Download the certificate.
- Run
openssl x509 -noout -text -in downloaded-cert.crt. - Look for CT Precertificate SCTs in the output.
If your certificates contain embedded SCTs, you are good to go.
In the other case, you can still profit from CT’s advantages by manually submitting your certificate to CT logs and transferring the resulting SCTs using a TLS handshake extension. To send SCTs in the TLS handshake there is a module for Apache and a configuration directive for nginx available. In this case, it is particularly desirable to make the browser remember that your website enforces CT, described in the upcoming section.
Enforcing CT using HTTP headers
To avoid the threat of CAs backdating certificates to circumvent the CT deadline, you can enforce CT for certificates issued before 30 April 2018 by including the Expect-CT HTTP header in your web server configuration.
In our research we found about 7,300 domains sending an Expect-CT header. Less than 10% of those domains enforce Expect-CT with a duration of one day or more.
If you made sure that your web server is sending appropriate SCTs in the handshake, you can enable Expect-CT on your website for one day with the following HTTP header:
Expect-CT: max-age=86400,enforce
Expect-CT is supported by Chrome and Firefox.
Using certificates from CT logs as address source
In addition to providing a comprehensive overview of the certificate ecosystem, CT data can be leveraged as a source for IP addresses.
As part of a long-term effort, we strive to provide an ‘IP address hit list’ for IPv6 measurements. This hit list is sourced from zone files, the Alexa Top 1M list, and other sources.
By resolving the domains extracted from CT log certificates we were able to increase our IPv6 hit list size by almost 70%. Our enhanced IPv6 hitlist is publicly available.
This article is based on joint research by Oliver Gasser (TU Munich), Benjamin Hof (TU Munich), Max Helm (TU Munich), Maciej Korczynski (Grenoble Alps University, TU Delft), Ralph Holz (USyd), and Georg Carle (TU Munich). The research paper [PDF 652 KB] received the Best Paper Award at the Passive and Active Measurement Conference 2018.
Oliver Gasser is a Senior Researcher at the Max Planck Institute for Informatics leading the Internet Security Measurements research group. His research focuses on leveraging Internet measurements to characterize aspects of security and network protocols.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.