Home > R&D > Using a “real” CA (such as Godaddy) generated SSL certificate locally

Using a “real” CA (such as Godaddy) generated SSL certificate locally

I recently got tired of going through all my local subdomains and approving the “invalid” certificate I had so that I can work locally every time I reopened chrome. Having bought a wildcard certificate for my production deployment (from Godaddy, but any would do), I knew it was only a couple of steps to get it into my project so that my local sub domains (e.g. local.tagzbox.com) would be considered “valid”.

Here are the steps to take, assuming you have openssl and keytool in your path, and are on a unix based system (I’m on Mac):

openssl pkcs12 -inkey ./yourdomain.key -in ./wildcard.yourdomain.com.crt -export -out ./yourdomain.pkcs12

This will generate a pkcs12 keystore with the certificate and key in it. Note that you need to concat your own certificate and the CA certificate, as explained here in step 3b.

Once this is done you need to create the keystore you will use, this is done using the following command:

keytool -importkeystore -srckeystore ./yourdomain.pkcs12 -srcstoretype PKCS12 -destkeystore ./yourdomain-ssl.keystore

Put the generated keystore (yourdomain-ssl.keystore) in your path, I put it in /src/main/resources so it is copied to my /classes path and thus can be used by my service.

Now you need to use it in your project, this is done through your POM file (assuming you’re using Maven, if not you should, and assuming you’re using jetty, which at least for dev environment is perfect):

								<connector implementation="org.eclipse.jetty.server.nio.SelectChannelConnector">
								<connector implementation="org.eclipse.jetty.server.ssl.SslSocketConnector">

A couple of things to note here:

  1. I’m using profiles, so this is activated only locally and not on production.  Maven profiles are out of scope here.
  2. I set the password to mypass, this password will be requested from you during the process of creating the keystore, just use whatever you like.
  3. This will work for your certificate, either regular or wildcard, but note that deep nested wildcard certificates (e.g. *.*.yourdomain.com) need to be generated specifically as such, otherwise local.admin.yourdomain.com won’t work)
Categories: R&D
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: