Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Certbot is good software in the classic Linux tradition: it does one thing simply and expects you to chain it together with everything else. One server, one certificate, done. The trouble is that most environments are not simple. And the moment yours isn’t, you discover that renewing a certificate and getting it deployed are two different problems, and deployment is your problem.

In July 2024, DigiCert discovered they’d been issuing certificates with improper domain validation for five years. They gave customers 24 hours to replace 83,000 certificates. CISA issued an emergency alert. Critical infrastructure operators couldn’t meet the deadline. Some customers sued. That’s what mass revocation looks like in practice. The CA finds a compliance problem, the clock starts, and everyone scrambles. ACME Renewal Information (ARI) is the fix.

Two new features this week, both pushing in the same direction: make certificate lifetimes someone else’s problem.

On May 21, 2019, LinkedIn’s URL shortener went down. The certificate had expired. Millions of people cried out in terror when they couldn’t click on AI link bait. The interesting part: LinkedIn had renewed the certificate ten days earlier. The renewal succeeded. The certificate just never made it to the server. The renewed cert existed somewhere, but the server still served the old one. Most certificate automation is built to prevent the “I forgot to renew” problem.

We’ve got a boatload of features to show off this week. We knocked out some of the most common requests, user management, single-sign on, and my personal favorite: the weekly email summary.

The bell rings. Last call for 398-day certificates is March 15. After that, every CA is required to cut you off at 200 days. Some have already stopped serving them early. The rest follow in two weeks. The irony of good certificate management is that when it works, nobody notices. No alerts, no outages, no 2am pages. The only time it gets attention is when something expires. Which means the teams doing it well rarely have the budget or the political capital to fix the process before it breaks.

The CertKit Agent 1.6 is out. Three things in this release, all of them coming from the same underlying problem: the shorter certificate lifespans get, the more certificate deployment has to behave like real software deployments.

Security vendors love the man-in-the-middle attack. It’s the boogeyman of every TLS marketing page. Some shadowy figure intercepting your traffic, reading your secrets, stealing your data. A man-in-the-middle attack is when an attacker positions themselves between two parties on a network to intercept the traffic flowing between them. In the context of TLS, that means an attacker who can present a valid certificate can read everything in plaintext and proxy it on to the real server.

A few months ago I wrote about BygoneSSL and the 1.5 million domains with valid certificates owned by someone else. Domains change hands but certificates don’t know. The old owner keeps their private key, and the certificate keeps working. It’s an industry problem, but it turns out it’s our problem too. We purchased certkit.dev for internal development and demos.

Getting a certificate is the easy part. Getting it onto every server that needs it, in the right format, with the right permissions, and restarting the right services? That’s the part where things fall apart. The CertKit Agent closes that gap, just released from our product roadmap.