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"
/root/.local/share/letsencrypt
/root/.local/share/letsencrypt/lib/python2.7/site-packages/letsencrypt
/root/.local/share/letsencrypt/bin/letsencrypt
/var/log/letsencrypt
/var/lib/letsencrypt
/home/michael/.local/share/letsencrypt
/home/michael/.local/share/letsencrypt/lib/python2.7/site-packages/letsencrypt
/home/michael/.local/share/letsencrypt/bin/letsencrypt
/opt/letsencrypt
/opt/letsencrypt/letsencrypt
/opt/letsencrypt/letsencrypt/letsencrypt
/etc/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
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.4 LTS"
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.)
IMPORTANT NOTES:
- 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
And
| 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?
Yes.
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"
/etc/letsencrypt/webrootauth/.well-known/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
Yay!
IMPORTANT NOTES:
- 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"
/root/.local/share/letsencrypt/lib/python2.7/site-packages/certbot/tests/testdata/live/sample-renewal/fullchain.pem
/home/michael/.local/share/letsencrypt/lib/python2.7/site-packages/certbot/tests/testdata/live/sample-renewal/fullchain.pem
/opt/letsencrypt/certbot/tests/testdata/live/sample-renewal/fullchain.pem
/etc/letsencrypt/live/staging.usfoodcoop.org/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
Duh!
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.