and each successive run had a higher numbered file (like cert6.pem).
This worked for certbot 0.38 and 0.39 (from EPEL). However it apparently broke when yum automatically updated certbot to 1.0.0. Previously it was verifying both SERVER1 and SERVER2 against SERVER1. However now it seems to be trying to do both against SERVER2 and that fails. I was able to make a certificate for just SERVER1 which verified against SERVER1.
and the file number is 1. Instead of putting the new ones into the original directory with higher file numbers. What controls this? Can I restore the previous behavior? And in general, where is the certbot documentation???
This command looks right... (try to remove all the "" and make it into one line.)
Let's Encrypt would generate a link file at /etc/letsencrypt/live/SERVER1.bio.caltech.edu/fullchain.pem and /etc/letsencrypt/live/SERVER1.bio.caltech.edu/privkey.pem.
This link is automatically updated after renewal.
If you already had the inital certificate issued, you can actually run sudo certbot renew and reload the web server after successful attempt. (Given that you used the live folder syn links)
This is due to creating certificates with overlapping name coverage. Certbot will never remove a name from an existing certificate unless you specify --cert-name, but if your new certificate with some names missing would have the same name as an existing certificate, it instead gets -0001, -0002, etc.
I found the problem. In early 12/2019 the web server was reconfigured to redirect all http queries to https. That worked on 12/25/2019 with certbot 0.39, but not later with certbot 1.00.
SERVER2 had in httpd.conf:
allow from caltech.edu letsencrypt.org compute.amazonaws.com
but in /etc/httpd/conf/extra/httpd-ssl.conf there was only:
allow from caltech.edu
adding the other two terms lets the full certbot command work.
This does raise another question though, which seems to be a “a chicken or the egg” situation. If everything is being redirected to https, and there is not yet a certificate, or the certificate has expired (or been revoked, or any other such problem), can certbot then run its tests successfully to generate a new certificate? If not, must one special case the test directory to keep it http rather than https?
Yes. I believe there was a mention that Let's Encrypt will ignore SSL error (wrong//invalid certificate) and proceed with validation.
P.S. I really want to suggest you to change the certificate/key references to /etc/letsencrypt/live/ 's symbolic link, so you won't need to use the find / cp script... (Just need to reload the apache server with certbot --clean-up-hook)
If memory serves the copy method was used because SELINUX kept locking out the link, at least once, and perhaps it was every time the target was updated. (My notes are unclear and I don’t want to experiment with it.) Rather than fight with SELINUX and have it fail at some unknown future point when that system’s behavior changes yet again, it was easier just to copy the file over. The cert generation is running in a cron script anyway, so two extra lines is no big deal.