Skip to content

Instantly share code, notes, and snippets.

@nelsonenzo
Created February 15, 2018 21:06
Show Gist options
  • Star 3 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save nelsonenzo/35a95107cee1a57e7ac4178c526b1b00 to your computer and use it in GitHub Desktop.
Save nelsonenzo/35a95107cee1a57e7ac4178c526b1b00 to your computer and use it in GitHub Desktop.
Generate letsencrypt SSL certificates using acme.sh and Route53

letsencrypt + route53

what will you learn?

How to use letsencrypt to generate ssl certificates and keys locally for any domain you own, using DNS entries for domain ownership validation.

requirements

  • aws keys with rights to read/write AWS Route53 for the domain in question
  • bash

##why this method, not the default "certbot" method?

Certbot technically has the lowest number of "requiremets" to generate certificates, but in todays modern world of architecture, it's not very practical. Certbot needs to serve "proof of domain ownership" file on port 80 at the dns ip the domain resolves to. This is troublesome, at the least, if you already have an application running on that server listening on port 80. If you have a distributed system with many servers behind the domain, it's worse than troublesome, it just wouldn't work.

What are the alternatives?

Pleasantly, there is a myriad of alternatives to certbot actually. You can find them here: https://letsencrypt.org/docs/client-options/

Which one to chose?

There are almost so many options, it becomese daunting to make a selection. I chose one that jumped out at me because it's written purely in bash, acme.sh. If your system can run a shell script, it can use this method. acme.sh also has a nice feature that it can validate your domain using a dns txt entry, which is typically how sys admins validate ownership of certs without having to disrupt running systems at all. If I purchased a cert through namecheap, this is how I would validate ownership of the domain. Brilliantly, acme.sh integrates with ~50 dns providers via thier api, including AWS Route53.

You can find the docs for how to use all of the dns api integrations of acme.sh here: https://github.com/Neilpang/acme.sh/tree/master/dnsapi#10-use-amazon-route53-domain-api

Without further adoo, lets encrypt ;)

Install instructions here https://github.com/Neilpang/acme.sh#1-how-to-install. It's as simple as:

curl https://get.acme.sh | sh

Once installed:

 export  AWS_ACCESS_KEY_ID=xxx
 export  AWS_SECRET_ACCESS_KEY=yyy

acme.sh --issue --dns dns_aws -d myexample.com -d www.myexample.com
## after a couple minutes it will output 4 files:
[Thu Feb  8 01:12:40 UTC 2018] Your cert is in  /home/ubuntu/.acme.sh/myexample.com/myexample.com.cer 
[Thu Feb  8 01:12:40 UTC 2018] Your cert key is in  /home/ubuntu/.acme.sh/myexample.com/myexample.com.key 
[Thu Feb  8 01:12:40 UTC 2018] The intermediate CA cert is in  /home/ubuntu/.acme.sh/myexample.com/ca.cer 
[Thu Feb  8 01:12:40 UTC 2018] And the full chain certs is there:  /home/ubuntu/.acme.sh/myexample.com/fullchain.cer 
The files of interest, primarily, are:

## the private key:
myexample.com.key

## the *chained* certificate
## while technically, the un-chained certificate often works, 
## many systems and browsers really want the full chain, 
## which proves that the letsencrypt certificate provider is indeed a valid cert provider upstream.
fullchain.cer 

validation

From here: https://www.sslshopper.com/article-most-common-openssl-commands.html

openssl rsa -in /home/ubuntu/.acme.sh/myexample.com/myexample.com.key  -check
openssl x509 -in /home/ubuntu/.acme.sh/myexample.com/fullchain.cer -text -noout
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment