If, like me, you don't want it to modify your configs files for you, and don't want to turn off the webserver everytime you renew certificates, use Webroot mode.
I updated my guide to setup Nginx + Ubuntu 16.04 + Let's encrypt (Nginx, IPv6, HTTP/2, and A+ rating at SLL Labs):
You can now get those instructions in concise form from the simple widget at https://certbot.eff.org.
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)
I used acme-tiny to secure several domains on my server, including automated renewal via cron, running as an unprivileged user that only has access to the CSR, the ACME auth key, and the directory /.well-known/acme maps to, but not the server private key. Took about an hour to secure three domains, most of which was convincing OpenSSL to produce the right three CSRs with SubjectAltName set (to cover the "www." variants so I can securely redirect them).
On AWS, you can also use https://github.com/alex/letsencrypt-aws - it works great if you're using both Route 53 and ELB. It uses the dns-01 challenge, which is out-of-band - it adds a text record to your DNS instead of needing to inject content into your server. I prefer that approach.
Only free if you have Elastic Load Balancer running for each domain. If you're hosting a dozen micro-sites on a box, the Certificate Manager path gets a little expensive
/me looks at his February bill and remembers the lesson all too well
Considering alex/letsencrypt-aws is also designed specifically for ELB, I think the comparison to ACM is appropriate.
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, right now ACM only works with CloudFront distributions or with ELBs in us-east-1. If you're running ELBs in another region, you can't use ACM on them.
letsencrypt-aws looks to be designed specifically to automate updating ELB certificates, and doesn't seem quite as suitable for provisioning certificates for standalone EC2 instances, for example.
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.
I also wrote a tool to automate this, using Ruby. Rather than an all-in-one magic solution, it is just a set of tools intended to be easy to modify to fit in to your existing workflow/app.
ACME defines an authorization object, which is created for every FQDN on a certificate. Part of this object is a randomized token. A valid authz object (i.e. one for which you have solved a challenge by, say, creating a TXT record with the token) allows you to request (any number of) certificates for the FQDN until the expiration date of the object is reached (10 months in case of Let's Encrypt).
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.
Ah, thanks. So this is not really that useful, since I can't keep reusing the same object. I guess I'll have to stick with the webroot method, too bad.
I am yet to try this, but I never liked the idea that it automatically edits my nginx config. Seeing that it's in Jesse Backports makes me more confident that it does something sane, though. However the Jesse instructions don't say anything about it. Is it that you get asked questions about Nginx when you say "letsencrypt certonly"? Also strange that it doesn't even seem to require sudo to run.
You can use the --standalone option to get just the certificate files, so you can keep your nginx config files as-is however you configured them and just update the privkey.pem and fullchain.pem files wherever your nginx config points to look for them. And the --standalone option actually requires sudo but I guess that's because it puts the certs in /etc/letsencrypt~.
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.
That's how it should work but even --standalone still inspects your web server config and will refuse to run if any part of that goes wrong. For example, if you have multiple Apache VirtualHosts in the same file[1] (e.g. a port 80 redirect to the HTTPS site in the same file) any attempt to renew a certificate will fail with an error.
My best guess is that you have previously issued a certificate using the apache plugin on that system, and the renewal config file for that certificate is still there.
$ 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)
You don't need --standalone to get only certificate files, by the way. You can also use certonly with --webroot and it'll work just fine. The certonly is the key part.
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.
There's something I find really off-putting about a tool that's going to be managing private keys having dependencies that point to the master branch of various third party git repositories.
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.
It being written in Go doesn't make "just pull the latest code from master from my dependencies at build time" a good thing. They should use vendoring and pin tagged releases.
It's the fastest and most stable web server I've ever used. It does crash whenever something is misconfigured, but that is usually my fault. It works wonders and never crashes unless I cause it to.
I've read somewhere that it won't work if there are multiple VirtualHost blocks in the same file. Allegedly if you separate each vhost config into it's own file, it will start working. YMMV.
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.
It occurred to me that this should probably be integrated with ansible for bringing up servers, and apparently I'm not the first to think so, I found a couple of project, and this one appears to fit the bill quite nicely:
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)?
It's interesting OVH just notified all their webhosting customers (I assume VPS & shared hosting) they encrypted all 1.5 million account control panels via Let's Encrypt
Correct me if I'm wrong because I really hope I'm wrong. Doesn't no question asked certificates completely undermine certificates and make man in the middle attacks remarkably simple on 'secure' sites?
I played with Caddy a little and had an SSL for a domain I already have one for without even asking for one.
You already proved that you have access to it. Why is that no question asked?
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.
In production assuming you're using HTTP validation you're going to end up routing the well-known ACME URL requests over to your ACME client. If you have a load balancer in front you can handle it there and keep IIS totally out of it. But you could also handle the route in IIS and make a back-end request to the ACME process in your code.
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.
The Azure situation is currently a bit of a debacle. Let's Encrypt wasn't designed with particular care toward the Windows ecosystem (or PaaS providers in general), but this guy isn't helping much either.
No, simp_le does not do the exact same thing. simp_le will also generate certs and get them signed, but certbot will install them in apache for you. certbot is for people who don't know or care how to install a TLS cert and just want the thing to go green
I haven't, but there are other clients that work nearly as well. I use a modified version of letsencrypt-nosudo [1], and setup.sh should do everything you need.
I'm having problems using letsencrypt with domains with multiple dns A-records (round robin). What would be the standard way to issue certificates for a cluster?
Eh, I wouldn't call it "similar functionality", don't get me wrong I use and quite like Caddy but that's like saying a hammer offers similar functionality to fully stocked workbench. This is a tool that only does certs, caddy does much much more.
This example script assumes that the server has a running webserver, either Apache or Nginx. Since it doesn't use a package install for Certbot, this script should work on most Linux distributions. It installs Certbot, obtains the certificate, and sets up the cron task for renewal.
---
#!/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}"
A couple of suggestions based on recent (0.5.0+) Certbot features:
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.
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.
Yes certbot-auto should work on Raspbian 7 but note you'll need a large swap file enabled in order for it to succeed at building the recent version of python-cryptography that it depends on:
Let's Encrypt does this by checking their records and determining whether a recent enough certificate was issued for your domains. They don't monitor your site to check the actual expiration dates of the certificates you use in production. This could be an issue if you run into a problem where you get a new certificate for your domains, but fail to deploy it (or something similar).
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.