Upgrading Let’s Encrypt – now Known as Certbot

First of all Electronic Frontier Foundation are the original cyberpunk revolutionary organization as far as my ignorant ass is concerned. Anyway for Open Food Foundation, we used their Python Let’s Encrypt library to install a free security certificate.

The certificates need to be renewed every few months (3, 6?). Well when I finally tracked down the location of Let’s Encrypt:

sudo find / -name "letsencrypt"

OK. From their docs I deduce that the files in the user local share directory are probably the binary:

sudo /home/michael/.local/share/letsencrypt/bin/letsencrypt
| You are running with an old copy of letsencrypt-auto that does not   │  
│ receive updates, and is less reliable than more recent versions. We  │  
│ recommend upgrading to the latest certbot-auto script, or using      │  
│ native OS packages.                                                  │  

From the github page it tells me to go here to find out about upgrade, install, etc….

I forget what version of Ubuntu is installed.

$ cat /etc/lsb-release

And we are running nginx webserver.

The instructions for installing are on the web page. But I don’t see anything about upgrading.

I’m going to bet that I can install the new certbot without backing up or moving any of the original directories. There isn’t a lot at stake here.

I am going to install it in the same location: ~/.local/share/letsencrypt/bin.

$ ~/.local/share/letsencrypt/bin/certbot-auto renew --dry-run
Requesting root privileges to run certbot...
  /home/michael/.local/share/letsencrypt/bin/letsencrypt renew --dry-run

Processing /etc/letsencrypt/renewal/staging.usfoodcoop.org.conf
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

Congratulations, all renewals succeeded. The following certs have been renewed:
  /etc/letsencrypt/live/staging.usfoodcoop.org/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)

 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.

That couldn’t have been much easier. The actual run went well too. Now for setting up autorenew with crontab.

crontab -e
# m h  dom mon dow   comman
@daily  /home/michael/.local/share/letsencrypt/bin/letsencrypt renew

Have a nice night. Wait. Not so fast! The certificate doesn’t seem to be associated with my site. Still getting a Firefox warning.

Rrrrr. Let’s install a new certificate.

~/.local/share/letsencrypt/bin/certbot-auto certonly --webroot -w /var/www/webrootauth -d usfoodcoop.org -d staging.usfoodcoop.org


| You have an existing certificate that contains a portion of the      │  
| domains you requested (ref:                                          │  
| /etc/letsencrypt/renewal/staging.usfoodcoop.org.conf)                │  
|                                                                      │  
| It contains these names: staging.usfoodcoop.org                      │  
|                                                                      │  
| You requested these names for the new certificate: usfoodcoop.org,   │  
| staging.usfoodcoop.org.                                              │  
|                                                                      │  
| Do you want to expand and replace this existing certificate with the │  
| new certificate?                 


Failed authorization procedure. usfoodcoop.org (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http: #etc

Where is this directory:

sudo find / -name "acme-challenge"

What’s in it?

-rw-r--r-- 1 root root 10 May 14 00:02 ping.txt

That’s old. So there’s not a new acme file in there. I think we have set the wrong webrootauth in our certbot flag.

$ ~/.local/share/letsencrypt/bin/certbot-auto certonly --webroot -w /etc/letsencrypt/webrootauth -d usfoodcoop.org -d staging.usfoodcoop.org


 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/staging.usfoodcoop.org/fullchain.pem. Your
   cert will expire on 2016-11-24. To obtain a new or tweaked version
   of this certificate in the future, simply run certbot-auto again.
   To non-interactively renew *all* of your certificates, run
   "certbot-auto renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

It seems the old certificate is still being served. Where are these old .pem files?

$ sudo find / -name "fullchain.pem"

Hmmm. I think some of these old directories may be creating problems.

$ sudo mv /etc/letsencrypt /etc/oldletsencrypt

Created a new directory:

mkdir -p /etc/letsencrypt/webrootauth

Ran the above cert command and now there are other directories:

drwx------ 3 root root 4096 Aug 26 16:22 accounts
drwx------ 3 root root 4096 Aug 26 16:26 archive
drwxr-xr-x 2 root root 4096 Aug 26 16:26 csr
drwx------ 2 root root 4096 Aug 26 16:26 keys
drwx------ 3 root root 4096 Aug 26 16:26 live
drwxr-xr-x 2 root root 4096 Aug 26 16:26 renewal
drwxr-xr-x 3 root root 4096 Aug 26 16:26 webrootauth

But Firefox is still getting the old certificate:

staging.usfoodcoop.org uses an invalid security certificate. The certificate expired on August 12, 2016 at 9:23 AM. The current time is August 26, 2016 at 6:32 PM. Error code: SEC_ERROR_EXPIRED_CERTIFICATE


Had forgotten to restart nginx: sudo service nginx restart. FAILED.

:No such file or directory:fopen('/etc/letsencrypt/live/staging.usfoodcoop.org/fullchain.pem','r')

Had to update the config file at /etc/nginx/sites-enabled/openfoodnetwork and remove staging. from the ssl_certificate and ssl_certificate_key paths. Working now.