Or you can just periodically renew the certificate on server using Task Scheduler + win-acme or Cron and certbot.

In my experience, it takes a little effort to set things up the first time, but from then on it just works.

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.

The certificate from LE will expire automatically 90 days after it was provided, that's why you need to renew it before the 90 days are up.

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.

> Also, why not support file based auth in .well-known/acme-challenge/... for domain wide certs

An ACME challenge file on a web server proves that you control a specific server at a specific domain, so you get a certificate for a specific domain.

A DNS entry proves you control the entire domain, so you (can) get a certificate for the domain.

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

The solutions exist, depensa on the providers and your client.

An attacker should not gain the ability to persistently issue certificates because they have one-time access to DNS. A non-technical user may not notice that the record has been added.

> Also, why not support file based auth in .well-known/acme-challenge/... for domain wide certs? Which attack vector does that prevent?

Control over a subdomain (or even control over the root-level domain) does not and should not allow certificate issuance for arbitrary subdomains. Consider the case where the root level domain is hosted with a marketing agency that may not follow security best practices. If their web server is compromised, the attacker should not be able to issue certificates for the secure internal web applications hosted on subdomains.

    #!/usr/bin/env bash

    cert_check() {
        server=$1
        host=$2
        port=$3

        str=`ssh "$server" "echo | openssl s_client -servername $host -connect localhost:$port | openssl x509 -noout -checkend 604800"` || true
        if ! echo "$str" | grep -q 'Certificate will not expire' ; then
            echo "$str" | ./send-email.py "Certificate \"$host\" on $server will expire in 7 days" \
        fi
    }

    cert_check name myserver.com 443

I don't begrudge people writing a tool to learn, but it should be noted that this wheel has already been invented:

* https://github.com/matteocorti/check_ssl_cert

* https://exchange.nagios.org/directory/Plugins/Security/check...

* https://github.com/narbehaj/ssl-checker

* https://github.com/Matty9191/ssl-cert-check

Risk of private keys/certificates from old backup media being leaked (remembering the adobe password leak...) and then suddenly coming back online and working until someone figures out how to revoke them

It also helps with things such as change of ownership so after a certain period of time you can have the peace of mind that certs potentially issued by the previous owners are not lingering around as active (I understand things such as revoking and pinning can help with this too but It's nice to have a plain time based expiry too).

You revoke a certificate when you believe that it might have been compromised. Expiring certificates helps protect you when you've unknowingly been compromised.

So let's say that one of your employees accidentally pushed a private key for one of your certificates up to GitHub and you notice it. That's when you should immediately rotate that certificate and revoking the old one.

Now let's say that the same thing happened but you didn't notice. That's where the certificate expiring comes into play. For a Lets Encrypt certificate there's currently going to be a maximum of 90 days where someone could find that private key and work out a way to exploit it, after that period the certificate would have expired and no longer be being used.

Improvements can be changes to cryptographic algorithms, like "Don't use SHA-1" or to the nuances of the certificate document like "Don't use this X509 feature" or to the CA infrastructure like "Don't issue certificates for names which don't exist".

Shortened certificate lifetimes improve agility by bringing forward that horizon. We can say "Stop doing X by August" tomorrow, and by Christmas 2026 there are no trusted end entity certificates which relied on X. A few years ago that took 3-5 years, at the turn of the century it was more than a decade and we repeatedly paid a price for that.

Yet it was still valuable to find those that fell through the cracks. At work, the emails prevented a couple of outages by expired cert, because a dev that left was renewing them by hand and we only found out when they left and the catch-all started to bubble them up to support.

Things fall through the cracks, or people are in a pinch and just forget to add the cert to the in-house monitoring system. The emails were a wonderful failsafe.

I wish I could just query LE to tell me all existing certain where the account is under my domain name. Extremely helpful to assemble a SBOM.

> For those who would like to continue receiving expiration notifications, we recommend using a third party service such as Red Sift Certificates Lite (formerly Hardenize). Red Sift’s monitoring service providing expiration emails is free of charge for up to 250 certificates. More monitoring options can be found here.