Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

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.

You’ve deployed certificate automation with Certbot and your artisanally-crafted scripts, but you still got paged at 2am for an expired cert. You’ve discovered the difference between issuance automation and certificate automation.

CertBot assumes every server that needs a certificate should also know how to request one, validate domain ownership, handle renewals, and manage failures. This makes sense with a handful of servers. One server, one cert, done. But infrastructures grow. Now you’ve got web farms sharing wildcards, load balancers, mail servers, VPN appliances. The “every server for itself” model doesn’t scale and isn’t sustainable. Even the Let’s Encrypt community knows it.