From 7dd84465235852f2a17017a07fed53fe1c6ff894 Mon Sep 17 00:00:00 2001 From: Daniel Wright Date: Fri, 9 Oct 2015 13:34:25 -0400 Subject: [PATCH 1/4] DevOps Guide to SSL Certificate Stubs out a guide for various SSL certificate concerns, as well as a 'devops' directory to house it. --- content/departments/devops/ssl-certificates.mdown | 1 + 1 file changed, 1 insertion(+) create mode 100644 content/departments/devops/ssl-certificates.mdown diff --git a/content/departments/devops/ssl-certificates.mdown b/content/departments/devops/ssl-certificates.mdown new file mode 100644 index 0000000..cf528e9 --- /dev/null +++ b/content/departments/devops/ssl-certificates.mdown @@ -0,0 +1 @@ +# SSL Certificates From 0ed7132f2541e53c159084869b124f4a029636b2 Mon Sep 17 00:00:00 2001 From: Daniel Wright Date: Mon, 12 Oct 2015 14:56:11 -0400 Subject: [PATCH 2/4] Fleshing Out of SSL Certificate How-To --- .../what-we-do/2015-10-09-ssl-certificates.md | 65 +++++++++++++++++++ .../departments/devops/ssl-certificates.mdown | 1 - 2 files changed, 65 insertions(+), 1 deletion(-) create mode 100644 _posts/what-we-do/2015-10-09-ssl-certificates.md delete mode 100644 content/departments/devops/ssl-certificates.mdown diff --git a/_posts/what-we-do/2015-10-09-ssl-certificates.md b/_posts/what-we-do/2015-10-09-ssl-certificates.md new file mode 100644 index 0000000..f87571c --- /dev/null +++ b/_posts/what-we-do/2015-10-09-ssl-certificates.md @@ -0,0 +1,65 @@ +--- +layout: post +title: "SSL Certificates" +published: true +tags: devops ssl +categories: what-we-do devops +order: 6 +--- + +# SSL Certificates + +Almost every site we build should be accessed over an encrypted connection. To establish such a connection, your server will need to have an SSL certificate installed. The following guide will run through the steps to obtain and secure a domain with an SSL certificate. + +## Generating a Certificate Signing Request + +This step is only necessary if you're securing a domain for the first time, or if the existing certificate's private key is unavailable. + +Open a terminal, and run the following command: + +```shell +~/ $ openssl req -new -newkey rsa:2048 -nodes -keyout www_domain_name_com.key -out www_domain_name_com.csr +``` + +The OpenSSL command-line tool will prompt you for several pieces of information. The important ones, which will need to match the organization on whose behalf the certificate is to be issued are: + +- Country Name, the two-letter abbreviation for the organization's country (e.g. `CA`); +- State or Province, the full name of the state/province in which the organization is based (e.g. `Quebec`); +- Common Name, the fully-qualified domain-name to which the certificate will be associated (e.g. `www.godynamo.com`); +- Email Address, the administrative email address for the organization (e.g. `webmaster@godynamo.com`). + +You may provide the other details, or leave them blank. + +This will generate two files: the certificate signing request (`www_domain_name_com.csr`) and the private key (`www_domain_name_com.key`). + +The certificate signing request (CSR) contains the identifying information collected above, as well as the public key. Together, they constitute the "application" we'll make to a certificate authority. + +The private key is the linchpin of the cryptographic security of the certificate, and should never exist anywhere except the server(s) the certificate will be securing. In practice, it's a real pain-in-the-ass to have to reissue a certificate because the private key got mislaid, so we store backups of private keys in Google Drive. + +## Buying a Certificate + +Now that you have a CSR, it's time to apply for a certificate. This is way crazier than you'd imagine, because there are a _lot_ of different kinds of certificates. You can cover one, or multiple, domains; you can choose from among many different certificate authorities; you can choose between high- and low-assurance certificates. This creates a non-trivial matrix of certificate vendors to choose from. + +### SSLs.com + +By and large, though, our SSL certificates are managed with SSLs.com, and we choose between QuickSSL Premium and RapidSSL Wildcard. The choice becomes pretty easy: if you need to secure subdomains, choose a RapidSSL Wildcard; otherwise, choose QuickSSL Premium. + +Once you've paid for the certificate, the process of _issuing_ the certificate begins. Depending on the level of assurance offered by the CA, the first step may be waiting for a confirmation email to be sent to the administrative email you provided in the CSR; or it may involve adding a DNS record or verification file on the server to which the domain points. + +Once the verification has been completed, though, you will be provided with two files: the PEM-format certificate file (usually `.crt`); and the intermediate and root certificates (`.ca-bundle`), which complete the certificate chain and ensure your certificate is trusted. (You might also have a `.p7b` file, but you can probably ignore this one.) + +**TBD: screen-by-screen cert issuing process?** + +### Let's Encrypt (TBD) +The [Let's Encrypt][https://letsencrypt.org/] is going to shake things up toward the end of 2015. It's in the final stages of approval as a new Certificate Authority who will issue SSL certificates for free. It may obsolesce SSLs.com. + +## Installing the SSL Certificate + +At this point, you've got your private key (.key) stashed away, and you've now got a certificate file (.crt) and a set of intermediate certificates (.ca-bundle). Now you have to install them on your server(s)! + +### Cloud 66 + +### Heroku + +### Load Balancers +SSL termination shenanigans. diff --git a/content/departments/devops/ssl-certificates.mdown b/content/departments/devops/ssl-certificates.mdown deleted file mode 100644 index cf528e9..0000000 --- a/content/departments/devops/ssl-certificates.mdown +++ /dev/null @@ -1 +0,0 @@ -# SSL Certificates From 61c9a3f36f0b28fa8ae982e12d600ce69056562c Mon Sep 17 00:00:00 2001 From: Daniel Wright Date: Mon, 12 Oct 2015 14:56:37 -0400 Subject: [PATCH 3/4] Convenience Shell Scripts This commit adds simple shell scripts to make bootstrapping the project, and compiling/serving the project files more convenient and consistent. --- script/bootstrap | 8 ++++++++ script/server | 6 ++++++ 2 files changed, 14 insertions(+) create mode 100755 script/bootstrap create mode 100755 script/server diff --git a/script/bootstrap b/script/bootstrap new file mode 100755 index 0000000..a9dc154 --- /dev/null +++ b/script/bootstrap @@ -0,0 +1,8 @@ +#!/bin/sh +# Make sure local dependencies are met. + +cd "$(dirname $0)"/.. + +bundle install && \ + npm install && \ + bower install diff --git a/script/server b/script/server new file mode 100755 index 0000000..fde7d1c --- /dev/null +++ b/script/server @@ -0,0 +1,6 @@ +#!/bin/sh +# Start the development server. + +cd $(dirname "$0")/.. + +bundle exec gulp serve From d4412418466fecf3f4e40ae4467d2ed98b27ccf3 Mon Sep 17 00:00:00 2001 From: Daniel Wright Date: Mon, 12 Oct 2015 15:16:03 -0400 Subject: [PATCH 4/4] Further Progress on SSL Certificates Guide This commit adds installation steps for Cloud66 and Heroku, and stubs for load-balancers and AWS services like S3 and CloudFront. --- .../what-we-do/2015-10-09-ssl-certificates.md | 21 ++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/_posts/what-we-do/2015-10-09-ssl-certificates.md b/_posts/what-we-do/2015-10-09-ssl-certificates.md index f87571c..1232ad0 100644 --- a/_posts/what-we-do/2015-10-09-ssl-certificates.md +++ b/_posts/what-we-do/2015-10-09-ssl-certificates.md @@ -59,7 +59,26 @@ At this point, you've got your private key (.key) stashed away, and you've now g ### Cloud 66 +To use your shiny new SSL certificate on Cloud66, you'll have to provision the SSL add-in to the corresponding stack. When prompted, enter the contents of the `.key` file in in the "Certificate Key" field, the contents of the `.crt` file in the "SSL Certificate" field, and the contents of the `.ca-bundle` file in the "Intermediate Certificate" field. + ### Heroku +Installing your SSL certificate on Heroku is a bit more complicated. The first step is to provision an SSL endpoint via the Heroku Toolbelt, using the following template: + +```shell +~/ $ heroku certs:add domain.crt domain.key domain.ca-bundle —app my-app-1234 +``` + +This will assign an endpoint URL along the lines of `example-1234.herokussl.com`, but visiting this URL will not reveal your website—indeed, your browser should emit a scary mismatched-certificate warning. This is expected, and indeed desireable: it demonstrates that Heroku is attempting to use your SSL certificate to establish the connection with your browser. + +To complete the setup, you'll need to add a couple DNS records. For the root domain, add an `ALIAS` or `ANAME` record with `example-1234.herokussl.com` as the target. For a subdomain, like `www.`, add a `CNAME` record. + +For more information on configuring DNS records, see the TBD guide to [[DNSMadeEasy]] (TBD). + ### Load Balancers -SSL termination shenanigans. + +To be added. + +### Amazon S3 & CloudFront + +To be added.