Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

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.

The CA/Browser Forum set 47-day certificates as target for 2029. Let’s Encrypt decided to implement it a year earlier. In December 2025, Let’s Encrypt announced their roadmap to cut certificate lifetimes from 90 days to 45 days by February 2028, a full year ahead of the industry mandate. It’s exactly what we’d expect from the CA that made automation mandatory from day one.

When you’re managing a handful of certificates, one big list works fine. Add a few dozen more and things get messy. Add multiple teams or projects and you’ve got a problem. Who should have access to the production certificates? What about staging? Does the contractor working on the marketing site really need to see your internal infrastructure? CertKit now supports multiple applications from our roadmap to help you sort this out.

It seems like every service wants proof you control your domain. Certificate authorities need it to issue certificates. Email platforms need it to authorize sending. Analytics needs it to gather data. Just add this magic TXT record to your DNS, wait for propagation, click verify. It works fine when it’s a one-time setup, but certificate lifetimes are dropping to 47 days, and you won’t be able to keep up on that schedule.