We're living in a pretty awesome time right now as we observe significant advances being made in the TLS/PKI ecosystem all around us. One of those advances is the introduction of Certificate Transparency and the deadline for compliance is fast approaching. Are you ready?
Certificate Transparency
CT is one of those things where once you know what it does you find yourself thinking 'why hasn't it always been like that?'. It fixes a problem we've had in the PKI ecosystem for some time and in many ways CT is a lot more awesome than you might realise. I have a blog post, Certificate Transparency, an introduction, if you'd like to go into more detail on exactly what CT is, but at a high level it means that you can always be aware of exactly what certificates exist for your domain. Right now there is no way for you to be absolutely sure what certificates exist and that means employees, friends, attackers or your dog could get a certificate for your site and if they didn't tell, you would never know. Think about, if I can bribe or compromise a CA, or even request a certificate outside of the normal company process, without me disclosing that I've done that there's basically no way to know it exists. This is a really dangerous place to be and this is exactly what CT fixes. CT requires that all certificates are logged into public CT Logs so that their existence can never be a secret and never be hidden from the domain owner. The CT Logs will provide something called a Signed Certificate Timestamp which is proof that the certificate has been placed on the log and it's this proof that the browser will soon want to see or it will reject the certificate.
Checking CT Compliance
For your certificate to be accepted by the browser it has to be 'CT Qualified' which means it meets the criteria set out by that particular browser. As Chromium is going to be the first browser to require certificates to be CT Qualified I will talk about their criteria for now. You can see the CT qualification criteria for Chromium at that link but essentially you need a varying number of valid SCTs depending on the validity period of the certificate. The options are a minimum of 2 SCTs for certs valid < 15 months and 3 SCTs for certs valid up to 27 months. There were other ranges but as the CA/Browser Forum has now restricted the maximum validity period of a certificate to 825 days they can no longer be reached. To check your certificate is CT Qualified then you need to do the following as a high-level checklist:
- Determine the number of SCTs required based on cert max age.
- Determine if the embedded SCTs are from logs trusted by Chrome.
- Check the SCTs are valid and issued for this certificate.
- Use the above information to determine if CT qualified.
This is a lot of 'stuff' to do with most of it being fairly technical and it'd also need to be done on a per certificate basis. Fortunately you don't need to do any of this, at all, as there's a much easier way.
Ask the browser
All of the features on Report URI are about making your life easier and the same can be done with checking certificates for CT qualification. The one thing in the world that knows whether or not your certificate meets the CT qualification criteria in Chrome is Chrome, so why not just ask? That's what the Expect-CT header is for and it's crazy easy to deploy.
Expect-CT: max-age=0, report-uri="https://{$subdomain}.report-uri.com/r/d/ct/reportOnly"
You can read more details about various settings in the blog linked above but that header will get you started with basic notifications on whether or not your certificates are ready for CT. The policy isn't in enforce mode, so it won't break anything, and it has a max-age of 0, so it won't be cached on the client either. What will happen though is that if you serve the browser a certificate that doesn't meet the CT qualification criteria it will tell you. What's even better is that it will tell you by sending a nicely formatted report to Report URI for you to see in your account.
{
"expect-ct-report": {
"date-time": "2018-05-10T07:00:00.000Z",
"effective-expiration-date": "2018-05-10T07:00:00.000Z",
"hostname": "example.com",
"port": 443,
"scts": [sct1, ... sctN],
"served-certificate-chain": [pem1, ... pemN],
"validated-certificate-chain": [pem1, ... pemN],
"source":
}
}
This report contains a heap of really useful information with the basics being the date-time of when the failure happened, the effective-expiration-date is when the policy will expire and the hostname and port of course. The more interesting fields are the scts which is an array of the SCTs delivered to the client if it got any, a copy of the served-certificate-chain as the client received it and then the validated-certificate-chain is the full chain the client built. Lastly, inside the SCTs that are delivered there will be a version, status, source and serialized_sct key.
{
"serialized_sct": "[serialized_sct]",
"source": "tls-extension",
"status": "valid",
"version": 1
}
The main thing we're going to be looking at there is the status field as the client really shouldn't be receiving SCTs that aren't valid and if it is, there's probably a big problem. The source tells us how the client got the SCT which could be embedded, ocsp or tls-extension, detailing which method was used and the version will either be 1 or 2.
Monitoring reports
With the browser now sending you these reports we have the ability to monitor them and know exactly what's happening with our certificates out in the wild. If there's a certificate out there that isn't CT qualified in Chrome, or other browsers in the future, they you can find out about it without your users having to report errors to you. Report URI is designed to quickly and easily provide that information and soon we will have alerting too. The account homepage gives you a quick indication of how many reports you've received and how much of your quota you've used.
Taking a look at the reports page you can see exactly what reports you've received, for which sites, and start to drill down into the report payloads which are parsed our for you into the separate column headings. This is where I got the example payloads from that I used above.
To finish up there's the graphs page where you can get a quick feel for your average report volumes and see spikes which usually indicate something worth looking into.
Useful links and tools
Once all certificates are logged into CT then monitoring for certificates issued for your domain becomes really easy. You can of course monitor the logs yourself manually but there are far easier and better ways to do this. Personally I use the Facebook CT Log Monitoring tool, which is crazy I know, but it's a great tool and it does the job perfectly. You can read more details on that here. You can get email notifications when a certificate is issued or my preferred method which is Facebook notifications that get pushed to all of my devices!
More recently Facebook announced that their CT monitoring tool would also look for certificates issued to domains that look very similar to your own so you can spot potential phishing domains too.
This is such an awesome feature and we're starting to see some of the power that CT gives us. You can now detect phishing domains that are homoglyphs of your site using CT! https://t.co/PDVdyYiWgY
— Scott Helme (@Scott_Helme) May 4, 2018
Here are some other useful links for further info:
My blog on CT: https://scotthelme.co.uk/certificate-transparency-an-introduction/
Report URI for CT reporting: https://report-uri.com
Info on the Expect-CT header: https://scotthelme.co.uk/a-new-security-header-expect-ct/
The CT project site: https://www.certificate-transparency.org/
SSL Mate CT log monitoring: https://sslmate.com/certspotter/
crt.sh allows you to quickly search for certs: https://crt.sh/
Censys also allows you to search for certs: https://censys.io/