Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

We just published the CertKit roadmap.

There’s a particular flavor of skepticism that shows up whenever someone suggests using Let’s Encrypt. The security team crosses their arms. “Free certificates? For production? We’re a serious organization. We use Sectigo.” I get it. You’ve been buying certificates from the same vendors for twenty years. They send you invoices, you pay them, certificates appear. It feels responsible, and free feels like a trap. But is it?

With the ACME protocol, to issue a certificate you have to prove you control the domain. The CA gives you a challenge, you complete it, and they issue your cert. The trouble is that every validation method has tradeoffs. And as certificate lifetimes get shorter, those tradeoffs will get more painful. DNS-PERSIST-01 is a new approach coming in 2026 that trades proof-of-freshness for easier operations.

You’ve used wildcard certificates for years. It made your life easier. Once a year you’d renew your wildcard certificate, and copy it around to all the servers. It was way too complicated and expensive to get a unique certificate for every system. But now certificate lifetimes are shrinking to 47 days by 2029 and it’s not going to work anymore. You need to automate your certificates. Soon.

We shipped some big updates this week!

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.