Let's Encrypt does exactly the right thing, which is to email you if a certificate is expiring without being renewed. Pretty much the behaviour you'd want from any CA, no?
But in a non-technical organisation, who should those messages go to?
Often the initial LetsEncrypt setup will be handled, correctly, by some IT staff. Then it might break several months or years later for some odd reason.
The organisational challenge is to get the message through to someone who understands it and will act on it.
Yes, and to keep a very infrequently used channel working and up-to-date.
Hence efforts like https://tools.ietf.org/html/rfc8701 - designed to make sure extensibility options don't get messed up.
This time the problem was LE all of a sudden decided to start storing my certificate in a directory called mydomain.com-0001 instead of mydomain.com, breaking the rest of the setup that relies on things being in the right directory. Automation is only useful when the software behaves predictably and consistently.
So if renewal fails you should have ~30 days to fix it.
But this does work best if your tools try the 2-month renewal. (I'm looking at you, wpengine!)
I'm looking for a program that is going to connect to all my SSL sites, and report back a problem if the cert is within 30 days of expiration. It is easy enough to write a client that will fail after the cert has expired, but I want one that will warn me ahead of time. And I don't want to mess with the system clock or something like that.
It shouldn't be a big program, I may just write it myself.
Also my employer (well, until the end of this week) Kynd does this as part of its broader "Check cyber-security stuff" offering for non-technical people. https://www.kynd.io/
define command {
command_name check_certificate
command_line $USER1$/check_http -H $ARG1$ -p $ARG2$ -4 -S -C 21 -t 20 --sni
}
is totally free, superfast and checks your TLS settings too (it's my baby)
But as a person who rolls LE certs across a very non-happy-path environment (many SAN domains, edge nodes which are geo-balanced).
I have a lot of issues automating this process, right now I have a HTTPd which reverse proxies the .well-known back to a central place where I run certbot and then I push out the cert to the nodes, however, sometimes one of our SAN domains will need to be removed and the whole universe comes crashing down.
DNS-01 Challenge is "nice" (although, doesn't feel super well supported); but requires domains registered with some kind of DNS server that accepts API's to change records, so Amazon route53- but it's exceptionally hard to roll your own DNS in this case. :\
1. HTTP-01 challenges have a "correct" answer for a given Let's Encrypt account which depends only on the challenge (ie the part in the HTTP GET request) and on knowing which account you want to use.
Silently Certbot creates you an account, with a private authentication key and so on, for the Let's Encrypt service. When it gives you a file to prove control by placing it in /.well-known/acme-challenge/ the content of the file is always the same as the filename, plus a suffix that depends on your key.
So long as you use the same account you can thus bake this suffix into the web server, essentially causing it to answer any request from anybody: "Hey, who is allowed to issue for somename.example ?" "dijit is allowed to do that". Bad guys can't use this because they don't know your private account key, but for you now magically everything is authorised, since when it is asked your server will answer "dijit is allowed to do that" to any question it's asked.
2. DNS-01 can be redirected using CNAME. Add a CNAME, once, manually if necessary, to redirect the DNS-01 checks to a DNS server you've set up for this specific purpose.