CardonTEC: Saving some cash - (Multi domain wildcard certificates)

Passion

I love to save money. It's best when I save my own money, but saving my company money is great too. It's part of why I love my job. As a Develop Happiness Engineer, my job is to make developers lives easier, so they can be more productive, and so that we can hire fewer of them to do the same great work. Really, my job boils down to increasing productivity, reducing server count, and keeping everything repeatable and audit-able.

Certificates

One of the necessary evil costs of running a professional website is encrypting traffic. When you're a healthcare company, this becomes even more critical. After all, this is pretty sensitive data. But certificates are not free. What's worse, I discovered yesterday that even the expensive ones only cover one level of sub-domains.

You see, I was reviewing our URL structure, and realized it was ugly. We had things like myapp-staging.mydomain.com in one place, and things like staging-someapp.mydomain.com in others. To make it worse, our route 53 hosted zone had become way too big, and it was getting hard to manage. So I decided it was time to cleanup the hierarchy and use subdomains to provide some structure to our URLs.

The Problem

Well, we have a wildcard domain cert through a major certificate provider. It applies to *.mydomain.com. When I went to create www.develop.mydomain.com I discovered that our cert was not valid for it. Yep, it only covers one level of subdomain. So my grand plan was going to cost us a couple thousand dollars by the time I covered all 7+ subdomains we needed. Lucky for me, only one of our domains is actually used by external customers. Everything else is internal to our system, or accessed by our own employees.

Self-signed Certificates to the Rescue?

So that means we can use self-signed certs, right? Well, yes, but how many of them? And how to distribute them? Yuk. If only I could get ONE certificate that covered ALL of my domains and subdomains across ALL internal infrastructure.

A Better Way

Well, it turns out you can. You just need to create a certificate with Subject Alternative Names. I found a blog post on self signed SAN certs that did a pretty good job. I just had to clean it up a little and elaborate by adding wildcard SANs to it. And without further ado, here is the process.

Creating a multi-domain wildcard certificate

Cautions

First, a quick caution. When you include ANY SANs in a certificate, you must include ALL of them. That is, the CN in your cert is ignored if you have even one SAN listed. So be sure to include your base domain in your san list.

The Extensions File

You must have a file that declares your certificate extensions. You can do this in your openssl.cnf file, or you can do it (as I do) in a standalone file.

extensions.cnf

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = mydomain.com
DNS.2 = *.mydomain.com
DNS.3 = myotherdomain.com
DNS.4 = *.myotherdomain.com
DNS.5 = *.mysubdomain.mydomain.com

Generate the certificate

# First create a key file (you'll need to enter your password 2X
openssl genrsa -des3 -out mykey.key 2048

# Next convert it to a passwordless key (remember that password?)
openssl rsa -in mykey.key -out mykey.rsa

# Now you need to create a signing request
# This requires you to enter a bunch of info
# I include:
# Country Name
# State
# City
# Organization Name
# Email Address
# But leave blank the OU, CN, and Password
openssl req -new -key mykey.rsa -out mykey.csr

# Finally, we generate the actual certificate
openssl x509 -req -extensions v3_req -days 365 -in mykey.csr -signkey mykey.rsa -out mykey.crt -extfile extensions.cnf

And that's it, you now have a certificate you can use to secure any domain you had listed in that extensions.cnf file.

Good luck!

CardonTEC

Friday, October 10, 2014

Saving some cash - (Multi domain wildcard certificates)