diff --git a/letsencrypt/README.md b/letsencrypt/README.md
new file mode 100644
index 0000000..23a6999
--- /dev/null
+++ b/letsencrypt/README.md
@@ -0,0 +1,40 @@
+# Lets Encrypt
+
+[Let's Encrypt](https://letsencrypt.org/) is an [ISRG](https://en.wikipedia.org/wiki/Internet_Security_Research_Group) project to provide free TLS certificates in an automated fashion.
+
+Let's Encrypt distributes a script for automating the CSR creation, domain validation, and certification acquisition process for acquiring TLS certificates. This script, `certbot` can be run from systems intended to be secured and automate the installation into common HTTP servers; or work in more passive modes simply for certificate acquisition.
+
+## 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).
+
+### 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/`
+- 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)
+
+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'`
+(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`
+
+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)}`
+
+5. Combine the certificate chain and the private key. HAProxy requires a full 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`
+
+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.