Letsencrypt Certbot on Amazon ec2 linux – LetsEncrypt Client Install – What a headache

At first glance, finding AWS’s exact documentation on how to get this working, may excite you. Until you find that you encounter the same error that you would get were you to follow certbot’s own official instructions for redhat. Recall that Amazon’s linux 2 is a variant of  redhat – and the instructions for redhat ‘should’ work. Except they don’t.

No matter what path you take (certbot’s instructions or aws’s own..), you will get stuck with the error below.

Sorry, I don't know how to bootstrap Certbot on your operating system!

Basic Installation Instructions for certbot on Redhat 

$ yum install python27-devel git

Install letsencrypt by cloning the github repository into /opt/letsencrypt

$ git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt$ /opt/letsencrypt/letsencrypt-auto --debug

When you reach this point, your install will fail with the error :

Sorry, I don't know how to bootstrap Certbot on your operating system!

EPEL and Amazon Linux

Certbot requires EPEL (extra packages for enterprise linux) to be installed and enabled. The trouble isn’t installing EPEL  or enabling it. The trouble is  – after enabling it – you will still be unable to use it to install anything meaningful (for e.g. installing Letsencrypt’s client certbot).

To work around this:
Step 1. Edit the file /opt/letsencrypt/certbot-auto to recognize your version of Linux:

• $ sudo vim /opt/letsencrypt/certbot-auto
• find this line in the file (likely near line nr 780):
  elif [ -f /etc/redhat-release ]; then
  and replace whole line with this:

elif [ -f /etc/redhat-release ] || grep 'cpe:.*:amazon_linux:2' /etc/os-release > /dev/null 2>&1; then

Your letsencrypt install on amazon linux ( or linux 2) should be successful at this point! Continue to make a request to an ACME server.

Making a request to an ACME server using certbot-auto

sudo /opt/letsencrypt/certbot-auto certonly --webroot -w /var/www/html -d example.com -d www.example.com

The Handshake Failed  Issue

Ordinarily, the root certificate of the ACME server should be present on your client (as part of it’s trust store). If this is not the case (as would be if you were testing with someone else’s ACME server), you will see a tls handshake failure error

remote error: tls: handshake failure

To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address. Additionally, please check that
you have an up-to-date TLS configuration that allows the server to
communicate with the Certbot client.

You have two options here.

Option 1 Obtain the public root certificate of the ACME server’s root domain – and place it in your OS’es trusted store. For redhat linux, this store would be one of the following:

/etc/pki/ca-trust/ and /usr/share/pki/ca-trust-source/

Option 2   Ignore the handshake failure – by using the flag below (no verify ssl on acme server’s certificate).

sudo /opt/letsencrypt/certbot-auto certonly --no-verify-ssl

The Challenge Failed  Issue

To prove that you are the owner of the domains (in our example – www.example.com and example.com), letsencrypt’s acme server (whoever you requested your cert from) will ask you to prove your ownership. This is done if the form of a challenge – an http challenge (most common) or a DNS challenge (less common).

The http challenge requires you to have a web server up and running.

The ACME server gives a token to your ACME client, and your ACME client puts a file on your web server at http://www.example.com/.well-known/acme-challenge/<TOKEN>. That file contains the token, plus a thumbprint of your account key.  Once the certbot client tells the acme server that the file is ready, the server tries retrieving it (potentially multiple times from multiple vantage points).  If the validation checks fail, you’ll have to try again with a new certificate.

To avoid getting  challenged, you can perform a –standalone request – this tells acme server to not bother validating your domains, as this is a standalone test.

sudo /opt/letsencrypt/certbot-auto certonly --standalone

Checking to see if certificate successfully created

Certificate files (cert.pem, chain.pem, fullchain.pem, and privkey.pem) are generated in an individual folder for each domain in /etc/letsencrypt/live/ (e.g. /etc/letsencrypt/live/_______.com/ )

• cert.pem: server certificate only.
• chain.pem: root and intermediate certificates only.
• fullchain.pem: combination of server, root and intermediate certificates (replaces cert.pem and chain.pem).
• privkey.pem: private key (do not share this with anyone!).

To Test Renewal

sudo /opt/letsencrypt/certbot-auto renew --allow-subset-of-names --dry-run

Deleting Existing Certificate

This will handle deletion from all the relevant folders

sudo /opt/letsencrypt/certbot-auto delete   --will prompt you for which certificates to delete

• /etc/letsencrypt/archive
• /etc/letsencrypt/live
• /etc/letsencrypt/renewal

Certbot Logs and Official Docs

Logs are stored in

/var/log/letsencrypt

Containerized Certbot Install

You will need the root certificate of docker hub (or whatever registry you are defaulting to) on your local OS (inside your trusted store). Without this, you will encounter ssl errors on executing the pull command. Once you have the certificate, you can pull certbot using this command (this will pull the image into your local registry).

docker pull certbot/certbot

Once pulled in, you can make a certificate request as follows (here certbot/certbot will pull from your local registry – since you already pulled in the image from the default remote registry)

sudo docker run -it --rm --name certbot \
            -v "/etc/letsencrypt:/etc/letsencrypt" \
            -v "/var/lib/letsencrypt:/var/lib/letsencrypt" \
            certbot/certbot certonly

Summary

I haven’t tried clients other than certbot (so, possibly those installs are less painful). However, certbot being the most popular client, it was worthwhile trying to get it working on an Amazon Linux ec2 instance.  Some issues you may encounter are the handshake failed issue and the challenge failed error. These have simple workarounds as described in this post.

One way to abstract away the OS dependencies is to run the containerized version of certbot. This is fairly foolproof – the only issue you might encounter is a missing root certificate from your docker hub registry.