diff --git a/letsencrypt/README.md b/letsencrypt/README.md index 23a6999..a9333b5 100644 --- a/letsencrypt/README.md +++ b/letsencrypt/README.md @@ -6,35 +6,61 @@ Let's Encrypt distributes a script for automating the CSR creation, domain valid ## Using Let's Encrypt at WIT -Currently all SSL/TLS traffic to WIT services is terminated on roberto.wit.com via HAProxy. The `certbot` script is present on roberto and can be used in the following manner to acquire additional certificates, or to upgrade the existing *.services.wit.com certificate to include more domains. WIT uses `certbot` in `certonly` and `standalone` mode; this means that we're only using `certbot` to acquire the certificate, not install it and also means that verification will take place using certbot's standalone web server (proxied via HAProxy). +Currently all SSL/TLS traffic to WIT services is terminated on roberto.wit.com via HAProxy. The `certbot` script is present on roberto and can be used in the following manner to acquire additional certificates, or to upgrade the existing *.services.wit.com certificate to include more domains. WIT uses `certbot` in `certonly` and `standalone` mode; this means that we're only using `certbot` to acquire the certificate, not install it. It also means that verification will take place using certbot's standalone web server (proxied via HAProxy). ### Adding Domains to the *.services.wit.com Cert Assumptions: - HAProxy's config still uses the certificate located in `/etc/haproxy/certs/git.services.wit.com.pem` -- HAProxy is still configured to pass traffic coming into tcp/80 to the `letsencrypt-backend` when it matches `path_beg /.well-known/acme-challenge/` +- HAProxy is still configured to pass 80/tcp traffic matching `path_beg /.well-known/acme-challenge/` to the `letsencrypt-backend` - Traffic for the new domain will be terminated by HAProxy on roberto.wit.com -- Certificate expiry warnings should still be mailed to `adam@wit.com` (see the `--email` flag in the `certbot` command) + +To update the certificate modify the list of domain arguments (`-d foo.com`) below and use the following process: 1. Acquire the current list of domains the certificate is responsible for: - `openssl x509 -in /etc/haproxy/certs/git.services.wit.com.pem -noout -text | grep DNS: | sed -e 's/DNS:/ -d /g' -e 's/, //g'` +``` +openssl x509 -in /etc/haproxy/certs/git.services.wit.com.pem -noout -text \ + | grep DNS: \ + | sed -e 's/^\s*//' -e 's/DNS:/ -d /g' -e 's/, / \\\n/g' +``` + (this command spits out a list delimeted by ` -d` as these will be passed as arguments to `certbot` 2. Visually inspect the list to ensure the list looks correct. (Consider comparing to the certificate for an existing *.services.wit.com) 3. Run certbot, naming the **git.services.wit.com** cert as the one to be updated, and providing the **entire list of domains the cert should be valid for** - `certbot certonly --standalone --cert-name git.services.wit.com -d git.services.wit.com -d chat.services.wit.com -d dashboard.services.wit.com -d git.wit.com -d k8s-dashboard-afrank.services.wit.com -d mirrors.services.wit.com -d mirrors.wit.com -d owncloud.services.wit.com -d registry.services.wit.com -d wordpress.services.wit.com -d wekan.services.wit.com --agree-tos --email afrank@wit.com --http-01-port=54321 --preferred-challenges http` +``` +certbot certonly \ + --standalone \ + --cert-name git.services.wit.com \ + + + --agree-tos \ + --email afrank@wit.com \ + --http-01-port=54321 \ + --preferred-challenges http +``` -At this point you should see certbot making a number of challenges (doing domain ownership verification), and then a "**Congratulations!**" message telling you the certs have been updated. + At this point you should see certbot making a number of challenges (doing domain ownership verification), and then a "**Congratulations!**" message telling you the certs have been updated. -4. Backup the current certificate: `cp /etc/haproxy/certs/git.services.wit.com{,.bak$(date +%s)}` +4. Backup the current certificate: +``` +cp /etc/haproxy/certs/git.services.wit.com{,.bak.$(date +%s)} +``` -5. Combine the certificate chain and the private key. HAProxy requires a full chain+key for its SSL configuration: +5. Combine the certificate chain and the private key. HAProxy requires a full certificate chain+key for its SSL configuration: -`cat /etc/letsencrypt/live/git.services.wit.com/fullchain.pem /etc/letsencrypt/live/git.services.wit.com/privkey.pem > /etc/haproxy/certs/git.services.wit.com.pem` +``` +cat /etc/letsencrypt/live/git.services.wit.com/fullchain.pem \ + /etc/letsencrypt/live/git.services.wit.com/privkey.pem \ + > /etc/haproxy/certs/git.services.wit.com.pem` +``` -6. Reload HAproxy `service haproxy reload` +6. Reload HAproxy +``` +service haproxy reload +``` -7. Test. Test both that your new service is accepting SSL connections, as well as existing services **remain** accepting SSL connections. +7. Test both that your new service is accepting SSL connections, as well as existing services **remain** accepting SSL connections.