CertBot: Automatically enable HTTPS on your website with Let's Encrypt certs
certbot.eff.org
certbot.eff.org
I updated my guide to setup Nginx + Ubuntu 16.04 + Let's encrypt (Nginx, IPv6, HTTP/2, and A+ rating at SLL Labs):
https://gist.github.com/cecilemuller/a26737699a7e70a7093d4dc...
I hope it helps those that hesitate to use Let's encrypt.
Let us know if there are any tweaks you'd like to see made to them (or send a PR to https://github.com/certbot/website, the instructions are in _scripts/instruction-widget)
/me looks at his February bill and remembers the lesson all too well
From what I can tell, the only reasons to use alex/letsencrypt-aws (IAM certificates) instead of AWS Certificate Manager are if you're either 1, provisioning ELBs in a region other than us-east-1 and unable to wait for Amazon to roll out ACM to other regions; or 2, subsequently applying the same certificate to other resources in addition to ELB+CloudFront (e.g., a standalone EC2 instance running nginx or apache).
Unfortunately it looks as though letsencrypt-aws won't either.
I've had good results using https://github.com/sorah/acmesmith which also uses the dns-01 challenge via Route53, but saves certificates to an S3 bucket that can be fetched from any EC2 instance granted the proper permissions.
So basically you can get up to 13 months worth of certificates out of one token/solved challenge. That being said, none of the clients I'm aware of currently reuse authorizations - they create a new one during renewal, which would result in a new token.
Caution though, the file paths you get after obtaining the certificates are actually relative symlinks for some reason so if you just copy these symlinks over they will most likely not point to the correct path so copy the original files instead.
In any case, thanks for the --standalone hint.
$ echo "BreakThisConfig" > /etc/apache2/sites-enabled/000-default.conf
$ ./certbot-auto --apache
2016-05-16 21:33:31,252:ERROR:certbot.le_util:Error while running apache2ctl configtest.
Action 'configtest' failed.
The Apache error log may have more information.
$ ./certbot-auto certonly --standalone -d example.com
- Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/example.com/fullchain.pem.
$ ./certbot-auto renew --force-renewal
Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/example.com/fullchain.pem (success)One thing I hope they make a little clearer is how to delegate cipher suite selection to certbot. I saw some discussion about making options-ssl-nginx.conf use, say, one of Mozilla's server-side configurations (whichever one you've configured). That way you could include options-ssl-nginx.conf and it'd auto-update over time.
It also unconditionally tries to listen on ports 80, 402, 443, 552 and 4402 whenever it completes a challenge, even if you have absolutely no intention of using any of these verification methods, so there's a lot of moving parts most of which you don't want.
I made a FreeBSD port, but thought twice about submitting it: https://github.com/Freaky/ports/tree/master/security/acmetoo...
It is weird that it attempts to listen on all of those ports, though.
using: https://github.com/JrCs/docker-letsencrypt-nginx-proxy-compa...
This dockerfile/repo made this incredibly easy to scale with nginx/ssl/docker.
Simply add the desired domain name as environment variable when starting your container, and letsencrypt will register your cert, and re-register it at an interval.
I haven't yet tried the other methods posted in this thread, but not sure I will want to, since this was so easy.
https://github.com/thefinn93/ansible-letsencrypt
Must say I'm not a fan of web first, then fallback (I mean if stand-alone works, then just use that - because that should work for certs used for eg smtp, imaps etc)?
I played with Caddy a little and had an SSL for a domain I already have one for without even asking for one.
Is this not a problem?
Normal DV certs are either "add a CNAME, upload a uniquely named html / txt file, or click a link in an email" -- you've already done one of those (automatically in caddy)
Lets Encrypt asks one question without you having to deal with it - the question where you prove you own the domain by placing a file in the webroot. This is just as much proof as the email verification you get from existing strategies. Except it involves less headache, because you aren't ordering from namecheap, then getting emails from @comodossl.com that fail SPF checks asking you to click links.
Once the well-known URL on your domain is setup to route to the ACME client, then you probably want a command line client (I like 'lego') scripted to run periodically and check which certs need refreshing. The last step is getting to certs back into IIS and bound to the specific site, which can be done in Powershell.
Overall it's fairly straightforward but will take hours to get it fully working and it does adds a few moving parts to your setup. I'd say not enough ROI if you need less than a dozen certs.
Certify is a Windows app which uses Let's Encrypt to provide free trusted SSL certificates for websites you control.
... I've got one of those up my sleeves for next year.
---
#!/bin/bash
#
# This sets up Let's Encrypt SSL certificates and automatic renewal
# using certbot: https://certbot.eff.org
#
# - Run this script as root.
# - A webserver must be up and running.
#
# Certificate files are placed into subdirectories under
# /etc/letsencrypt/live/*.
#
# Configuration must then be updated for the systems using the
# certificates.
#
# The certbot-auto program logs to /var/log/letsencrypt.
#
set -o nounset
set -o errexit
# May or may not have HOME set, and this drops stuff into ~/.local.
export HOME="/root"
export
PATH="${PATH}:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
# No package install yet.
wget https://dl.eff.org/certbot-auto
chmod a+x certbot-auto
mv certbot-auto /usr/local/bin
# Install the dependencies.
certbot-auto --noninteractive --os-packages-only
# Set up config file.
mkdir -p /etc/letsencrypt
cat > /etc/letsencrypt/cli.ini <<EOF
# Uncomment to use the staging/testing server - avoids rate limiting.
# server = https://acme-staging.api.letsencrypt.org/directory
# Use a 4096 bit RSA key instead of 2048.
rsa-key-size = 4096
# Set email and domains.
email = admin@example.com
domains = example.com, www.example.com
# Text interface.
text = True
# No prompts.
non-interactive = True
# Suppress the Terms of Service agreement interaction.
agree-tos = True
# Use the webroot authenticator.
authenticator = webroot
webroot-path = /var/www/html
EOF
# Obtain cert.
certbot-auto certonly
# Set up daily cron job.
CRON_SCRIPT="/etc/cron.daily/certbot-renew"
cat > "${CRON_SCRIPT}" <<EOF
#!/bin/bash
#
# Renew the Let's Encrypt certificate if it is time. It won't do anything if
# not.
#
# This reads the standard /etc/letsencrypt/cli.ini.
#
# May or may not have HOME set, and this drops stuff into ~/.local.
export HOME="/root"
# PATH is never what you want it it to be in cron.
export
PATH="\${PATH}:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
certbot-auto --no-self-upgrade certonly
# If the cert updated, we need to update the services using it. E.g.:
if service --status-all | grep -Fq 'apache2'; then
service apache2 reload
fi
if service --status-all | grep -Fq 'httpd'; then
service httpd reload
fi
if service --status-all | grep -Fq 'nginx'; then
service nginx reload
fi
EOF
chmod a+x "${CRON_SCRIPT}"
---openssl speed rsa2048 rsa4096
on your server for what is probably going to be a rude awakening. For a small, low-traffic site you might be able to manage but as traffic increases you are probably going to regret choosing 4096 bit certs unless you absolutely need them for a specific reason.
Will this work for multiple domains? If so, is it just a matter to add them to the "domains" variable?
If it is all the same webroot, then yes, add them all to the domains variable.
If different webroots you might need to use the command line, which lets you run
--w /x/y/z -d example1.com --w /a/b/c -d example2.com
in one command. I'm not sure how to make that work in the configuration file, though I'm sure there's a way.
1. You can now do certbot certonly --post-hook "service XYZ reload" to run something if and only if certs were obtained / renewed. Or if you use the renew verb, you can use --renew-hook to get a callback for each renewed cert individually. See certbot --help renew for details.
2. You can set "quiet = True" to minimize output from the client (but see https://github.com/certbot/certbot/issues/2990)
https://github.com/certbot/certbot/issues/1081
This is resolved by .deb packages; they're available in jessie-backports, but I'm not sure if/when those will ever make it to Raspberry Pi land.