> If you hate setting up automated certificate renewal, you can still get longer-lasting certificates from paid certificate providers.

Not for much longer, the maximum lifetime of a public certificate will progressively go down to 47 days by March 2029.

> If you hate setting up automated certificate renewal, you can still get longer-lasting certificates from paid certificate providers. It used to be that you needed to pay a company to generate a certificate for you every year, now you just get the option to have a free one every 90 days.

I took the easier route and let Cloudflare generate and handle certs for my domains. I’m on the free tier. I secure traffic between them and my host with an origin cert. By default those are valid for 15 years.

I know CF is frequently criticised around here, but wanted to mention it as an option.

That works too, of course. You don't even need a specific certificate or even an open port by leveraging Cloudflare tunnels, which means you can host your website on a local server behind three layers of NAT if you had to.

And it's not just Cloudflare; there are plenty of other redirect-everything-through-a-CDN hosts available. If you don't mind giving Cloudflare control of your website (and barring visitors from countries like India where CGNAT makes everyone fill out CAPTCHAs every page load), this approach will take care of just about everything.

Agreed. It’s about priorities and tradeoffs.

I’ve been impressed with how much I get on the free tier (my sites are small). With the DDoS protections, rate limit, WAF rules, and Turnstile, it feels like I can keep a significant amount of abusive traffic from reaching my host. It’s a pretty compelling tradeoff for me, anyway.

You now have described the status quo in length. But you have not touched on why it is supposed to make sense. You have not provided attack vectors for the easier alternatives.

    By uploading a file to tekmol.freewebhost.com,
    you haven't proven that you control either
    .freewebhost.com

Who said that putting a file on a subdomain should grant you a cert on the domain? Putting it on domain.com/.well-known/acme-challenge/ should.

They attempted to indicate wildcards there, but HN ate them. That should say "you haven't proven that you control either *.freewebhost.com or *.tekmol.freewebhost.com".

Now, I can definitely see there being a system where the owner of the root domain (eg, freewebhost.com) can set up something in their own .well-known directory that specifies that any subdomains can only declare certs for that specific subdomain, rather than being able to claim a wildcard, and then we can allow certs that sign wildcards in cases where such a limiter is not in place.

In any case, this would only solve the DNS auth hurdle, not the overall expiration hurdle.

    solve the DNS auth hurdle, not the
    overall expiration hurdle

That would already be a big step forward.

  > That's like saying "why does the government expire my passport/driver's license when I haven't changed my name". That's not how it works; the document is stamped valid for a specific amount of time, and you get a new document with a new expiration time when you renew it.

That does not answer the question, why?

Because certificate lifetimes need to be determined when they’re issued. They aren’t dynamic and so can’t be changed in response to whether an acme challenge file exists.

Passport is a good example. So is bank notes. They expire to add new security features.

Banknotes don't expire.

There’s plenty that have. Just one example: https://en.wikipedia.org/wiki/Military_payment_certificate

Similar schemes have been used in the past as a forcing function against tax evasion or simply to phase out less secure older bills.

In practical terms retailers can refuse old ones. In countries I have lived in.

Specific notes and coins do, despite the underlying money doesn't.

The government expires your driver's license because they want to charge you for a renewal. You can tell that this is the only reason because it's the only thing they want in order to give you a new one. They do nothing to confirm that you still know how to drive.

But Let's Encrypt doesn't charge anything. All they want is to confirm that you still control the domain. So why doesn't "the DNS record they had you add to begin with is still there" satisfy that requirement and allow you to repeatedly renew the certificate until it stops being there?

Tie the DNS challenge to the public key in the certificate. Then as long as it hasn't changed you can update the certificate without giving the update process modify access to the DNS server.

Most governments primarily don’t want stolen identity documents circulating without any time bounds, especially given that they often get used improperly these days (e.g. by allowing a photo/scan of somebody’s ID to constitute “authentication” without comparing the photo to a real person, which is a bizarre notion that’s getting more and more common).

Passports and license renewals are often for periods in the nature of 10 years. Is that meaningfully different from the self-invalidation already implied by an ID that claims you're 144 years old? The mean time between mass data breaches is certainly already less than the existing renewal interval.

Meanwhile how does a stolen scan of an identity document become invalidated by requiring a renewal? The new document is identical and even contains the same ID number. The only difference is the date which anyone could trivially alter with a computer. For that matter the only thing they need from the stolen ID is the name and number, so even if you completely redesign the layout of the ID, someone with the old one can recreate a scan of the new layout using only the information on the old stolen one.

The problem here is not that you need IDs to expire, it's that you need fools to stop trying to rely on a computer image of an ID to authenticate anything.

> The new document is identical and even contains the same ID number.

Quite a few IDs contain a 2D barcode, and I believe at least some of these contain some offline-validateable signature over the basic data of the document, including the expiry date. That's not as trivial to forge.

On top of that, document expiry does help a bit with people trying to use a lost/stolen ID of somebody they happen to look similar to, adds a forcing function to make people eventually upgrade to newer/more secure document standards etc.

> Quite a few IDs contain a 2D barcode, and I believe at least some of these contain some offline-validateable signature over the basic data of the document, including the expiry date. That's not as trivial to forge.

Most government IDs don't have that, and it's still not clear what good it would be doing when data breaches happen on much shorter timescales than ID expirations. Who cares if they stop being able to use the ID after 10 years, when they can use them for 10 years and there will be another breach providing them with a new batch of IDs to use in a matter of days rather than years?

> On top of that, document expiry does help a bit with people trying to use a lost/stolen ID of somebody they happen to look similar to

That seems like an extremely narrow advantage. If they just need some ID that looks like them then they can just get another one from the batch of fresh ones. If they need the ID of a specific person, the government still isn't authenticating renewals, so wouldn't they just use the existing stolen ID and pay for a renewal in that case, in which case we're back the only thing happening being the government extracts money?

Or no, in that case it's worse, because then they can submit a fresh picture of themselves to renew the ID which has someone else's name on it.

> adds a forcing function to make people eventually upgrade to newer/more secure document standards etc.

Which you already have because everybody eventually dies.

Regarding "the DNS record they had you add to begin with is still there", it generally isn't. Part of the automation process for certbot using the DNS-01 challenge is the removal of the DNS record, following successful validation of said record. In any complex DNS environment, leaving TXT records around just increases the debris.

It's the Let's Encrypt people who make certbot, so that's just an implementation detail, and the premise here anyway is that you would be doing it manually (once) because the inconvenience to be avoided is when certbot can't update the DNS records automatically.

No, it's not the LetsEncrypt people who make certbot. Certbot is an EFF project, managed by separate people. Additionally, most of the DNS implementations will require the use of a specific plug-in/library for your selected DNS platform, and those, also, are developed separately.

Let's Encrypt was an EFF project to begin with. They're still the same people.

The DNS plugins only matter if you're trying to automate updating the DNS entry. The whole point is that you could have certbot spit out a DNS TXT record for the user to manually add to their DNS once, e.g. which contains the public key fingerprint of the certificate they want Let's Encrypt to renew on an ongoing basis, and then certbot would be able to renew the certificate as long as the DNS record remains in place.

No, LetsEncrypt was not an EFF project to begin with. Look, it works how it's documented to work. If you wish it worked some other way, to solve your particular suggested workflow, you're likely free to fork it and make it work that way.

Good luck.