Operations | Monitoring | ITSM | DevOps | Cloud

On June 3, Let’s Encrypt announced that the post-quantum web is going to run on something called Merkle Tree Certificates. The internet did what it does and turned this into a doomsday Q-Day countdown. The quantum computers are coming, your certificates are about to break, panic! Unlike every other security vendor, I’m not worried about quantum computers. But the announcement is still worth your attention. Just not for the reason you’ve been told.

Most security vendors hide their documentation behind a login. Some don’t write it at all. You get a sales page, a demo, and a request to install an agent on your servers, and you’re expected to trust that the thing does what the marketing says. That’s backwards. So we wrote the docs, and we put all of them at certkit.io/docs. No login, no account gate, no “contact us for details.” You can read every page before you create an account.

The word “certificate” means too many different things. When someone says “the certificate for example.com,” they might mean the public key the CA signed. They might mean the key-pair sitting on the filesystem. They might mean the signature that expires in 47 days. Or they might mean all the things together, that you’ve been renewing for the last 10 years. That last one doesn’t have a name in any PKI standard. And it should.

Two things shipped this week. One is for the MSPs who manage certificates on behalf of other companies. The other lets you run the shorter 45-day renewal cycle today.

The pitch for private PKI gets more compelling every year. Public certificate lifetimes are down to 200 days, dropping to 47 by 2029. If you run your own private certificate authority, you make your own rules. Issue certificates for as long as you want, skip the renewal churn. Let’s Encrypt and DigiCert don’t get to tell you what to do. Apple does though.

Running your own certificate authority sounds like the responsible choice for internal infrastructure. Distribute your root cert to every machine and issue certs internally. In practice, you spend the next six months chasing down every device, contractor laptop, and vendor console that didn’t get root installed. The warnings come back. And when they do, people click through them, because they always have. There’s a simpler path, and most teams don’t know it exists.

Certificate automation does a lot of work on your behalf. Agents running on your servers, talking to certificate authorities, deploying certs to your infrastructure. At some point someone (your CISO, your auditor, or your own brain at 3am) is going to ask: what exactly happened, and when? Today we’re shipping audit logs. Every action taken in CertKit is now recorded: logins, invitations, certificates added, issued, renewed, revoked, and deployed. Agent registrations, approvals, and config changes.

Getting a certificate from a CA is a solved problem (ACME). Distributing it to the rest of your infrastructure is not. Your F5 has its own API. Your Palo Alto has a different one. Azure Key Vault is a third thing entirely, and the appliance in the back of the rack only has an SSH interface.

I’m an old engineer at heart. Many of my ideals were formed by Joel’s Things You Should Never Do, Fred’s No Silver Bullet, and Brian’s Big Ball of Mud. One of my favorites was Greenspun’s Tenth Rule: The joke isn’t really about programming languages. It’s about a pattern: certain problems have a shape, and no matter how you approach them, you end up building the same solution, in the same order, until you arrive at the same messy place.

A few practical improvements this week, mostly driven by what we’re learning as customers deploy CertKit into larger infrastructures.