Depends on which DNS service you are using, a plugin might already exist that would do it for you. e.g. I use cloudflare for DNS and certbot is able to automatically set the txt record.

For internal stuff, it may be easier to set up your own CA.

Hot take: for-profit orgs should be buying TLS certificates from the CA cartel instead of using Let's Encrypt. Unless you're donating to LE, and in that case it's cool.

our org forbids plain http

is redirecting http to https also out of the question? because let's encrypt HTTP-01 accepts http -> https redirects:

Our implementation of the HTTP-01 challenge follows redirects, up to 10 redirects deep. It only accepts redirects to “http:” or “https:”, and only to ports 80 or 443. It does not accept redirects to IP addresses. When redirected to an HTTPS URL, it does not validate certificates.

Can't use DNS?

Forgive my ignorance but why would that incur a downtime?

The only way I can think of for downtime to happen if you switched certs before the new one was signed (in which case ..don't) or am I missing something?

It also strikes me as weird that LE requires 80 but does allow insecure 443 after a redirect. Why not just do/allow insecure 443 in the first place?

Yeah, this has become an issue for us at work as well.

Currently we are doing a POC for an in-house developed solution where a azure function app handles the renewal of certificates for any domain we have, both wildcard and named, and place the certificates in a key vault where services that need them can get access.

Looks to be working, so the main issue now is finding a non-US certificate provider that supports acme. EU has some but even more local there aren't many options.

You could try using the DNS challenge instead; I find it a lot more convenient as not all my services are exposed.

The usual way for me is to give certbot write access to a directory in the HTTP root, so the server can keep running.

Half a dozen sounds like a lot, kinda curious what you are running? If they all are web services maybe use a reverse proxy or something?

You could try a path unit watching the cert directory (there are caveats around watching the symlinks directly) or most acme implementations have post renewal hooks you can use which would be more reliable.

Don't worry, they'll sell you new software for another $50.00/m/certificate to help with the new certificate fiddling you now have to do monthly. It didn't make sense for them to release it until they pushed through the 45 day window change through backchannels.

Personally, yes. Everything is behind NPM and SSL cert management is handled by certbot.

Professionally? LOL NO. Shit is manual and usually regulated to overnight staff. Been working on getting to the point it is automated though, but too many bespoke apps for anyone to have cared enough to automate the process before me.

This is one of the reasons they're reducing the validity - to try and convince people to automate the renewal process.

That and there's issues with the current revocation process (for incorrectly issued certificates, or certificates where the private key was leaked or stored insecurely), and the most effective way to reduce the risk is to reduce how long any one certificate can be valid for.

A leaked key is far less useful if it's only valid or 47 days from issuance, compared to three years. (note that the max duration was reduced from 3 years to 398 days earlier this year).

From https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days:

In the ballot, Apple makes many arguments in favor of the moves, one of which is most worth calling out. They state that the CA/B Forum has been telling the world for years, by steadily shortening maximum lifetimes, that automation is essentially mandatory for effective certificate lifecycle management.

The ballot argues that shorter lifetimes are necessary for many reasons, the most prominent being this: The information in certificates is becoming steadily less trustworthy over time, a problem that can only be mitigated by frequently revalidating the information.

The ballot also argues that the revocation system using CRLs and OCSP is unreliable. Indeed, browsers often ignore these features. The ballot has a long section on the failings of the certificate revocation system. Shorter lifetimes mitigate the effects of using potentially revoked certificates. In 2023, CA/B Forum took this philosophy to another level by approving short-lived certificates, which expire within 7 days, and which do not require CRL or OCSP support.

That's a lot easier said that done for hobbyists that need a certificate for their home server. I will give you a real world example. I run Ubuntu Linux (but without snaps) on my main desktop machine, however like the person you replied to I am old and I don't have a good memory so when I do use Linux I try to take the easiest approach possible. But I also have a server running on a Raspberry Pi, and another family member (that has a Mac) that I exchange XMPP-based instant messages with. The server runs Prosody, and on my Ubuntu box I run Gajim (the one from the apt repository which is version 1.8.4, I have no idea why they won't put a newer version in the repo). The other family member uses some MacOS-based XMPP client. The problem is that if there is not a valid certificate on the server, Gajim refuses to send or receive anything other than plain-text messages. It won't sent or receive files or pictures, etc. unless the certificate is valid.

However the Raspberry Pi does other things as well (it would be silly to dedicate a Pi to just running Prosody) and one of those other things puts a pseudo-web server of sorts on port 80, which is only accessible from the local network. So I can't use Certbot because it insists on being able to connect to a web server. Even if I had a general web server on the Pi, which I don't have and don't want, it would be restricted for local access only. Also, I'm not paying for a DNS address for my own home server. What I found I could do is get a DuckDNS address (they are free) and use that to get a LE certificate. But the procedure is very manual and kind of convoluted, you have to ssh into the server using two separate sessions and enter some information in each one, because of the absolutely asinine way LE's renewal process works if you don't have a web server. I hate doing it every 90 days and if I have to do it every 45 days I'll probably just give up on sending and receiving files.

I should also mention that it took me hours to figure out the procedure i am using now, and it seems so stupid because I have that server locked down with two firewalls (one on the router and then iptables on the server) I don't even want a certificate but the designers of Gajim in their infinite wisdom(?) decided not to give users the option to in effect say "I trust this server, just ignore an expired or missing certificate." And the designers of LE never seemed to consider that some people might need a certificate that are not running a web server (and don't want to run one) and provide some automatic mechanism for renewing in that situation. And just because someone uses Linux does not mean we are all programmers or expert script writers. I can follow "cookbook" type instructions (that is the ONLY way I got Prosody set up) but I can't write a script or program to automate this process (again, I'm OLD).

I know somebody's going to be tempted to say I should use some other software (other that Prosody or Gajim). I tried other IM clients and Gajim is the only one that works the way I expect it to. As for Prosody, I have from time to time tried setting up other XMPP servers that people have suggested and could never get any of them to work. As I said, had I not found "cookbook" type instructions for setting up Prosody I would probably not be running that either, it was a PITA to get working but not that it IS working I don't want to go through that again. And Prosody isn't the problem, it works perfectly fine without a valid certificate, but pretty much every Linux IM client I have tried either loses functionality or won't work at all if the server doesn't have a valid certificate. And no I don't run or use Docker, nor do I have any desire to (especially on a Raspberry Pi).

EDIT: After giving this some thought I decided look further into this, and discovered that while Certbot can't handle this, it's possible that a script called acme.sh can. See https://github.com/acmesh-official/acme.sh?tab=readme-ov-file (also https://github.com/acmesh-official/acme.sh?tab=readme-ov-file#8-automatic-dns-api-integration - may need to scroll up just a bit, the pertinent item is "8. Automatic DNS API integration"). I haven't tried it yet (just manually renewed yesterday) but it looks promising if I can figure it out. Thought I'd post the links for anyone else that might be in the same situation.

But can you imagine the load on their servers should it come to this? And god forbid it goes down for a few hours and every person in the world is facing SSL errors because Let’s Encrypt can’t create new ones.

This continued shortening of lifespans on these certs is untenable at best. Personally I have never run into a situation where a cert was stolen or compromised but obviously that doesn’t mean it doesn’t happen. I also feel like this is meant to automate all cert production which is nice if you can. Right now, at my job, all cert creation requires manually generating a CSR, submit it to a website, wait for manager approval, and then wait for creation. Then go download the cert and install it manually.

If I have to do this everyday for all my certs I’m not going to be happy. Yes this should be automated and central IT is supposed to be working on it but I’m not holding my breath.

Well that could be considered the point where we lost our innocence, yeah. :(

Imagine trying to do this (excluding China, Russia and some middle eastern or african countries) in the western world.
I would assume total anarchy (especially in the stock trade lol)

Oh, definitely rose-coloured, but I am thinking even before those days... like when access to Usenet was restricted to colleges and universities, dial-up BBSes ... and I didn't use Windows or MacOS at all back then. ActiveX and js didn't even exist back then. Boot-sector floppy viruses did, but those were easy to guard against.

More the latter :) ... if only we could all just get along and be nicer to each other. Sigh.

Oh, I'm really just pining for the days before the 'Eternal September', I suppose. We can't go back, I know. :/

Signing (intermediate) certs have been compromised before. That means a bad actor can issue fake certs that are validated up to your root ca certs

While you can invalidate that signing cert, without useful and ubiquitous revocation lists, there’s nothing you can do to propagate that.

A compromised signing certs, effectively means invalidating the ca cert, to limit the damage

yeah good advice

Let's be extra safe. New cert per every request

Well it should be as short as possible while still being practical. LE doesn't have infinite server compute, renewal also takes some amount of time, plus if they make the validity too short people might stop using them (pretty evident judging from sentiment here) and move to other CAs and make what they do pointless.

45 days are still plenty of time yet people are already complaining. Does make me worry.