BlogWelcome to the Hardenize blog. This is where we will document our journey as we make the Internet a more secure place and have some fun and excitement along the way.
Update (2 May 2018): The Chrome team has now announced that they will start enforcing the CT requirement in Chrome 68, which will be released as beta in early June and stable in late July. Web site operators have until then to ensure that all their new certificates either embed CT logging proof or provide proofs using other means.
After April 30th, Chrome will start rejecting all new certificates that don’t have sufficient proof of being logged to Certificate Transparency (CT) servers. To help with the transition, we’ve released a series of improvements to our tools to verify and monitor CT compliance.
Certificate Transparency is an important part of Google’s plan to deal with security issues inherent in the current PKI design, mainly the fact that any public CA can issue a certificate for any property in the world. Google’s first attempt was via public key pinning, which used strong technical measures to accept only certificates operated by those who genuinely control them. However, that experiment had been deemed too complex to use widely and is now being phased out.
CT approaches the problem from another end and ensures that all public certificates are recorded (in CT logs) and available for inspection. The idea is that tools can choose to accept only publicly-disclosed certificates. At the same time, PKI ecosystem auditors and other interested parties—including property owners themselves—can keep an eye on the certificates issued in their name.
This deadline is just the latest in the series of steps toward full CT compliance. Previously, Google had required CT to give special treatment to EV certificates. It had also imposed CT compliance as a punitive measure against Symantec. From May this year, all new certificates will need to be CT compliant for Chrome to accept them without warning.
It is expected that all certificates will contain embedded proofs, which means that everything should just work, from end-user perspective. Although there are alternative transport methods for the proofs (TLS extensions and OCSP responses), they are not widely supported in the common server software.
The actual compliance rules are quite elaborate and depend on the certificate lifetime as well as the transport methods used. As a result, a certificate may need to be logged in between two and five CT logs to be compliant.
In our assessment, we now look for embedded SCTs in every certificate we encounter. If there are any, their information will be in the certificate details section.
We have also extended our assessments to examine CT compliance of every encountered certificate. The notes section just below each certificate will show the compliance status.
However, because of how CT works, having a certificate that’s not compliant is not in itself an error (either now or from May), because CT information can be supplied at runtime, via a TLS extension or an OCSP response. That’s why you will never see an error finding attached to a certificate that complains about the lack of compliance. The real testing is done at the TLS level, whenever we establish a connection to your server. To check for CT compliance we first look at the certificate, but we fall back to other transport methods if necessary. We do report problems at this level, if we encounter a non-compliant TLS connection with a certificate for which compliance is required.
On the reporting side, in our commercial application, we’ve made two improvements to help organisations monitor their CT compliance. Because we can’t properly check for CT compliance before May, we’ve done the next-best thing: we’ve added a certificate history page that shows recent certificates and their issuers. What you want to be seeing here is that all your new certificates are CT compliant.
Additionally, we’ve created another network endpoint report that shows all network locations with problems, and lack of CT compliance is just one of the problems we report there.
As you may know, in Hardenize we monitor issuance of certificates in real-time; we also evaluate each discovery and have rules to automatically hide routine new certificates as well as escalate problems. There is now a new escalation rule that validates new certificates for CT compliance and alerts if necessary. We don’t expect to catch many certificates there from May 2018 onwards, but there’s no harm in checking. For now you can use this feature to catch unexpected non-compliant certificates (e.g., if your CA has told you that they’re compliant already).
