SSL certificate requirements are becoming obnoxious
chrislockard.net
chrislockard.net
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.
So unless you’re part of the folks fine heavily curating (or jailbreaking) devices to make the above possible, PKI is hardly a solved problem. If anything it remains a nightmare for orgs of all sizes. Even in BigCo at a major SV company, we had a dedicated team to manage PKI for internal certificates - complete with review board, justification documents, etc - and that still only bought us a manual process with a lead time of 72 hours for a cert.
That said, it is measurably improved and I do think ACME/certbot/LE is on the right track here. Instead of constant bureaucratic revisioning of rules and standards documents, I believe the solution here is a sort of modern Wireguard-esque implementation of PKI and an associated certification program for vendors and devices. “Here’s the cert standard you have to accept, here’s the tool to automatically request and pin a certificate, here’s how that tool is configured for internal vs external PKI, and here’s the internal tooling standards projects that want to sign internal certs have to follow.”
Basically an AD CA-alike for SMB and Enterprise both. Saves me time having to get into the nitty gritty of why some new printer/IoT/PLC doesn’t support a cert, and improves the posture of the wider industry.
If the biggest issue is "we want to encrypt traffic" then the answer really should be something more automated. To put it another way, TLS certificates used to convey a lot of things. We had basic certs that said "you are communicating with the rightful owner of domain example.com" and we had EV certs that said "you are communicating with the rightful legal entity Example Org, who happens to own example.com" and so-on and so-forth.
But the thing is, we've killed off a lot of these certificate types. We don't have EV certs anymore. Let's Encrypt effectively democratized it to the point where you don't need to do any manual work for a normal "we want to encrypt data" certificate. I just don't understand what your specific requirements are, if they aren't directly "encrypt this traffic" focused, where you actually need valid certificates that work across the internet.
Put differently, if you're running an internal CA, you can push out your own certificates via MDM tools and then not worry about this. If you aren't running your own CA but you're implementing all of this pomp and circumstances, what are you trying to solve? Do you really need all of this ceremony for all of your devices and applications?
They've also blocked JavaScript access to things like cameras and microphones if you're not using HTTPS. If it were up to me they'd always block them and you'd have to install an app, but still.
It isn't that they are equal, just that it is difficult to tell them apart. The change over time is that UAs have more and more erred on the side of not trusting when there is any question.
Of course HTTPS sites with valid certificates could also be malware infested hot zones, but it is less likely. Sites with invalid certs are more likely to be a problem than those with no cert (the situation might imply a DNS poisoning issue for instance), and sites with no cert are a higher risk than those with a valid one.
At least we seem to have dropped the EV cert theatre, the extra checks done before issuing one of those were so easy to fake or work around in many cases that they essentially meant nothing [source: in DayJob we once had an EV cert for a client instance, and I know how easy it was to get because I was the person at our end who applied for it and installed it once issued].
EV certificates are no longer in use? Do you know why?
You can still buy EV certs if you want to donate money to a CA, but that's about all they accomplish.
To be more precise, the browsers de-emphasized them and removed any distinguishing marks or indicators that made them valuable. EV certs used to display the company name in the URL bar, but they were stripped back.
Just because someone’s homelab is fully cert’d through Caddy and LE that they slapped together over a weekend two years ago, doesn’t mean the process is trivial or easy for the masses. Believe me, I’ve been fighting this battle internally my entire career and I hate it. I hate the shitty state of PKI today, and how the sole focus seems to be public-facing web services instead of, y’know, the other 90% of a network’s devices and resources.
PKI isn’t a solved problem.
If you can do that, do that. It's great.
That being said, deploying and loading these certs is a fun adventure, even in somewhat modern software.
We're discovering a surprising amount of fairly modern software which handles certs in stupid ways. For example, if I recall right, NodeJS applications tend to load certificates to secure a connection to PostgreSQL into memory and never bother to reload. libpq on the other hand loads them on connection startup. Even Spring wasn't able to properly reload certificates 3-4 years ago and this was only added in recent versions with dynamic certificates - a colleague patched this in back in the day. Our loadbalancers folded the ticket of "Hey, reload these three certs" into the issue of reloading the entire configuration, including opening, closing ports, handing TCP connections over transparently, and a billion other topics.
Funny enough, if there is enough stuff running, there's not even an agreement on how to store stuff. Some stuff needs PEM-files, some stuff needs PKCS8 stores, some stuff wants 1-2 PKCS12 keyrings with certs and keys in there in separate entries. I even had to patch a PKCS12 handling library because one ruby library needed everything in one entry in a PKCS12 key store and there was no go-code under the sun to find to do this.
So there is a sunny place in which PKI is indeed solved. And besides that there is a deep dark hole that goes deeper than it should on earth.
Also, I used to do IT, I get it but what do you think the fix here is? You could also run your own CA that you push to all the devices and then you can cut certificates as long as you want.
> PKI isn’t a solved problem.
PKI is largely a solved issue nowadays. Software like Vault from hashicorp (it's FIPS compliant, too: https://developer.hashicorp.com/vault/docs/enterprise/fips) let you create a cryptographically-strong CA and build the automation you need.
It's been out for years now, integrating the root CA shouldn't be much of an issue via group policies (in windows, there are equivalents for mac os and gnu/linux i guess).
> Just because someone’s homelab is fully cert’d through Caddy and LE that they slapped together over a weekend two years ago, doesn’t mean the process is trivial or easy for the masses.
Quite the contrary: it means that the process is technically so trivial the masses can do it in an afternoon and live off it for years with little to no maintenance.
Hence, if a large organization is not able to implement that, the issue is in the organization, not in the technology.
You have no idea the environment they work in. The "skill issue" here is you thinking your basic knowledge of Vault matters.
> Software like Vault from hashicorp (it's FIPS compliant, too: https://developer.hashicorp.com/vault/docs/enterprise/fips) let you create a cryptographically-strong CA and build the automation you need.
They didn't tell you their needs, but you're convinced this vendor product solves it.
Are you a non-technical CTO by chance?
> there are equivalents for mac os and gnu/linux i guess
You guess? I'm sensing a skill issue. Why would you say it's solved for their environment, "I guess??"
> Quite the contrary: it means that the process is technically so trivial the masses can do it in an afternoon and live off it for years with little to no maintenance.
I'm sensing you work in a low skill environment if you think "home lab trivial" translates to enterprise and defense.
> Hence, if a large organization is not able to implement that, the issue is in the organization, not in the technology.
Absolutely meaningless statement.
* Yes, I have experience with Vault. I have deployed it internally, used it, loathed it, and shelved it. It’s entirely too cumbersome for basic PKI and secrets management in non-programmatic environments, which is the bulk of enterprise and business IT in my experience.
* You’re right, the organization is the problem. Let me just take that enlightened statement to my leadership and get my ass fired for insubordination, again, because I have literally tried this before with that outcome. Just because I know better doesn’t mean the org has to respect that knowledge or expertise. Meritocracies aren’t real.
* The reason I don’t solve my own PKI issues with Caddy in my homelab is because that’s an irrelevant skill to my actual day job, which - see the point above - doesn’t actually respect the skills and knowledge of the engineers doing the work, only the opinions of the C-suite and whatever Gartner report they’re foisting upon the board. Hence why we have outdated equipment on outdated technologies that don’t meet modern guidelines, which is most enterprises today. Outside of the tech world, you’re dealing with comparable dinosaurs (no relation) who see neither the value or the need for such slick, simplified solutions, especially when they prevent politicians inside the org from pulling crap.
I’ve been in these trenches for fifteen years. I’ve worked in small businesses, MSPs, school campuses, non-profits, major enterprises, manufacturing concerns, and a household name on par with FAANG. Nobody had this solved, anywhere, except for the non-profit and a software company that both went all-in on AD CA early-on and threw anything that couldn’t use a cert from there off the network.
This is why I storm into the comments on blogs like these to champion their cause.
PKI sucks ass, and I’m tired of letting DevOps people claim otherwise because of Let’s Encrypt and ACME.
I've deployed Vault both at home and in two different companies, doing anything from pki, mutual-tls, secret storage and other stuff.
> > Software like Vault from hashicorp (it's FIPS compliant, too: https://developer.hashicorp.com/vault/docs/enterprise/fips) let you create a cryptographically-strong CA and build the automation you need.
> They didn't tell you their needs, but you're convinced this vendor product solves it.
It was an example from the ecosystem of available tools but in general yes, Vault can do that. Mentioning FIPS compliance was about letting you know that the software can be used also in governative environments. It's not just a "homelab toy".
> Are you a non-technical CTO by chance?
Senior cloud engineer here. Worked anywhere from not-so-small companies (250 people, 100 engineers) to faangs (tens of thousands of engineers).
> > there are equivalents for mac os and gnu/linux i guess
> You guess? I'm sensing a skill issue.
You're attacking me on a personal level because you can't argue otherwise. That's a common logical fallacy ("Ad Hominem" - https://www.britannica.com/topic/ad-hominem). You basically have skill issue at debating =)
> Why would you say it's solved for their environment, "I guess??"
When you account Windows, Mac OS and Linux you're accounting for pretty much the totality of the desktop computing landscape. The last two macbooks I had for work came with the mac os equivalent of group policies with certificates installed etc etc. Enterprise-tier Linux distributions can do that as well (eg: Red Hat Enterprise Linux).
> I'm sensing you work in a low skill environment if you think "home lab trivial" translates to enterprise and defense.
Again, worked anywhere from companies with 250 people to FAANGs. You have skill issue at sensing, it seems.
To get back to the point: homelab "triviality". In a way, yes. Large enterprises and even more defense can spend all the money not just for software but even for consulting from various company that can bring the skills to implement and maintain all the services that are needed, and train your people at that. Things become non trivial not on the base of technical issue, but on the base of organizational issues...
If we talk government and defense... Do you know the US government has dedicated cloud regions (eg: https://aws.amazon.com/govcloud-us/)? Do you really think that cloud providers offer those services at loss? Do you really think a few vault enterprise licenses are the issue there?
And by the way, Vault is just an example of one of the possible solutions. It was meant to be an example but you clearly missed the point.
> > Hence, if a large organization is not able to implement that, the issue is in the organization, not in the technology.
> Absolutely meaningless statement.
I think it's very meaningful.
It's not 1995, cryptography isn't arcane anymore. We had hardware crypto acceleration in cpu since at least 2010 (AES-NI). The tooling is well established on both servers and clients. The skills are on the market ready to be hired (either via employment or via contracting).
The issue is not technical in nature.
Oh and by the way: I've worked closely with engineers working for the US government. I wasn't close to the US government (because I am not an US citizen) but they were. They were "close enough" that they had to work in a SCIF and could only interact with me via phone. The systems they were working on... Those systems had their own private CA (among other things).
It's feasible. It's not a technical issue. If it's not done then it's an organizational issue.
My username is literally a cryptographic mode of operation. But you didn't know that, because you have a low skill issue.
> Do you know the US government has dedicated cloud regions (eg:
This is a joke, right? You're just an LLM going through training.
Again, ad hominem attack... You proved yourself to be quite a fool. You can't argue, you can't back your own opinions, you are only capable of attacking on a personal level.
> This is a joke, right? You're just an LLM going through training.
My account is from 2015 and has ~11k points. Your account is 4 months old and barely has 150 points. It's more likely that you're a poorly trained LLM (whoever trained you had skill issues :P) rather than me.
I'll be dropping this useless conversation. Farewell.
That's not what ad hominem means. Ad hominem doesn't mean I can't insult you
> My account is from 2015 and has ~11k points. Your account is 4 months old and barely has 150 points. It's more likely that you're a poorly trained LLM (whoever trained you had skill issues :P) rather than me.
Content matters more than age you goofball
How do you do this on a proprietary device from the late 90s that runs a WindRiver VXWorks RTOS with 1 MB of SRAM? The updated (full color!) Panelview HMI is running Windows CE 6.0, so it's perhaps more likely to be compatible, but I don't think the same group policies exist on that platform.
The masses can do it in an afternoon because they can choose to only install modern equipment that's compatible with the new requirements. Some of the "heavy iron" castings for the machines we have to work with were built more than a century ago, and only later automated with tubes and relays, and then again with the first PLCs that could do the job. But now "SSL everywhere" policies and certificate expiration timelines that don't make a distinction between firewalled OT networks and Internet-facing webservers don't allow anything to run for a decade without major, risky rewrites that cost tens of thousands of dollars for highly specialized engineering services and minimal downtime. Sure, adding a cert to the SCADA server is trivial, it runs Windows Server and has a NIC that can access the Internet, but on the other NIC...there's a menagerie of 30 years of industrial oddities.
If your homelab is still working after 2 years, that's great, but if it's not running after 100 years would you call that an organizational failure?
I've automated certificate upgrades on everything from dodgy network appliances to IBM System i servers.
I've used everything from headless browsers to scripted 5250 terminal emulators. Generally, if you have the will, you can automate anything that you do manually. The solutions are often janky, but they can usually be verified easily by other tools (curl output can be parsed to verify cert details).
You weight the cost of incurring in that thing getting hacked against the cost of that thing being rebuilt on modern hardware with modern technologies and enough processing power to do TLS.
Then you pick the "rebuild route". Easy.
Anyway, it's crazy how on this forum it goes from "REWRITE EVERYTHING IN RUST!!! ANYTHING THAT'S NOT RUST IS INHERENTLY UNSAFE" to the complete opposite of "why doesn't anybody think of the poor WindRiver VXWorks RTOS!!".
> Sure, adding a cert to the SCADA server is trivial, it runs Windows Server and has a NIC that can access the Internet, but on the other NIC...there's a menagerie of 30 years of industrial oddities.
Not gonna lie, all i hear is "i'm annoyed i was able to ignore the problem for 30 years but now i have to actually fix it".
> Not gonna lie, all i hear is "i'm annoyed i was able to ignore the problem for 30 years but now i have to actually fix it".
You're not entirely wrong, but you're talking to the wrong guy. Clean-slate rewrites are some of my favorite best projects, and I hate dealing with legacy junk - but there's just not budget to keep everything brand new all the time.
Realize that when you flush the toilet, the reason the water level goes down is likely to be a municipal sewer system and waste treatment plant that must never stop...they replace mechanical wear items once in a while, but some of the controls are well over 30 years old. Same story at the clean water plant that fills the tank back up. An average consumer might replace their phone every 2 years, but industrial processes and infrastructure have much, much longer timelines.
Hey, I get it.
The thing is, budget is largely artificial. Unless a company is on the brink of bankruptcy, there can be budget (but the company has to eat that from profits).
The thing is, eating budget for maintenance and system upgrades is a known playbook companies use. That doesn't make it right though.
That is why i wrote that the issue is organizational, not technical...
You dont and you are not supposed to bend security posture backwards to accomodate insecure devices that should be in the landfill by now
It’s generally best to assume experts in other fields are doing things for good reasons, and if you don’t understand the reason it might be something other than them being dumb.
When I argued here that Linux is still pain to maintain on my laptops, it wasn’t because it’s not possible. I just didn’t have enough willpower.
People who jumped on me because of this were still idiots, because they thought that their even less knowledge (what were the error messages, my exact setup, etc) can be helpful for me, but still it would be wrong to state that I was unsuccessful because it’s not possible, or I had full knowledge back then.
Especially now, that I’m running Linux full time.
For example, I’m quite sure that you can solve this problem with a proxy, no matter what’s behind it. Maybe it’s infeasible, because you would need a custom proxy implementation, but it’s definitely possible.
That doesn't guarantee they don't have malicious intents, but it's different from a for-profit company that tries to make money with you.
What I think LE did was to gather the required bag of money that any cert issuer needs to pony up to get the infra up and validated, and then skipped the $5 part and just run on donations. So while LE might stop tomorrow, you don't have any good guarantees that the $5 cert company will last longer if their sidebusiness goes under, and if you go to a $100 cert company, you are just getting scammed from some company who soon will realize that most certs are being given away and that they can't prove why their $100 certs are "better" in any meaningful way so they will also be at risk of going under. In all these cases, you get to use your cert for whatever validity period you had, and then rush over to the next issuer, whoever that is left when the pay-for-certs business tanks.
As opposed to cars or whatever, you can't really put more "quality math" into the certs so they last longer, the CAs have limits on how long they are allowed to last, so no more 10-year certs for public services anyhow. You might aswell get the cheapest of the ones that are still valid and useful (ie, exists in browser CA lists) and LE is one of those. Might be more (zerossl?) but same argument would hold for those. The CA list is curated by the browser teams lots better than me or you shopping around websites that make weird claims on why their certs are worth paying $100 for.
- Many companies (including competitors) are sponsoring LE, so the funding should be quite robust
- These companies are probably winning from the web being more secure, so the incentives are aligned with you (contrary to say, a company that offers something free but want to sink you under ads)
- the vendor lock-in is very weak. The day LE goes awry, you can move to another CA pretty painlessly
There are CAs supporting ACME that provide paid services as well.
I run a couple of low-stakes websites just for fun and manually updating certificates takes me about 10 minutes a year, and most of that is remembering how to generate the csr. Setting up an automated process gains me nothing except additional points of failure. Ratcheting the expiration down to 47 days is an effort to force everyone to use automation, which makes no sense for small hobby sites.
> I'm not sure why many people are still dealing with legacy manual certificate renewal
Not everyone is a professional sysadmin. Adding automation is another layer of complexity on top of what it already takes to run a website. It's fine for large orgs and professionals who do this for a living at their day jobs, but for someone just getting their feet wet it's a ridiculous ask.
you make it sound like setting up automated renewals is an onerous process. IME it takes about the same amount of time to set up the automation according to the directions as it does to manually renew the certs with an ACME client. the only difference is you're pasting a command into a crontab/timer instead of directly into your shell to execute.
The problem isn't that it's hard to set up. It's that it adds another thing that I have to monitor for failures and troubleshoot when it breaks. For a small hobby site, I might go longer than 47 days without looking at it.
ymmv. for me, i'll fix it if i have to, but i haven't yet :)
Forcing everyone to use automation sounds like a great idea. I am sure it is by design.
I’d say the easiest way out is to use the Caddy web server, which can take care of the certs all by itself.
You don't need to be a professional sysadmin to deal with this - so long as the software you use isn't ass. Nginx will _finally_ get this ability in the next release (and it'll still be more configuration than caddy, that just defaults to the sane thing)...
I wonder what they will do with the shorter validity periods. They aren't required to comply in the same way; it's not a great look not to but I can't believe the processes will scale (for them or their customers) to renewing an order of magnitude more frequently.
- Rotation of all certificates and authentication material must be renewed at regular intervals (no conflict here, this is the goal)
- All infrastructure changes need to have the commands executed and contents of files inspected and approved in writing by the change control board before being applied to the environment
That explicit approval of any changes being made within the environment go against these being automated in any way shape or form. These boards usually meet monthly or ad-hoc for time-sensitive security updates and usually have very long lists of changes to review causing the agenda to constantly overflow to the next meeting.
You could probably still make it work as a priority standing agenda idea but its going to still involve manual process and review every month. I wouldn't want to manually rotate and approve certificates every month and many of these requirements have been signed into law (at least in the US).
Starting to see another round of modernization initiatives so maybe in the next few years something could be done...
Clearly not all automated infrastructure requires approval: autoscaling groups spin up and tear down compute instances all the time. Further, changes to data can't universally require approval, otherwise every CRUD operation would require a committee meeting.
Are certificates truly explicitly defined to be infrastructure that requires change approval? If not, perhaps more careful interpretation of the regulations could allow for improved automation and security outcomes.
In these sort of environments, they do not.
We're talking about environments where it is forbidden to make _any_ change of any kind without a CCB ticket. Short cert lifetimes are fundamentally at odds with this. Luckily these systems often aren't public and don't need public certs, but there's a slice of them that do.
Each change needs a documented approval trail. While you can get pre-approval for automated rotations as a class of changes, many auditors interpret the controls conservatively and want to see individual change tickets for each cert rotation, even routine ones.
In some regulated places, someone is legally responsible for authorizing a change in production.
If it fails, that person's on the hook. So the usual way is to have a manual authorization for every change. Yes, it's a PITA.
One place I've worked changed their process to automatically allow changes in some specific parts for a specific period during the development of a new app.
And for some magical reasons, the person usually associated with such legal responsibility are the one that don't trust automatic process.
Weird internal setups, dozens of proprietary or in-house sites, different verification needs for internal vs. external.
And I'm speaking of the easier scenario of an internal CA.
I currently for EIDAS certificates, I can only choose a vouched certificate provider, and it's mostly somes that requires me to in person with my ID card with someone verifying the guy who made the CSR is actually me.
The certificate is used for double SSL to authentify the server doing the request , i.e that the server doing an API call to the bank server is one I own. (I find it a pretty neat solution and much better than requiring to make a theater dance to get a token to renew every 3600 seconds )
So I’m really not excited about the time limit dropping from 90 days to 47 days.
And yes, there are alternatives, but everything is made so that LetsEncrypt is the only reasonable choice.
First, if you are not using https, you get shunned by every major web browser, you don't get the latest features, even those that has nothing to do with encryption (ex: brotli compression), downloads get blocked, etc... So you need https, good thing LetsEncrypt make it so easy, so you use LetsEncrypt.
Because of the way LetsEncrypt verification works, you get short-term certificates, ok, fine. Other CAs do things differently, making it short-term certificates impractical, so your certificates last longer. But now, browsers are changing their requirements to only short-term certificate, but it is not a problem, just switch to LetsEncrypt, and it is free too.
Also, X.509 certificates, which is the basis of https (incl. TLS, HTTP/3, ...) only supports a single signature, so I guess it is LetsEncrypt and nothing else.
I understand that people get annoyed at shorter cert lifetime, for instance if you are managing appliances or use SSL certs for other reasons than the common use case. But if you just want to serve a website, there are not so many reasons not to use HTTPS today, either on Let's Encrypt or on something else.
Maybe there are problems with that, but I never really understood the limit of a single signature for certificates. Is it because of bandwidth and performance requirements? Is it really a problem nowadays? especially with ECDSA making public keys much smaller.
Then anybody can maintain a database of "known fingerprints", and a web-of-trust can be established without depending on a centeral-point-of-censorship.
Fuck CA's. They're not and never have been trustworthy:
https://en.wikipedia.org/wiki/DigiNotar
https://en.wikipedia.org/wiki/Xcitium#Certificate_hacking
https://arstechnica.com/security/2025/06/chrome-boots-2-cert...
https://www.zdnet.com/article/google-guillotine-falls-on-cer...
Just wait until SSL is used to prevent us from publishing anything.
Your ID will have to be on file and be compliant.
We've gone from really simple tools to tools that could easily be used to ensnare us and rid us of our rights.
Encryption doesn't necessarily mean privacy. It can also mean control.
yeah encryption is needed. but then you need authentication. and then, if authentication is controlled by corporations you're f'd.
instead youd want identities to be distributed and owned by everyone. many trust models have been developed and other than raw UI problems (hi gpg/pgp) its really not a terrible UX.
If you're talking about Android, it doesn't require you to use WebPKI CAs. You can go self-signed.
If it's about the search engine, well, that's gone to shit and you'll only be visible if Google likes you in a completely arbitrary way - no point trying to add HTTPS to show up in search results now unless you already do.
All of these things we take for granted can change. You're watching it happen right now.
The cert situation has vastly improved over the past 30 years. I remember paying $100's of dollars for certificates in the 90's, faxing in forms, etc.
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.
Why wouldn't you go with a week or a day? isn't that better than a whole month?
Why isn't it instead just a minute? or a few seconds? Wouldn't that be better?
Why not have certificates dynamically generated constantly and have it so every single request is serviced by a new one and then destroyed after the session is over?
Maybe the problem isn't that certificates expire too soon, maybe the problem is that humans are lazy. Perhaps it's time to go with another method entirely.
a whole month put you in the "if you don't have the resource to automate it, it's still doable by a human, not enough to crush somebody, but still enough to make the option , let's automate fully something to consider"
hence why it's better than a week or a day (it's too much pressure for small companies) better than hours/minutes/secondes (it means you go from 1 year to 'now it must be fully automated right now ! )
a year or two years was not a good idea, because you loose knowledge, it creates pressure (oh my.... not the scary yearly certificate renewal, i remember last year we broke something, we i don't remember what...)
A month, you either start to fully document it, or at least to have it fresh in your mind. A month give you time to everytime think "ok, we have 30 certicates, can't we have a wild card, or a certificate with several domain in it?"
> Perhaps it's time to go with another method entirely.
I think that's the way forward, it's just that it will not happen in one step, and going to one month is a first step.
source: We have to manage a lot of certificate for a lot of different use cases (ssh, mutual ssl for authentification, classical HTTPS certificate etc. ) and we learned the hard way that no 2 years is not better than 1 , and I agree that one month would be better
also https://www.digicert.com/blog/tls-certificate-lifetimes-will...
(Why not less than six days? Because I think at that point you might start to face some availability tradeoffs even if everything is always fully automated.)
Ah yes, let's make a terrible workflow to externally force companies who can't be arsed to document their processes to do things properly, at the expense of everyone else.
Monthly expiration is a simple way to force you to automate something. Everyone benefits from automating it, too.
He said six figures for the price would be fine. This is an instance where business needs and technology have gotten really out of alignment.
It'll take about fifteen minutes of time, and executive level won't ever have to concern themselves with something as mundane as TLS certificates again.
Most solutions: make the peons watch a training video or attend a training session about how they should speak up more.
I completely agree with you but you would be astonished by how many companies, even small/medium companies that uses recent technologies and are otherwise pretty lean, still think that restarting/redeploying/renewing as less as possible is the best way to go instead of fixing the root issue that makes restarting/redeploying/renewing a pain in the ass.
And not even at the "math" level. I mean, like, how to get them into a Java keystore. Or how to get Apache or nginx to use them. That you need to include the intermediate certificate. How to get multiple SANs instead of a wildcard certificate. How to use certbot (with HTTP requests or DNS verification). How to get your client to trust a custom CA. How to troubleshoot what's wrong from a client.
I think the most rational takeaway is just that it's too difficult for a typical IT guy to understand, and most SMBs that aren't in tech don't have anyone more knowledgeable on staff.
Where would that kind of thinking lead us..? Most medical procedures are too complex for someone untrained to understand. Does that mean clinics should just not offer those procedures anymore, or should they rather make sure to train their physicians appropriately so they’re able to… do their job properly?
Even if your server admins fully understand TLS, there are still issues like clock skew on clients breaking things, old cipher suites needing to be reviewed / sunset, users clicking past certificate warnings despite training, and the list of (sometimes questionable) globally trusted CAs that the security of the Internet depends upon.
Of course they should do their job properly, but I'm skeptical that we (as software developers) can't come up with something that can more reliably work well.
I actually watched for crashes (thank you inventory control department shenanigans) so that I can sneak in changes during a reset.
I mean… There's a tradeoff to be sure. I also have a list of things that could be solved properly, but can't justify the time expense to doing so compared to repeating the shortcut every so often.
It's like that expensive espresso machine I've been drooling over for years—I can go out and grab a lot of great coffee at a barista shop before the machine would have saved me money.
But in this particular instance, sure; once you factor the operational risk in, proper automation often is a no-brainer.
Business culture devaluing security is the root of this and I hope people see the above example of everything that's wrong with how some technology companies operate, and "just throw money at the problem because security in an annoying cost center" is super bad leadership. I'm going to guess this guy also have an MFA exception on his account and a 7 character password because "it just works! It just makes sense, nerds!" I've worked with these kinds of execs all my career and they are absolutely the problem here.
Then if your CA went down for an hour, you would go down too. With 47 days, there's plenty of time for the CA to fix the outage and issue you a new cert before your current one expires.
Using LetsEncrypt and ZeroSSL together is a popular approach. If you need a stronger guarantee of uptime, reach for the paid options.
https://github.com/acmesh-official/acme.sh?tab=readme-ov-fil...
>If you need a stronger guarantee of uptime, reach for the paid options.
We don't. If we had 1 minute or 1 second lifetimes, we would.
A short cycle ensures either automation or keeping memory fresh.
Automation of course can also be forgotten and break, but it's at least somewhere written down in some form (code) rather than personal memory of a long gone employee who previously uploaded certs to some CA website for signing manually etc
Imagine you run an old-school media company who's come into possession of a beloved website with decades of user-generated and reporter-generated content. Content that puts the "this is someone's legacy" in "legacy content." You get some incremental ad revenue, and you're like "if all I have to do is have my outsourced IT team do this renewal thing once a year, it's free money I guess."
But now, you have to pay that team to do a human-in-the-loop task monthly for every site you operate, which now makes the cost no longer de minimis? Or, fully modernize your systems? But since that legacy site uses a different stack, they're saying it's an entirely separate project, which they'll happily quote you with far more zeroes than your ads are generating?
All of a sudden, something that was infrequent maintenance becomes a measurable job. Even a fully rational executive sees their incentives switch - and that doesn't count the ones who were waiting for an excuse to kill their predecessors' projects. We start seeing more and more sites go offline.
We should endeavor not to break the internet. That's not "don't break the internet, conditional on fully rational actors who magically don't have legacy systems." It's "don't break the internet."
And, if you haven't been using a reverse proxy before, or for business/risk reasons don't want to use your main site's infrastructure to proxy the inherited site, and had been handling certificates in your host's cPanel with something like https://www.wpzoom.com/blog/add-ssl-to-wordpress/ - it is indeed a dedicated project to install a reverse proxy!
> Perhaps it's time to go with another method entirely.
What method would you suggest here?
Could it work that your long-term certificate (90 days, whatever) gives you the ability to sign ephemeral certificates (much like, e.g. LetsEncrypt signs your 90 day certificate)? That saves calling out to a central authority for each request.
a month is better than a year because we never ever ever managed to make revocation work, and so the only thing we can do is reduce the length of certs so that stolen or fraudulently obtained certs can be used for less time.
https://www.darkreading.com/endpoint-security/china-based-bi...
I'm sure that you are perfectly able to do your own research, why are you trying to push that work onto some stranger on the internet?
I also wonder how many organizations have had certificates mis-issued due to BGP hijacking. Yes, this will improve the warm fuzzy security feeling we all want at night, but how much actual risk is this requirement mitigating?
Now they are doing next plausible solution. Seems like 47 days is something they found out by let’s encrypt experience estimating load by current renewals but that last part I am just imagining.
But CRL sizes are also partly controlled by expiry time, shorter lifetimes produce smaller CRLs.
There is in fact work on making this an option: https://letsencrypt.org/2025/02/20/first-short-lived-cert-is...
> Why isn't it instead just a minute? or a few seconds? Wouldn't that be better?
> Why not have certificates dynamically generated constantly and have it so every single request is serviced by a new one and then destroyed after the session is over?
Eventually the overhead actually does start to matter
> Maybe the problem isn't that certificates expire too soon, maybe the problem is that humans are lazy. Perhaps it's time to go with another method entirely.
Like what?
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.
New phone and suddenly I can't install it from Google Play anymore simply because the developer hasn't updated it in awhile. Not that it needs to be updated. I've since repurchased it from itch.io and it runs fine, but that's not unusual for lots of good old software.
Forcing developers to stay engages pushes out feature complete software but also pushes out unmaintained software.
An app store is an inherently higher cost distribution method. The operating systems are gratis so development is cross subsidized from app store royalties. They have an incentive to host more paid apps, especially micro-transaction apps that trick kids into spending thousands of dollars off mom's credit card. Of course they've banned or are going to ban alternative channels so you can't choose to self-distribute.
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.
[0]: https://hacks.mozilla.org/2025/08/crlite-fast-private-and-co...
It's really annoying because I have to carve outs for browsers and other software that refuse to connect to things with unverifiable certs and adding my CA to some software or devices is a either a pain or impossible.
It's created a hodge podge of systems and policies and made our security posture full of holes. Back when we just did a fully delegated digicert wildcard (big expense) on a 3 or 5 year expiration, it was easy to manage. Now, I've got execs in other depts asking about crazy long expirations because of the hassle.
Plenty of people leave these devices without encrypted connections, because they are in a "secure network", but you should never rely on such a thing.
We used to use Firefox solely for internal problem devices with IP and subnet exclusions but even that is becoming difficult.
It's not different from IPSec, GRE, VXLAN, etc. It's just the new hotness.
We use VXLAN extensively in our network, btw, and IKEv2/IPSec tunnels between sites.
Just because it can be used to recreate VPNs traditionally used to remotely dial into a secure network zone doesn't mean it shouldn't be used in far smaller use-cases. WireGuard doesn't constitute anything like a full VPN solution on its own.
Pick your poison.
Why not encode that TXT record value into the CA-signed certificate metadata? And then at runtime, when a browser requests the page, the browser can verify the TXT record as well, and cache that result for an hour or whatever you like?
Or another set of TXT records for revocation, TXT _acme-challenge-revoked.<YOUR_DOMAIN> etc?
It's not perfect, DNS is not at all secure / relatively easy to spoof for a single client on your LAN, I know that. But realistically, if someone has control of your DNS, they can just issue themselves a legit certificate anyway.
Also, I don't see how that last paragraph follows; is your argument just that client-side DNS poisoning is an attack not worth defending against?
Also, there's maybe not much value in solving this for DNS-01 if you don't also solve it for the other, more commonly used challenge types.
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.
There are environments and devices where automation is not possible: not everything that needs a cert is a Linux server, or a system where you can run your own code. (I initially got ACME/LE working on a previous job's F5s because it was RH underneath and so could get Dehydrate working (only needs bash, cURL, OpenSSL); not all appliances even allow that).
I'm afraid that with the 47-day mandate we'll see the return of self-signed certs, and folks will be trained to "just accept it the first time".
You linked to a whole thread in which the top comment asks a question that's a slippery slope, and of which the top answer lists advantages of a reduced validity time (while pointing out that too short like 30 seconds poses reliability and scale risks, to address the slippery slope argument).
What did you mean to point out?
For new certificate you can keep the existing amount of human oversight in place so nothing changes on that front.
With manual renewals, the cert either wouldn't get renewed and would become naturally invalid or the notification that the cert expired would prompt someone to finish the cleanup.
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.
https://cabforum.org/working-groups/server/baseline-requirem...
You can also just search the document for the word "Perspective" to find most references to it.
"Effective December 15, 2026, the CA MUST implement Multi-Perspective Issuance Corroboration using at least five (5) remote Network Perspectives. The CA MUST ensure that [...] the remote Network Perspectives that corroborate the Primary Network Perspective fall within the service regions of at least two (2) distinct Regional Internet Registries."
"Network Perspectives are considered distinct when the straight-line distance between them is at least 500 km."
I.e they check from multiple network locations in case an attacker has messed with network routing in some way. This is reasonable and imposes no extra load on the domain needing the certificate all the extra work falls on the CA, and if Letsencrypt can get this right there is no major reason why "Joe's garage certs" can't do the same thing.
This is outrage porn.
Also, there are loads of other requirements except this one and they are there for good reasons. It’s not easy to get your root certificate accepted by Firefox/Google/Microsoft/Apple and it shouldn’t be.
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
> 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!
The hand-waving away of certbot/ACME at the very end of the article only really goes to show that it hasn't been looked in to properly for whatever reason.
I inherited a process using the same thing last year and it is the absolutely most insane nonsense I can think of. These types of companies have support that is totally useless and their entire business model is to charge 1000x or more (eg. compare signature price to a HSM in GCP) what competitors charge while also providing less functionality, and hoping that people will get sucked in and trapped in their ecosystem by purchasing an expensive cert such as an "EV" cert which I'm still not totally clear does by the way, but I'm assured it's very important for security on Windows. Not security against bad guys though... it appears to be for security against no-name anti virus vendors deleting your files if they detect you didn't pay this "EV" cert ransom. They don't need to actually detect threats based on code or behavior, they just detect if you have enough money.
Then you only have to follow the stricter rules for only the public facing certs.
https://github.com/linsomniac/lessencrypt
I've toyed with the idea of adding the ability for the server component to request certs from LetsEncrypt via DNS validation. Acting as a clearing house so that individual internal hosts don't need a DNS secret to get certs. However, we also put IP addresses and localhost on our internal certs, so we'd ahve to stop doing that to be able to get them from LetsEncrypt.
(You say hijacking the HTTP port, but I don't let the ACME client take over 80/443, I make my reverse proxy point the expected path to a folder the ACME client writes to, I'm not asking for a comparison with a setup where the acme client takes over the reverse proxy and edits its configuration by itself, which I don't like)
Active Directory Certificate Services is a fickle beast but it's about to get a lot more popular again.
But certs and every other context have become neigh impossible except in enterprise settings with your own CA and cert servers. From things like printers and network appliances to entirely non-http applications like VPN (StrongSwan and OpenVPN both have/support TLS with signed SSL certs, but place very different constraints on how those work in practice and what identities are supported, how or if wildcards work, etc).
Very little attention has been paid to non-general purpose and non-http contexts as things currently stand.
Also, I know firsthand that the DNS Validator also works perfectly fine, no http check required
From advertising companies, search engines (ok, sometimes both), certificate peddlers and other 'service' (I use the term lightly here) providers there are just too many of these maggots that we don't actually need. We mostly need them to manage the maggots! If they would all fuck off the web would instantly be a better place.
Desktop app development gets increasingly hostile and OSes introduce more and more TCC modals, you pretty much need a certificate to codesign an app if you sideload (and app stores have a lot of hassle involved), mobile clients had it bad for a while (and just announced that Android will require a dev certificate for sideloading as well).
edit: also another comment is correct, the reason it is like that is because it has the most eyes on it. In the past it was on desktop apps, which made them worse
But it seems apparent to me that it will have to work over HTTP/QUIC, and TCP port 443.
Which prompts the obvious question ...
The question I was alluding to is: if it's HTTP-ish over tcp/443, wouldn't it still be the web anyway?
But thinking about it more, the server could easily select a protocol based on the first chunk of the client request. And the example of RTP suggests that maybe even TCP would be optional.
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.
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.
The remaining domain control validation (DCV) methods for my organization have been reduced to two options: DNS TXT records and email-based validation.
DNS validation is a decent and secure option in an organization where DNS management access is tightly controlled.
A recent change aims to thwart BGP hijacking and DNS spoofing attacks.
Indeed, there are CA consulting services that will offer to "bring PKI and DNS together to validate domain ownership and issue certificates without manual DNS record updates"."
This CA-based, i.e., third-party-based, "Web PKI" appears to depend heavily on the ICANN DNS. But in ICANN DNS the authoritative nameservers are not required to accept encrypted queries or send encrypted responses
In this ICANN DNS upon which "Web PKI" depends, specifically the system of authoritative nameservers, there is no encryption, only authentication, and it is not mandatory for all nameservers. Even more, the setup and maintenance of this authentication system for the data^1 served by these nameservers (DNSSEC) is as difficult if not more than the CA-issued certificates system for networked computers that the blog post is complaining about^2
1. Nevermind the authentication of the computers serving the zone data
> I am responsible for approving SSL certificates for my company. [...] I review and approve each cert. What started out as a quarterly or semi-monthly task has become a monthly-to-weekly task depending on when our certs are expiring.
I don't get the security need for manually approving renewals, and the author makes no attempt to justify this either. It may make sense for some manual process to be in place for initial issuances, as certificates are permanently added to a publicly-available ledger. And to take a step back, do you need public certs to begin with? Can you not have an internal CA? Again, the author makes no attempt to justify this, or demonstrate understanding in the post.
> email-based validation may as well not exist when we need to update a certificate for test.lab.corp.example.com because there is no webmaster@test.lab.corp.example.com.
I know that this is an example, but as a developer it would be a pain to have to go through a manual, multi-day process for my `test.lab.corp.example.com` to work. And the rest of the post seems to imply that this is actually the case at OP's org.
> Which resource-starved team will manage the client and the infrastructure it needs? It will need time to undergo code review and/or supplier review if it’s sold by a company. There will be a requirement for secrets management. There will be a need for monitoring and alerting. It’s not as painless as the certificate approval workflow I have now.
There are additional costs and new processes to be made, yes, but even from a non-technical POV this appears to be a good time to lead and take ownership.
> Any platforms that offer or include certificate management bundled with the actual services we pay for will win our business by default. [...] What is obvious to me is that my stakeholders and I are hurrying to offload certificate management to our vendors and platforms and not to our CA.
That's okay. If you hate change and don't want to take ownership, pay someone else to take ownership.
My journey personally was with my previous company and we had the challenge of 1-n domains pointing at 1-n sub domains so a simple solution like certbot just didn’t work for us sadly. Not only that but my bosses were doing it manually and still paying for the certs which was consuming time and money. So over the course of a few months I wrote a solution to that problem to easily issue, manage, and renew 1-n certs for 1-n vanity domains. Was a good bit of work but for the last 2 years it’s been flawless and turned into a upsell and a money maker from a losing situation previously.
This is funny timing because we actually just put VanityCert on product hunt if you’re interested in checking out what I build. Would love your thoughts!
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.
Probably because making sure that clients trust the right set of non-public CAs is currently too much of a pain in the ass. Possibly an underrated investment in the security of the internet would be inventing better solutions to make this process easier, the way Certbot made certificate renewal easier (though it'd be a harder problem as the environment is more heterogeneous). This might reduce the extent of conservative stakeholders crankily demanding that the public CA infrastructure accommodate their non-public-facing embedded systems that can't keep up with the constantly evolving security requirements that are part and parcel of existing on the public internet.
I don't see a reason why that should be a problem to solve for public CAs and rest of the internet? Complaining about multi-perspective validation or lifetime is silly if the hindrance is someone's own business needs and requirements.
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
FWIW the idea of inspecting the certificate "for typos" or similar doesn't make sense. What you're getting from the CA wasn't really the certificate but the act of signing it, which they've already done. Except in some very niche situations your certificate is always already publicly available when you receive it, what you've got back is in some sense a courtesy copy. So it's too late to "approve" this document or not, the thing worth approving already happened.
Also the issuing CA was required by the rules to have done a whole bunch of automated checks far beyond what a human would reasonably do by hand. They're going to have checked your public keys don't have any of a set of undesirable mathematical properties (especially for RSA keys) for example and don't match various "known bad" keys. Can you do better? With good tooling yeah, by hand, not a chance.
But then beyond this, modern "SSL certificates" are just really boring. They're 10% boilerplate 90% random numbers. It's like tasking a child with keeping a tally of what colour cars they saw. "Another red one? Wow".
The CA is going to look at the requested names (to check they were authorized) and they'll also copy the requested public key, this combination is what's certified. But if your antiquated gear spits out a CSR which also gives a (possibly bogus) company name and an (maybe invalid) street address "checking" that won't matter because the CA will just throw it away, the certificate they issue you isn't allowed to contain information they didn't check, so that part of your CSR is just tossed away without reading it.
So even reviewing CSRs won't help you.
(The solution of course is to automate your cert request/issuance, which has the side effect of ensuring no human is involved in the cert process)
Yes, it's insane, but it sure makes fault analysis easier when the environment is that locked down and documented.
Side note, at some point I got an email telling me to stop issuing public certificates and only issue private certs. I had to get on a call with someone and explain PKI. To someone on the security team!
There are many solutions (reverse proxies, private CAs, literally hiring a guy to manually update certs on each bit of equipment every 35 days), some of them are painful, but it's not worth handicapping the security of the entire public web for them.
Vs. shoving httpS proxy services in front of insecure backends is often easy.
Usually fronting a service with Traefik or NGINX fits all the business needs.
I do recall a setup in Kubernetes where nearly all traffic had to be encrypted, even within the cluster. The boundary was the pod. Within a pod you are guaranteed that all containers run on the same node. And since a node is a physical boundary (it's either a physical machine or a vm on a physical machine) you're guaranteed that that traffic never goes over a network cable.
The solution then is to deploy something like LinkerD which ensures that traffic between pods is encrypted transparently. We could've eased the policy that traffic between pods on the same node shouldn't be encrypted, but then we introduced more variables in the process, and it wasn't worth it.
You will either obey the rules of the product (as dictated by mostly-Google), or you will stop using the product. It's no different in kind from either obeying the new Play Store policies or getting removed from the Play Store. It's no different in kind from either obeying the new Twitter terms or getting banned from Twitter. These are applications, centrally controlled platforms, not ecosystems.
If the Web decides that you need to meet some requirement but your corporate process is set up in a way that makes it onerous to meet, then you either change your corporate process or you get off the Web.
At least it still doesn't cost actual money or ID documents to be on the Web, like it does on the Play Store. I'm not very sympathetic to corporations who put roadblocks in front of themselves and then play the victim. The Web has demanded that you must have a streamlined fully automated process for certificate issuance and deployment, but, key point, this isn't an unreasonable requirement.
It's justified to keep a close eye on the rollout of new Web requirements, because unreasonable ones are surely not far behind. Google has just announced that in the next version of Android you won't be able to sideload apps that Google hasn't approved. It'd be folly to assume they aren't trying to impose something similar on the Web as well. But this isn't that, and can't become that.
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 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.)
It might be harder to host at home, but only for network reasons. It is perfectly straightforward to use letsencrypt and your choice of acme client to do certificates; I really don't think that's meaningful point of friction even with the shorter certificate lifetimes.
And it's not like the automation is hard (when I first did letsencrypt certs I did a misguidedly-paranoid offline key thing - for my second attempt, the only reason I had to do any work at all, instead of letting the prepackaged automation work, was to support a messy podman setup, and even that ended up mostly being "systemd is more work than crontab")
Azure had an "individual developer" beta that lasted less than a year and is now closed... so you have to be able to prove your "business" has been around for three years. they're one of the very few low-cost options who support cloud signing... $10/month or $120/year is VERY reasonable compared to $300/year the other registrars want, PLUS the cost of an HSM you can't use from the cloud.
how are people doing signed binaries on Windows for open source projects? I bought a three year file-based certificate to kick the can down the road but those three years are now up.
For example why not allow an organization to have its own self-signed certificate authority, and allow it to publish its self-signed root certificate through DNS, and make browsers accept that root for use with that domain?
I see two objections offhand.
Objection #1. It doesn't provide any validation that the certificates were actually made by the legal entity that they claim to be for. It just shows that whoever made the CA had write access to the domain's DNS records. It can't replace EV certificates or OV certificates.
Retort #1. So? Those sites that need EV of OV certificates can keep using the current approach. But a very large number of sites don't need EV or OV certificates. This can be seen by the success of Let's Encrypt which only issues DV certificates. Even some large sites use DV certificates, such as Amazon.
Objection #2. If someone gets write access to your DNS records they can replace your CA!
Retort #2. So? If someone gets write access to your DNS records they can make Let's Encrypt certificates for your domain.
What have I overlooked?
If you want to get more specific about using DNS as an alternate root of trust, there are bigger problems. The X.509 WebPKI has mandatory certificate transparency, so misissuance can be detected. Just as importantly, and relatedly, the browser developers can kill a CA that misissues. They've done so multiple times, and have killed one of the largest CAs over misissuance incidents.
Neither capability exists for a DNS-based PKI, which is deeply problematic given that the DNS PKI is --- de jure --- run by state actors.
Is this because DNS traffic often is not encrypted, so middleboxes can see and meddle with DNS traffic?
You overlooked the need for DNSSEC, so another PKI with his own quirks, and somehow less reliable than CAs.
Additionally, Google and the PSL have inadvertently broken .home.arpa on Chrome by misclassifying it as a public suffix, while leaving .internal alone. A wildcard cert for *.home.arpa will not work on Chrome, but *.internal will, despite these two domains being essentially equivalent in purpose.
You should be. From what I can remember, both Firefox and Chrome add exceptions to user installed certificates that disable requirements such as certificate transparency logs and even things like HPKP back when that was a thing.
It's easy to make a mistake and install certificates in the system chain instead (especially on Windows), but if you pick the right certificate store I don't think you should be having any trouble. That said, it's been a while since I last dealt with Chrome, maybe things have gotten worse.
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.
What typically does work for this kind of thing, is finding a hook to artificially rather than technically necessitate it, while not breaking legacy.
For example, while I hate the monopoly that Google has on search, it was incredibly effective when they down-ranked HTTP sites in favour of HTTPs sites.
( In 2014: See https://developers.google.com/search/blog/2014/08/https-as-r... )
Almost overnight, organisations that never gave a shit, suddenly found themselves rushing through the any required tech debt to get SSL certs and HTTPs in place.
It was only after that drove up HTTPs to a critical mass did Google have the confidence to further nudge through bigger warnings in Chrome. ( 2018 ).
Perhaps ChatGPT and has impacted Google's monopoly too much to try again, but they could easily rank results based on certificate validity length and try the same trick again.
The solution is just like with any other automation - document it.
Even your unrelated question is another argument for shortened certificate lifetimes. :-)
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".)
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.
???
All my servers use certbot and it works fine. There's also no shortage of SaaS/PaaS that offer free ssl with their service, and presumably they've got that automated as well.
It may help you to understand that it is not an assumption any given product even supports HTTPS well in the first place, and a lot of vendors look at you weird when you express that you intend to enable it. One piece of software requires rerunning the installer to change the certificate.
Yeah, there are also some very expensive vendors out there to manage this for big companies with big dollars.
Plus, how would you ever get enterprise tool vendors to add support if not for customers pestering them with support requests because manual certificate renewal has gotten too painful?
> I do not think PKI will survive the 47 day change. […] In our case, we'll be spending the next couple years reducing our use of PKI certificates to the bare functional minimum.
Maybe PKI will die… or you will. Progress doesn't treat dinosaurs too well usually.
> In our case, we'll be spending the next couple years reducing our use of PKI certificates to the bare functional minimum.
Good. A certificate being publicly trusted is a liability, which is why there are all these stringent requirements around it. If your certificates do not in fact need to be trusted by random internet users, then the CA/B wants you to stop relying on the Web PKI, because that reduces the extent to which your maintenance costs have to be balanced against everybody else's security.
As I said in another comment, private CAs aren't that popular right now in the kinds of organizations that have a hard time keeping up with these changes, because configuring clients is too painful. But if you can do it, then by all means, do!
I suspect when companies who are members actually realize what happened, CA/B members will be told to reverse the 47 day lifetime or be fired and replaced by people who will. This is a group of people incredibly detached from reality, but that reality is going to come crashing through to their employers as 2029 approaches.
> Good.
You may assume that most organizations will implement private CAs in these scenarios. I suspect the use of encryption internally will just fall. And it will be far easier for attackers to move around inside a network, and take over the handful of fancy auto-renewing public-facing servers with PKI anyways.
If an org is tech-forward enough to have bothered setting up HTTPS for internal use cases on their own initiative, just because it was good for security, then they're not going to have major problems adapting to the 47-day lifetime. The orgs that will struggle to deal with this are the ones that did the bare minimum HTTPS setup because some external factor forced them to (with the most obvious candidate being browsers gradually restricting what can be done over unencrypted HTTP). Those external factors presumably haven't gone anywhere, so the orgs will have to set up private CAs even if they'd rather not bother.
Most of the other forum members either won't oppose longer lifetimes (every cert vendor would be happy) or will bow to the only two companies that matter.
And I really hope you are wrong that it will not get reversed. (I hope I am wrong about the above, but I doubt it.)
When the Internet breaks, people die. It's all fun and games to talk about hypothetical security problems that you aren't actually solving as an excuse to make the Internet incredibly transient and fragile, but it has a real human cost.
Right now, over 80% of organizations have outages do to a certificate issue every year. That's really bad, and already due to the CA/B's poor decisionmaking. But at the existing certificate lifetimes, at least it's predictable. Now the CA/B wants to multiply the possible problem occurrences by a factor of ten. And an organization can't even just be concerned with their own certificates, because any layer of their stack's software or infrastructure having a certificate error can have downstream effects.
The reason I believe this change will be undone, is because ultimately it will have to. It will be so obviously wrong if it goes into effect that people opposed to undoing it will get removed from the decisionmaking until it is undone.