SSL Certificates in Development

Recently I've been working a lot with multiple multi-app servers and their SSL certificates. Once you get more than two or three environments up and running it can get a little tricky finding and wrangling certificates from each instance. Thankfully I've found a few super tips that have been a big time saver when it comes to solving issues with certs when your working in less than ideal system setups.

Tip 1: Find and Destroy

I find there are certain times when the dev certs on my PC are just out of hand. The first step to cleaning them up is by removing the old ones. The certificates snap-in for the Microsoft Management Console is a decent tool if you want to look at a specific cert. Simply select the folder on the left and you can easily find the certs you need. But when you're looking for one or more possible certs, then try the following Powershell snippet:

ls Cert:\ -Recurse | where { $_.Issuer -like "*Jim Buck*" }

This snippet will recursively search all installed certificates but only display those that match the criteria (in this case the Issuer must contain Jim Buck. You can filter on any of the following fields:

1. Subject - text (might be generic or the same as issuer)
2. Issuer - text (typically quite reliable to filter on)
3. Thumbprint - hash (unique per certificate)
4. FriendlyName - string (sometimes empty)
5. NotBefore - Datetime
6. NotAfter - Datetime
7. Extensions - List of Oid objects (they have FriendlyName and Value properties).

Early in the development process you might be adding quite a few certs to your store. Run the same command but pipe it to the rm command and you can easily remove all of the pesky old certificates:

ls Cert:\ -Recurse | where { $_.Issuer -like "*Jim Buck*" } | rm

I don't recommend clearing out certs too often though. Ideally you only have to do it before installing the "good" certs. Once you have a nice clean cert store adding new certs that are known to be good should be just fine to have installed.

Tip 2: Trust the CA Root certificate

Our application relies on an in-house data service. During the install of this service, it generates a CA Root certificate and an end-user certificate for the server's FQDN (signed by the generated CA Root). We can't modify the install logic of the service, so we have to make due with the certs it produces. The best approach is to simply download the CA Root cert from each instance and install it in the Trusted Root of our Local Machine.

I typically select "Local Machine" (just in case) and manually select "Trusted Root Certification Authorities".

Don't be fooled, certs of the same name (but different thumbprint) can be installed side-by-side. Just remember to restart your browser/client apps so they pick up the new certificates.

Tip 3: Use a shared CA Root certificate

By far the best approach is to simply make your certificate generation use a shared CA Root. This would allow a project or even a whole department to use one common root cert that signs all server-specific development/test certs. No more downloading of certs to trust, no more hacks to ignore cert errors. No more rummaging through each environment trying to update all references of which cert to use. Just one shared cert that keeps developers, testers, managers, and product owners safe and secure.

I am currently finalizing a script to help create (dev-only) CA Root and SSL certs. Once I can test it a bit more and get the usage as simple as possible I will write a special article all about it.