- Updated:
- April 29, 2019
- Published:
- May 4, 2017
Web development is not magic; development environments are the secret sauce that make it look magical. The more closely your development environment matches production, the fewer problems you will have on deployment. Here at Workshop Digital I use Vagrant and VVV to spin up WordPress sites for building and testing. Sometimes it is helpful to have a development website that can operate over SSL. This can be a requirement if you are writing a feature that requires authenticating with a third-party. Think OAuth.
Chrome 58, released on April 20th, made a change that invalidated the installed certificates, and I started receiving security warnings. You can read more about why the change was made here and here. The gist is that Chrome was moved into compliance with RFC 2818 and no longer uses the commonName (CN) field for domain validation. Chrome, and other browsers, will now use the subjectAltName (SAN) fields for domain validation.
If you’ve stayed with me thus far, there is good news. There is a fairly easy fix. If you read the Chrome support thread, there is a flag you can set in Chrome to enable the old way of validation. That will work for a time. The more permanent answer requires a bit of command line work.
The following was tested on Trusty Ubuntu 14.04. Remember to replace the example info I provide with your own. Thank you to the authors of the below articles whom I used for reference.
Step 1: Write a new openssl configuration file
There is no method of defining x509 v3 extension SAN names without first writing a configuration file. Open up your favorite editor and generate a configuration file. Here’s what I have for my configuration.
Remember to change out the details to suit your own site. The important and new part of this configuration are the v3 extensions which contain your new SAN definitions.
Step 2: Generate a private key
You can skip this step if you already have a private key. To generate a new private key, use the command below.
$ openssl req -nodes -new -x509 -keyout workshopdigital.dev.key
This will ask you a few questions to create the Distinguished Name (DN) and will spit out a certificate block. You can safely ignore that, we will generate one in the next step.
Step 3: Generate a new CSR
We are going to use that new config file to make a new Certificate Signing Request. Since we’ve already provided all the needed info we won’t be prompted for it on screen.
$ openssl req -key workshopdigital.dev.key -new -out workshopdigital.dev.csr -config openssl.cnf
Step 4: Check the CSR contains the right info
$ openssl req -text -noout -verify -in workshopdigital.dev.csr
You should see a line that looks like this:
X509v3 Subject Alternative Name: DNS:workshopdigital.dev, DNS:www.workshopdigital.dev
If you don’t see the above double check your work and make sure you included the config file when generating the CSR.
Step 5: Generate a new certificate
$ openssl x509 -req -days 3650 \ -in workshopdigital.dev.csr \ -signkey workshopdigital.dev.key \ -out workshopdigital.dev.crt \ -extensions req_ext \ -extfile openssl.cnf
Step 6: Restart your web server
If you are using Vagrant on Ubuntu 14.04 the command will be:
$ sudo service nginx restart
Step 7: Copy your new certificate into Keychain
Since this is a self-signed certificate, Chrome is going to throw another error, even if you have done everything right so far. Copy your newly created certificate file into macOS Keychain. Open the certificate and click Trust. Set the trust to Always Trust. Restart Chrome and you should see a green bar and no more errors.
Leave a comment if you have any questions or thoughts about this process!
Leave a Reply