[metastart]

I really really wish LetsEncrypt would support 1 year long certificates.

Round Robin DNS isn't really supported "easily" so for those sites & others, manually replacing certs every year would be a more practical option.

To generate revenue, they should charge for stronger business confirmation like all the other for-profit certs.

[tialaramex]

The long term goal, supported by Let's Encrypt, is that almost everybody should stop "manually replacing certs".

When Let's Encrypt launched, the rule was 39 months. You could buy a certificate in 2015 and not need to replace it until 2018. If you had typical accounting practices a server might only ever need two certificates between when it's first purchased and installed and when it is finally retired and sent for scrap.

Ryan Sleevi and co. fought for two years and eventually got 825 days.

But in 2020 Apple unilaterally announced that they'd decided they didn't respect the line in the sand on this issue from mostly for-profit CAs, and their policy would require a maximum lifetime of 398 days.

You should not depend on this as the last word. I can certainly see less than 100 days being required later this decade.

As to "stronger business confirmation" it's essentially worthless. The client software doesn't enforce stuff you think you read in a certificate, because it doesn't understand it. The SANs can be understood by a machine so those are enforced, but nothing else is.

Example: When you visit google.com, your browser silently and automatically verifies at each step that this is really google.com, by doing effectively memcmp(dnsName, "google.com") for every single HTTPS transaction. That's mindless work so it can get it correct without bothering you. But even if the certificate includes Google's business number and postal address (which it does not) the browser can't match those against anything, they're just gibberish to a machine. It entirely ignores these values.

So: If at any step the remote site can't prove it is google.com, that fails immediately. Suppose you're typing in your password, the HTML form loaded just fine, and now it's just a POST to submit. During that POST the browser verifies, as it always does, that this is google.com. But if the business is now named "Bob's Toys" of "1234 Toy Town, Nowhere" it doesn't know that's wrong, your password will be sent anyway. Most likely after the password is sent, the response is a 30x HTTP code, and the browser fetches a different URL, which might incur a new HTTPS connection with a new certificate. So the "Bob's Toys" certificates was never seen by a human (you) at all, and the browser doesn't know who Bob's Toys are or that they're not google.com, it only checks that the DNS names match.

Only DNS names matter. Maybe you're happy about that, maybe you're sad, but it won't stop being true either way.