Changes certbot 0.39 to 1.0.0?

#1

A CentOS 7 machine running Apache2 has two web servers at:

SERVER1.bio.caltech.edu
SERVER2.bio.caltech.edu

and a single set of certs were made for BOTH with:

certbot certonly  --webroot --force-renewal  \
 -w /home/apache2/htdocs -d SERVER1.bio.caltech.edu,SERVER1.caltech.edu \
 -w /home/apache2/SERVER2 -d SERVER2.bio.caltech.edu 1>>$LELOG 2>&1

and these were installed with:

LADIR=/etc/letsencrypt/archive/SERVER1.bio.caltech.edu
FC=`find $LADIR -anewer $TS | grep fullchain`
PK=`find $LADIR -anewer $TS | grep privkey`
/bin/cp $FC /home/apache2/conf/ssl.crt/letsencrypt_server.pem
/bin/cp $PK /home/apache2/conf/ssl.key/letsencrypt_key.pem
apachectl restart

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.

certbot certonly  --webroot --force-renewal  \
 -w /home/apache2/htdocs -d SERVER1.bio.caltech.edu,SERVER1.caltech.edu \
  1>>$LELOG 2>&1

What is the current syntax equivalent to the original above, to make a single set of certs for both web servers?

Also, when the single server command was run it created a new directory

/etc/letsencrypt/archive/SERVER1.bio.caltech.edu-0001

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???

Thanks.

#2

certbot documentation is here: https://certbot.eff.org/docs/using.html?highlight=hook#webroot

and it says that your syntax should work.

moreover, if you use --deploy-hook and cp -L you don’t need to get LADIR, FC and PK that way.

#3

This is the expected behavior.

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)

1 Like
#4

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.

1 Like
#5

Thanks for the feedback. It helped.

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?

1 Like
#6

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)

Thank you

1 Like
#7

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.

2 Likes
#8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.