Operations | Monitoring | ITSM | DevOps | Cloud

CertKit Private PKI: A private certificate authority without running one yourself

In May I wrote that you probably don’t need private PKI for internal infrastructure, because DNS validation gets a publicly trusted certificate onto hosts that never touch the internet. In June I pointed out that Apple enforces an 825-day cap on private certificates, so your own CA doesn’t even free you from the browser vendors. Two days ago I told you that public client certificates stop renewing in October, and that the replacement is a private certificate authority.

Public mTLS client-auth certificates stop renewing in October

Chrome’s root program decides what certificates will be trusted by Chrome, and what they are allowed to do. Recently, Google decided that client authentication isn’t on the list. Under Chrome Root Program Policy v1.8, every certificate issued on or after March 15, 2027 can assert only one Extended Key Usage (EKU): server authentication. Let’s Encrypt moved early.

How the TLS handshake works, and why half of it is gone

Every HTTPS connection starts with a TLS handshake. It’s the security check, answering “are you who you say you are?” and “how are we going to keep this conversation secret?”. There’s a lot going on during the handshake, and there used to be even more before it all got hacked and removed. And that’s useful to understand, the modern TLS 1.3 handshake is short because everything else got compromised.

Certificate deployments just got an easy mode

The old deployment flow expected a lot from you. You had to know what format your certificate needed to be in. You had to know where it should be stored on the target system. Then you had to review and customize a deployment script in a code editor before anything ran. It turns out most of you don’t want to do that. And fair enough, staring at a script editor when you just want a certificate on your Exchange server is a little intimidating.

One SSL certificate on multiple servers

Every certificate renewal automation tool has to answer one architecture question before it does anything else: where does the private key get generated? A reader who used to be “the certificate guy” at his organization emailed me this week to ask about exactly that: It’s the right instinct. It’s also how most automation tools work. Certbot generates the key on the server, builds a certificate signing request, and the private key never leaves the machine.

Automating SonicWall Certificate Deployment with the SonicOS API

How do we keep our Sonicwall certificates up to date as certificate lifetimes get shorter? We’re already at 200 day certs with 100 then 47 day certificates coming soon. A certificate you used to touch once every year now needs replacing up to twelve times a year. Doing this by hand is out of the question, no one has the time. Even if they did, the frequent updates is just asking for mistakes. Luckily, this can be automated using the SonicOS API.

Quantum is the least interesting part of quantum certificates

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.

We wrote the docs

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.

Certificate lineage: the concept your tools already use but nobody named

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.