I understand OP's frustration, but the alternate view is that mandating better practices is a forcing function for businesses that otherwise don't give a shit about users or their privacy or security.
For all the annoyance of SOC2 audits, it sure does make my manager actually spend time and money on following the rules. Without any kind of external pressure I (as a security-minded engineer) would struggle to convince senior leadership that anything matters beyond shipping features.
I think a large enough org that needs many different certificates should have an internally-trusted CA. That would then allow the org to decide their own policy for all their internal facing certificates.
Then you only have to follow the stricter rules for only the public facing certs.
I do not think PKI will survive the 47 day change. I am not sure the CAB will survive that change. It seems extremely apparent the people who made the decision have neither any relevant experience in IT nor any practical understanding of security, and I think they've finally flown too close to the sun.
Automated renewal is... probably about a decade or two from being supported well enough to be an actual answer.
In our case, we'll be spending the next couple years reducing our use of PKI certificates to the bare functional minimum.
I think the author has missed the point of the 47 day expiry.
It is short enough to force teams to automate the process.
You're not supposed to be human-actioning something every month.
But yes, it'll be a huge headache for teams that stick their head in the sand and think, "We don't need to automate this, it's just 6 months".
As the window decreases to 3 months it'll be even more frustrating, and then will come a breaking point when it finally rests at 47 days.
But the schedule is well advertised. The time to get automation into your certificate renewal is now.
In the real world however, this will be a LOT of teams. I think the organisations defining this has missed just how much legacy and manual processes are out there, and the impact that this has on them.
I don't think this post makes that argument well enough, instead trying to argue the technical aspect of ACME not being good enough.
ACME is irrelevant in the face of organisations not even trying, and wondering why they have a pain every 6 weeks.
I believe the low maximum lifetimes are becoming a thing because revocation failed.
CRLs become gigantic and impractical at the sizes of the modern internet, and OCSP has privacy issues. And there's the issue of applications never checking for revocation at all.
So the obvious solution was just to make cert lifetimes really short. No gigantic CRLs, no reaching out to the registrar for every connection. All the required data is right there in the cert.
And if you thought 47 days was unreasonable, Let's Encrypt is trying 6 days. Which IMO on the whole is a great idea. Yearly, or even monthly intervals are long enough that you know a bunch of people will do it by hand, or have their renewal process break and not be noticed for months. 6 days is short enough that automation is basically a must and has to work reliably.
I've spent 15+ minutes searching, and the digicert (linked to in the article), and other cert providers all reference a vote on "Multi-Perspective Issuance Corroboration (MPIC)".
Everywhere I've read, one "must validate domain control using multiple independent network perspectives". EG, multiple points on the internet, for DNS validation.
Yet there is not one place I can find a very specific "this is what this means". What is a "network perspective", searching shows it means "geographical independent regions". What's a region? How big? How far apart from your existing infra qualifies? How is it calculated.
Anyone know? Because apparently none of the bodies know, or wish to tell.
The decreasing validity time pushes for the process to be automated, and automation reduces the possible human errors.
Many things need to be run and automated when running stuff, I don't understand what makes SSL certificates special in this.
For a hobbyist, setting up certbot or acme.sh is pretty much fire and forget. For more complex settings well… you already have this complexity to manage and therefore the people managing this complexity.
You'll need to pick a client and approve it, sure, but that's once, and that's true for any tool you already use. (edit: and nginx is getting ACME support, so you might already be using this tool)
It's not the first time I encounter them, but I really don't get the complaints. Sure, the setup may take longer. But the day to day operations are then easier.
With Azure-hosted sites, I find it's significantly easier to have Microsoft perform all certificate management for us. All we do is verify that we own the domain, and then they do all the certificate management for us.
When I saw the 47-day expiration period, it made me wonder if someone is trying to force everyone onto cloud solutions like what Azure provides.
The old geezer in me is disappointed that it's increasingly harder to host a site on a cable modem at home. (But I haven't done that in over two decades.)
There's two sides to this, if it's not a public service, why should it have a certificate from a public CA? If your risk assessment says that you do not need MPIC, then just don't do that, yourself.
The second side is that if it's so tedious to approve and install, use solutions that require neither. Surely you don't need to have some artisanal certificate installation process that involves a human if you already admit that stricter issuance reduces no risk of yours. Thus, simplify your processes.
There are automated solutions to pretty much all platforms both free and paid. Nginx has it, I just checked and Apache has a module for this as well. Could the author write a blog post about what's stopping them from adopting these solutions?
In the end I can think of *extremely* few and niche cases where any changes to a computer system are actually (human) time-consuming due to regulatory reasons that at the same time require public trust.
The web today is a rotting carcass with various middlemen maggots crawling all over it and gorging themselves on the decay. The only real discussion to be had is what to replace it with and how to design the new protocols to avoid the same issues.
Looking at the changes going on in computing regarding the need for constantly updating certificates for a website, verified identity to develop mobile apps etc. it's clear there is a background push for control of everything such that when things are considered problems they can promptly be cut off from everything all at once.
Since the advent of LetsEncrypt, ACME, and Caddy I haven't thought about SSL/TLS for more than about an hour per year, and that's only because I forget the steps required to setup auto-renewal. I pay nothing, I spend a tiny amount of time dealing with it, and it works brilliantly.
I'm not sure why many people are still dealing with legacy manual certificate renewal. Maybe some regulatory requirements? I even have a wildcard cert that covers my entire local network which is generated and deployed automatically by a cron job I wrote about 5 years ago. It's working perfectly and it would probably take me longer to track down exactly what it's doing than to re-write it from scratch.
For 99.something% of use cases, this is a solved problem.
It's strange: SSL certificates (and maybe domain name registrations?) are one of the only "ticking time bomb" elements present in every modern web stack, whether a static site or not. By "ticking time bomb" I mean that there's a hard date N weeks/months from now where your site will definitely stop working, unless some external pile of dependencies work smoothly to extend that date.
Software didn't have that sort of "ticking time bomb" element before, I think?
I think I understand why it's necessary: we have a single, globally shared public namespace of domain names, which we accept will turn over their ownership over the long run, just like real estate changes hands. So we need expiration dates to invalidate "stale" records.
We've already switched over everything to Let's Encrypt. But I don't think anyone should be under the delusion that automation / ACME is failproof:
(These are generally not issues with the software per se, but misconfiguration, third-party DNS API weirdness, IPv6, rate limits, or other weird edge cases.)
Anyway, a gentle reminder that Let's Encrypt suggests monitoring your SSL certificates may be "helpful": https://letsencrypt.org/docs/monitoring-options/ (Full disclosure: I wrote the most recent addition to that list, with the "self-hosted scripts".)
I think that the author is a bit confused about email validation.
When I was doing this, via email, if you wanted a certificate for sub.subdomain.example.com - the list of email addresses were in order something like hostmaster@sub.subdomain.example.com and hostmaster@example.com - you clicked the radio option that best suited you and you were good to go. You don't need email addresses for every subdomain.
The one complaint that I think is valid is that automating wildcard certificates at the moment is really tricky. And that really is because most of the DNS providers do not have proper APIs for it.`
Nobody has yet mentioned how certificates induce and support churn.
In 2025 it's not possible to create an app and release it into the world and have it work for years or decades, as was once the case.
If your "developer certificate" for app stores and ad-hoc distribution is valid for a year, then every year you must pay a "developer program fee" to remain a participant. You need to renew that cert, and you need to recompile a new version within a year. Which means you must maintain a development environment and tools on an ongoing basis for an app that may be feature- and operationally-complete.
All this is completely unnecessary except when it comes to reinforcing hegemony of app-store monopolists.
What is obnoxious is that certificate transparency logs mean that you now have to effectively centrally register any new domain you put online. That means you instantly see a whole load of traffic to your domain from bots, scrapers, beg bounty scanners etc. Any new site has to be designed to handle that baseline of traffic.
I understand the point of CTL's and it's necessary given that every browser and device is configured to trust CA's that you wouldn't actually trust. It's had awful side effects for people who want to host low traffic sites, or fly under the radar for whatever reason.
44 comments
[ 3.5 ms ] story [ 53.3 ms ] threadFor all the annoyance of SOC2 audits, it sure does make my manager actually spend time and money on following the rules. Without any kind of external pressure I (as a security-minded engineer) would struggle to convince senior leadership that anything matters beyond shipping features.
Then you only have to follow the stricter rules for only the public facing certs.
Automated renewal is... probably about a decade or two from being supported well enough to be an actual answer.
In our case, we'll be spending the next couple years reducing our use of PKI certificates to the bare functional minimum.
It is short enough to force teams to automate the process.
You're not supposed to be human-actioning something every month.
But yes, it'll be a huge headache for teams that stick their head in the sand and think, "We don't need to automate this, it's just 6 months".
As the window decreases to 3 months it'll be even more frustrating, and then will come a breaking point when it finally rests at 47 days.
But the schedule is well advertised. The time to get automation into your certificate renewal is now.
In the real world however, this will be a LOT of teams. I think the organisations defining this has missed just how much legacy and manual processes are out there, and the impact that this has on them.
I don't think this post makes that argument well enough, instead trying to argue the technical aspect of ACME not being good enough.
ACME is irrelevant in the face of organisations not even trying, and wondering why they have a pain every 6 weeks.
CRLs become gigantic and impractical at the sizes of the modern internet, and OCSP has privacy issues. And there's the issue of applications never checking for revocation at all.
So the obvious solution was just to make cert lifetimes really short. No gigantic CRLs, no reaching out to the registrar for every connection. All the required data is right there in the cert.
And if you thought 47 days was unreasonable, Let's Encrypt is trying 6 days. Which IMO on the whole is a great idea. Yearly, or even monthly intervals are long enough that you know a bunch of people will do it by hand, or have their renewal process break and not be noticed for months. 6 days is short enough that automation is basically a must and has to work reliably.
Everywhere I've read, one "must validate domain control using multiple independent network perspectives". EG, multiple points on the internet, for DNS validation.
Yet there is not one place I can find a very specific "this is what this means". What is a "network perspective", searching shows it means "geographical independent regions". What's a region? How big? How far apart from your existing infra qualifies? How is it calculated.
Anyone know? Because apparently none of the bodies know, or wish to tell.
What does this even mean? Does he check the certificates for typos, or that they have the correct security algorithm or something?
I'm pretty sure such an "approval" could be replaced by an automatic security scanner or even a small shall script
Many things need to be run and automated when running stuff, I don't understand what makes SSL certificates special in this.
For a hobbyist, setting up certbot or acme.sh is pretty much fire and forget. For more complex settings well… you already have this complexity to manage and therefore the people managing this complexity.
You'll need to pick a client and approve it, sure, but that's once, and that's true for any tool you already use. (edit: and nginx is getting ACME support, so you might already be using this tool)
It's not the first time I encounter them, but I really don't get the complaints. Sure, the setup may take longer. But the day to day operations are then easier.
When I saw the 47-day expiration period, it made me wonder if someone is trying to force everyone onto cloud solutions like what Azure provides.
The old geezer in me is disappointed that it's increasingly harder to host a site on a cable modem at home. (But I haven't done that in over two decades.)
The second side is that if it's so tedious to approve and install, use solutions that require neither. Surely you don't need to have some artisanal certificate installation process that involves a human if you already admit that stricter issuance reduces no risk of yours. Thus, simplify your processes.
There are automated solutions to pretty much all platforms both free and paid. Nginx has it, I just checked and Apache has a module for this as well. Could the author write a blog post about what's stopping them from adopting these solutions?
In the end I can think of *extremely* few and niche cases where any changes to a computer system are actually (human) time-consuming due to regulatory reasons that at the same time require public trust.
I'm not sure why many people are still dealing with legacy manual certificate renewal. Maybe some regulatory requirements? I even have a wildcard cert that covers my entire local network which is generated and deployed automatically by a cron job I wrote about 5 years ago. It's working perfectly and it would probably take me longer to track down exactly what it's doing than to re-write it from scratch.
For 99.something% of use cases, this is a solved problem.
Software didn't have that sort of "ticking time bomb" element before, I think?
I think I understand why it's necessary: we have a single, globally shared public namespace of domain names, which we accept will turn over their ownership over the long run, just like real estate changes hands. So we need expiration dates to invalidate "stale" records.
We've already switched over everything to Let's Encrypt. But I don't think anyone should be under the delusion that automation / ACME is failproof:
https://github.com/certbot/certbot/issues?q=is%3Aissue%20ren...
https://github.com/cert-manager/cert-manager/issues?q=is%3Ai...
https://github.com/caddyserver/caddy/issues?q=is%3Aissue%20A...
(These are generally not issues with the software per se, but misconfiguration, third-party DNS API weirdness, IPv6, rate limits, or other weird edge cases.)
Anyway, a gentle reminder that Let's Encrypt suggests monitoring your SSL certificates may be "helpful": https://letsencrypt.org/docs/monitoring-options/ (Full disclosure: I wrote the most recent addition to that list, with the "self-hosted scripts".)
> I am responsible for approving SSL certificates for my company.
And that is exactly what the requirements are intending to prevent. Automation is the way.
The system is working!
When I was doing this, via email, if you wanted a certificate for sub.subdomain.example.com - the list of email addresses were in order something like hostmaster@sub.subdomain.example.com and hostmaster@example.com - you clicked the radio option that best suited you and you were good to go. You don't need email addresses for every subdomain.
What does that even mean? Is he smelling them to check for freshness?
I get process around first time request perhaps to ensure it’s set up right, but renewals?
> My stakeholders understand their roles and responsibilities
Oh no. All that’s missing here is a committee and steering group and daily stand ups
In 2025 it's not possible to create an app and release it into the world and have it work for years or decades, as was once the case.
If your "developer certificate" for app stores and ad-hoc distribution is valid for a year, then every year you must pay a "developer program fee" to remain a participant. You need to renew that cert, and you need to recompile a new version within a year. Which means you must maintain a development environment and tools on an ongoing basis for an app that may be feature- and operationally-complete.
All this is completely unnecessary except when it comes to reinforcing hegemony of app-store monopolists.
I understand the point of CTL's and it's necessary given that every browser and device is configured to trust CA's that you wouldn't actually trust. It's had awful side effects for people who want to host low traffic sites, or fly under the radar for whatever reason.
One option to avoid this could be to use the DNS-01 challenge to get a wildcard cert from Let’s Encrypt. Then CT will not expose your subdomains.