Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

In 2015, only about 40% of websites used HTTPS. Today HTTPS is used over 95% of the time. The ACME protocol made that shift possible. The Automatic Certificate Management Environment (ACME) protocol enables software to automatically prove domain control to a certificate authority without any human involvement. No more generating CSRs by hand. No more copy-pasting into web forms. No more waiting for validation emails. ACME largely solved certificate issuance.

For twenty years, a stolen private key was a disaster. It meant total compromise. Every encrypted conversation, password transmitted, API call ever made was readable. Traffic was being recorded all the time, “just in case” your private key leaked out. The NSA even had a name for it: “harvest now, decrypt later.” Record all the encrypted traffic today. Steal the private keys tomorrow. Decrypt everything retroactively.

Clickhouse is an incredible database. Here at Certkit, we’ve long worked in the world of “No SQL” databases like Elasticsearch precisely for their ability to query large amounts of data. But for every database, there’s an amount of data that’s “Too big”. Too big to query quickly or too big to store affordably. Clickhouse manages to thread the needle by efficiently storing truly ridiculous amounts of data while still providing impressive query performance.

In the last post we discussed why we’re building our own Certificate Transparency (CT) search tool. There’s good background on the CT ecosystem in that post, so check it out if you haven’t. This post assumes a certain understanding of terminology covered previously. Now that we know where the CT logs live, and the different kinds of logs, we need to start reading them.

Every TLS certificate issued by a root Certificate Authority (CA) ends up in one more more publicly accessible logs. These logs, collectively, make up the Certificate Transparency (CT) ecosystem. Unfortunately the logs are not very searchable. You can’t easily type in a domain and find all associated certificates. At CertKit we’re building CT monitoring capabilities to notify our customers when a new certificate is issued.

Last week, someone commented on my post about 47-day certificates: This perfectly captures our collective delusion that SSL certificate revocation works. You click a button, the certificate stops working. And why wouldn’t we believe that? Every CA has a big “Revoke Certificate” button right there in the dashboard. It must do something, right? Here’s the dirty truth: most revoked certificates keep working.

Turns out the scariest thing about SSL certificates isn’t when they expire. It’s when they don’t. I wrote about the CA/Browser fight that led to the 47-day certificate mandate. CAs crying about lost revenue, browsers flexing their root program authority, enterprises stuck in the middle. But nobody talks about the security research that started it all: BygoneSSL at DEFCON 2018. Two researchers mining Certificate Transparency logs found something surprising.

For twenty years, Certificate Authorities ran the perfect protection racket. The CAs had a beautiful monopoly. Browsers needed them to keep users safe. Websites needed them to look legitimate. Everyone paid up, nobody asked too many questions. Then the cryptography of most certificates (SHA-1) got shattered, and the browsers realized they’d been played.

You were tired of renewing all those certificates, and Certbot looked so easy. Now you have scripts thousands of lines long filled with command line incantations you have to Google every time you open it. The script is running on all the critical servers. And some of the printers. If someone looks at it the wrong way, a certificate expires.