Blog

We've just delivered our second batch of features intended to provide full support for the Certificate Transparency (CT) ecosystem. Chief among them is support for the Expect-CT HTTP response header, which sites can use to enable CT compliance enforcement and reporting. Additionally, we've also added a series of user interface and functionality improvements to test for edge cases and detect non-CT-compliant deployments.

Expect-CT Configuration Validation

Expect-CT is a nice little feature that gives web site operators control over how CT is evaluated on their properties. Its main function is to enable CT compliance reporting, enabling browsers to submit reports if they're having problems verifying a site's certificate. Expect-CT is conceptually similar to HSTS; when you create a policy you specify its duration, and so browsers can store it and remember it for the next time they visit a web site.

During the transition period, the reporting is going to be very useful as it will provide real-time detection of misconfigured web sites. Ideally it's something you'd monitor now so that you're not caught by any surprises when Chrome begins to enforce CT. Later on, it may also be useful if someone attempts to use a fraudulent certificate for one of your properties. In Hardenize, we now detect and validate Expect-CT configuration.

CT Compliance Validation Improvements

With our initial implementation of CT validation, in May we started to observe certificates issued by various CAs to see what kind of problems will come up. The vast majority of certificates issued are compliant and embed the necessary SCTs as expected. We have seen a number of problems, one being that some certificates don't embed any CT information.

Now, this is not a problem as such, because the CT spec allows delivery of CT logging proof via other means, more specifically via an TLS extension or OCSP stapling. In Hardenize we support these methods, too, so our reports will correctly handle them and show CT compliance. Initially, not all site operators seemed to be aware of the need to be CT compliant, but we've noticed signs that the problems are being fixed. Cloud providers may typically use TLS as delivery method, and OCSP delivery is also being used. The latter is somewhat worrying, as it's well-known that many popular web servers don't provide robust OCSP stapling. On the surface, everything works as expected, but there are a number of edge cases when connections might start to fail.

Thus, a word of warning: if your sites are using OCSP stapling for CT compliance, ensure that your OCSP stapling implementation is robust. It is said that the IIS server works well. Popular servers such as Apache and Nginx have had a series of problems with OCSP stapling in the past and it's not quite clear what the situation is now exactly.

We've also seen some certificates that embed SCTs but fall short from being fully compliant. Seeing these non-compliant servers and certificates in the wild helped us improve our validation and user interfaces and we made the following improvements:

• We now do a better job presenting embedded SCTs, showing how many SCTs there are, how many are required, and the status of each SCT (does it belong to Google, is it qualified, and so on).
• More importantly, we provide detailed diagnostics of specific problems, spelling out exactly what is wrong. Whereas we don't expect that many of you will see these reports, they will be very useful to those who do.
• We now perform SCT signature validation. These problems are even more rare, but they do appear from time to time.