New on the blog: a full walkthrough of the TLS handshake. It leads with the TLS 1.3 flow step by step, then covers how we got here: BEAST, CRIME, POODLE, FREAK, Logjam, and SHAttered each removed a piece of the old handshake. Diagrams throughout, including the SSL 3.0 flow most of us learned that no longer exists.
Deployments got an easy mode. The old flow expected you to know the cert format, the store location, and to review a deployment script in an editor. The new default: pick a template, name it, select the certificate, fill in any template variables. The full script is still behind the Advanced view toggle.
Also new: built-in templates for auto-detected Microsoft Exchange, SQL Server, SSRS, and Citrix NetScaler.
Details: https://www.certkit.io/blog/easy-mode-certificate-deployments
Private PKI is next. Comment if you want an early look.
A reader asked why an automation tool would ever generate private keys anywhere but the server that uses them. Fair question, so I wrote up the answer. Any shared certificate (wildcard or an HA pool serving one name) forces the key to move between machines, so the local-generation property is already gone. PFS makes a moving key less scary than it used to be. The argument: centralize issuance and treat key distribution as a designed system, not scp in cron.
https://www.certkit.io/blog/ssl-certificate-multiple-servers
If you manage SonicWall firewalls, the SonicOS certificate import API is a mess. It is barely documented and changed between 7.1 and 7.3: the 7.1 request 404s on 7.3, the password field moved, and the only reliable way to find the 7.3 format is watching what the admin UI sends in the browser. The new request then fails on 7.1, so any automation has to detect the version first.
Writeup with the details: https://www.certkit.io/blog/automating-sonicwall-certificates
u/toddhgardner went on RunAs Radio to talk through the 47-day SSL certificate change and what it means if you manage certificates at scale.
Short version: the public maximum is already down to 200 days as of March 2026, heading to 47 by 2029. The driver is that revocation never really worked, so short lifespans are the workaround. The catch is renewal frequency goes up roughly 8x, which is where manual processes fall apart.
Reading through the Merkle Tree Certificate design Let's Encrypt just committed to. The size math is the whole story: ML-DSA signatures are ~2,420 bytes vs 64 for ECDSA, and a handshake carries five of them. MTCs batch-sign into one tree, so the leaf becomes a single inclusion proof and the handshake ends up smaller than today's. Transparency is built in since a cert can't exist outside the published tree. Knock-on effect: it removes the cost barrier to even shorter cert lifetimes.
https://www.certkit.io/blog/quantum-is-the-least-interesting-part
New post explaining one of the weirder ambiguities in how we (and most cert tools) use the word "certificate." Short version: when CertKit says "certificate," we mean something closer to what Certbot calls a lineage (the ongoing record for a hostname, not any single point-in-time cert). Post walks through where the term comes from and why it matters more at shorter lifetimes.
We shipped managed accounts this week, aimed at MSPs.
You can create a fully-managed account for a client, set up the certs, and deploy agents, then hand the account over for them to run. It's a real account with its own users, SSO, logging, and monitoring, not a folder inside yours.
After handoff your team can keep working inside the client account to support them, fully logged and audited. You can co-brand it too.
Two Apple docs, two different numbers. HT211025 exempts private CAs from the 398-day limit. HT210176 covers all TLS server certs: 825-day max, no private CA carve-out. Apple's trustd logs it: "Non-system-trusted leaf validity period longer than 825 days." Safari enforces it.
https://www.certkit.io/blog/apple-doesnt-care-who-signed-your-certificate
PSA: you don't need a private CA to get trusted SSL certificates for internal infrastructure.
DNS-01 ACME challenges prove domain ownership through a DNS record. Your server never needs to be internet-reachable. That means real, browser-trusted SSL certs for internal portals, management consoles, and network appliances, with no root cert distribution and no internal CA to maintain. CertKit handles DNS delegation and appliance deployment if you want renewals fully automated.
https://www.certkit.io/blog/private-pki-internal-infrastructure
Audit logs are live.
Every action in your account is now logged: certificate issuances, renewals, revocations, and deployments. Agent registrations, approvals, and config changes. Domain edits. User logins. All timestamped and attributed to the user or system that triggered it.
Importance flags let you filter down to the consequential actions without scrolling through routine events.
Available for Business and Enterprise customers.
The CA/Browser Forum's Ballot SC-081 is already in effect. 200-day max as of March 2026, 100 days in March 2027, 47 days in March 2029.
The math on renewal workload scales linearly: 50 certificates managed manually goes from ~50 renewals a year at 398 days to ~400 at 47 days. Same cert count, 8x the operations work.
Wrote up the canonical schedule and what it does to teams still running manual processes: https://www.certkit.io/blog/shrinking-certificate-lifetimes
Todd's Tenth Rule: any sufficiently complicated SSL certificate script contains a bad implementation of half a certificate lifecycle manager.
If you've been running Certbot in your environment for a few years, you've probably built most of a certificate management system without realizing it. The shared folder, the DNS creds in the script, the 30-day expiry email, the audit spreadsheet.
https://www.certkit.io/blog/todds-tenth-rule-certificate-automation