Public mTLS client-auth certificates stop renewing in October
Chrome’s root program is pulling mTLS client authentication out of the public web PKI. Let’s Encrypt got there first, and the last client certificates they issued expire in early October.
Chrome’s root program is pulling mTLS client authentication out of the public web PKI. Let’s Encrypt got there first, and the last client certificates they issued expire in early October.
Every HTTPS connection starts with a TLS handshake. It’s a lot shorter than it used to be because twenty years of attacks removed a lot of insecure steps.
Let’s Encrypt just committed to Merkle Tree Certificates for a post-quantum web. I don’t think quantum computers are close. The plan is still worth your attention, just not for the reason the headlines give.
PKI has precise terminology for almost everything. The one thing it never named is the series of certificates you’ve been renewing for years. Here’s what it is, why it matters now, and why your tools already know about it.
Running a private CA to escape the public cert treadmill makes sense. Apple still enforces an 825-day validity limit in Safari on every TLS certificate, no matter who issued it.
Most teams assume internal infrastructure needs a private CA. It doesn’t - and skipping it saves you from a maintenance burden that never fully works anyway.
Certificate validity is dropping from 398 days to 47 days by 2029. Here is the canonical schedule, what’s driving it, and what it does to your renewal workload.
Let’s Encrypt ran their first annual mass revocation drill, shortening ARI renewal windows across 3 million production certificates. Here’s what happened.
When a CA has to revoke hundreds of thousands of certificates on a short deadline, email notifications aren’t enough. ARI is the protocol that lets the CA tell your client directly: renew now. Here’s how it works, and why most ACME clients can’t actually respond in time.
The bar closes March 15. After that, no CA can serve you a 398-day certificate. If you’re still managing commercial SSL certs manually, you have two weeks to grab one last round of full-year runway before the 200-day era begins.
A stolen TLS private key sounds catastrophic. But thanks to forward secrecy, it can’t decrypt recorded traffic. The only thing left is server impersonation, and that requires network position that ranges from “be in the same room” to “be a nation-state.” We looked at the data on how often this actually happens.
We wrote about BygoneSSL and the 1.5 million domains with certificates owned by someone else. Then we bought certkit.dev and found one on our own domain. A DigiCert certificate, still valid for 98 days, issued to whoever owned this domain before us. Here’s what we found, what we tried to do about it, and what happened when we tried to revoke it.
IT teams keep buying certificates from DigiCert and Sectigo because free feels risky. But the assumptions behind that trust are a decade old. Let’s Encrypt now secures 64% of the web, is funded by Google and AWS, and uses the same encryption as your $500 certificate. The real question isn’t whether free is good enough. It’s whether you’ve examined your objections lately.
You’ve been using wildcard certificates for years because they were simpler. One cert, one renewal, copy it everywhere. But now you’re automating anyway. If certificate management is no longer painful, do you still need wildcards? Or are they solving a problem that no longer exists?
HTTPS went from 40% to over 90% of web traffic in a decade and the ACME protocol made that possible. Here’s how the ACME order flow works, how HTTP-01 and DNS-01 challenges differ, and what ACME still doesn’t handle.
We used to treat private keys like plutonium because losing one meant every encrypted conversation ever was compromised. Perfect Forward Secrecy fixed that. Now each connection gets temporary keys that vanish after use, so stolen certificates can’t decrypt old traffic. It makes private keys safe to touch.
In this post we’ll write Golang code to pull Certificate Transparency Log entries and process them at scale.
Every TLS certificate ever issued for a domain is recorded in public Certificate Transparency logs. Here’s how to search them to find mis-issued certificates, unauthorized changes, or infrastructure you didn’t know existed.
SSL Certificate revocation is so broken that browser vendors gave up trying to fix it. Chrome manually curates 24,000 ‘important’ revocations out of 2 million. Firefox uses bloom filters that flag valid certs as revoked. Safari does something nobody can document. The industry’s solution? Pretend 47-day certificates solve the problem.
When domains change hands, old certificates don’t. Two researchers at DEFCON found 1.5 million domains with valid certs owned by someone else. This is the security research that killed long certificates. And why 47-day certificates aren’t just browser bureaucracy. They’re fixing a problem we ignored for 20 years.
For twenty years, Certificate Authorities ran the perfect protection racket. Then SHA-1 got shattered, Apple went rogue, and certificates went from lasting 3 years to 47 days. This is the story of how browsers broke the CA cartel, and why your manual certificate process is about to become your biggest problem.
New writing on certificate management, sent when there is something worth your time. Shrinking lifetimes, ACME on real infrastructure, the occasional outage post-mortem.