SSL certificate requirements are becoming obnoxious

I feel like a lot of these requirements need to be really solved from first principles. What do you need these certificates for -- specifically, TLS certificates?

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?

In our defense, it’s because we’re expected to give everything a cert but often have no say on the security and cryptography capabilities of what’s brought onto the network in the first place, nevermind the manpower and time to build such an automated solution internally. Execs bringing in MFPs that don’t support TLS, PLCs that require SHA-1, routers with a packet buffer measured in single-digit integers but with a Java web GUI, all of these horrors and more are why it’s such a shitshow even today.

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.

Alternatively, those people are dealing with legacy systems that are pathologically resistant to cert automation (looking SQUARELY AT YOU vmware) and elect for the longest lasting certs they can get their hands on to minimize the disruption.

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.

What's frankly ridiculous is that the big softwares like Nginx and Apache don't deal with this on their own. I've been letting Caddy (my http host of choice) deal with TLS for me for _ages_ now. I don't have to think about anything, I don't have to setup automation. I just... configure my caddy to host my website on https://my.domain.com and it just fetches the TLS for me, renews it when necessary, and uses it as necessary.

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)...

Let's Encrypt is run by a nonprofit organization [1], funded by corporate and individual sponsors (like Google and AWS, but also the EFF and Mozilla) [2].

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.

[1] https://www.abetterinternet.org/about/

[2] https://www.abetterinternet.org/sponsors/

With you in general, but in this specific case, the whole thing seems healthy:

- 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 think for certs, you are not better of paying $5 for the cert, than paying nothing to get an LE cert. It is already "subsidized" into cheapness, and the $5 company will bug you with ads for EV certs and whatnot in order to make a profit off you somehow since you are now a customer.

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.

Whats a LetsEncrypt competitor which has convenient automated renewal?

There are paid ACME services - basically LE with paid support.

Well, its eidas, ofc you need to show the id

I think it's all about change management

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...

I just recently had a executive level manager ask if we could get a 100 year cert for our ERP as the hassle of cert management and the massive cost of missing a renewal made it worth it.

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.

The exact time probably has no "best" but from past times: I have seen so many places where multi-year certificates were used and people forgot about them, till some service suddenly stopped working and then people having to figure out how to replace that cert.

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

Sure, there is an argument about slippery slopes here. But the thing about the adage of "if you slowly boil a frog..." (https://en.wikipedia.org/wiki/Boiling_frog) is that not only is the biological metaphor completely false, it also ignores the fact that there can be real thresholds that can change behavior.

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."

>Why isn't it instead just a minute? or a few seconds? Wouldn't that be better?

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.

I'm not sure if you're arguing in good faith, but assuming you are, it should be pretty self-evident why you wouldn't generate the certificate dynamically each request: it would take too much time to do so, and so every request would be substantially slower, probably as slow as using Tor, since you would need to ask for the certificate from a central authority. In general it's all about balance, 1 month isn't necessarily better than 1 year, but the reduced timeframe means that there's less complexity in keeping some renovation list and passing it to clients, and it's not so short to require more resources on both the issuer and the requester of the certificate.

> Perhaps it's time to go with another method entirely.

What method would you suggest here?

There was an attempt doing it differently by CRL but it turns out certificate revoking is not feasible in practice on web scale.

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.

> Why wouldn't you go with a week or a day? isn't that better than a whole month?

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 these setups, the issue already exists: an appliance would have to renew its SSL certificate when it expires. I believe ssl certificates should already not be used anywhere they can't be renewed.

Oversight over… what exactly? TLS certificates don't need human oversight. If you want to see which certificates have been issued for your domains, set up certificate transparency monitoring. But thank goodness we're past paying people for comparing certificate checksums.

Do you really need more oversight on renewals than a simple success/failure notification?

For new certificate you can keep the existing amount of human oversight in place so nothing changes on that front.

No better way to create errors at scale than automation ;-)

Why is fronting these systems with a central haproxy with TLS termination or similar not an option?

I think the problem with this idea is not security (as you point out, the status quo isn't really better), but availability. It's not all that uncommon for poorly designed middleboxes to block TXT records, since they're not needed for day-to-day web browsing and such.

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.

For convenience, here are the quotes that most directly answer the above question:

"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."

It's trivial for an attacker to learn the validation origins by triggering validations of their own servers while watching the logs. Secrecy confers no advantage here.

Renting five servers 500km apart each, spread across at least two continents is hardly a difficult or costly requirement

I can't tell if it's a typo but HTTP-01 would contact your webserver on :80 in order to successfully retrieve a very, very, very specific ACME path and does not care at all what you do with your issued TLS afterward, including what port you run it upon

Also, I know firsthand that the DNS Validator also works perfectly fine, no http check required

You can get LetsEncrypt certificates for endpoints that aren't publically accessible through the DNS-01 challenge.

Why or in which cases is opening a dedicated port better than publishing challenges under some /.well-known path using the standard HTTP port?

(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)

Who do you propose needs to fuck off in order for the web to not need certificate authorities?

As a friendly reminder, SRV records exist and are great at fixing that magic port syndrome (unless you were hinting at the infinite corporate firewall appliances, for which I have no magic fix)