The image above is a common scene when developing new web applications and perfectly fine for internal development machines, but when it’s time to deploy it just won’t do.

This article will go through the steps needed to apply a certificate, signed by a trusted third party, to secure our web applications.

Prerequisites

This article will assume you already have the following:

• A registered domain pointed to a server running Glassfish 4.0.
• A web application deployed to that glassfish instance

For the purposes of this article I’ll pretend we’ve registered domain.com. If you’re following these steps make sure to replace any instances of domain.com with your own domain.

I would encourage you to read the entire article before following the instructions yourself, now lets start securing glassfish.

Step 1: The certificate signing request

The first step is to generate our signing request and submit it to the trusted third party, the exact steps can vary between providers. We performed these steps for GoDaddy from an Oracle Linux host. If possible perform the steps from the host you want to install the certificates on, this will reduce the risk to your private key as we won’t have to transfer it later.

Access the console of your Linux machine and at the terminal prompt:

• openssl req -new -newkey rsa:2048 -nodes -keyout domain.key -out domain.csr

OpenSSL will ask us a few questions before generating the request. It is important these are answered correctly or the authority may reject the request.

• Common Name: This is the fully qualified domain name so domain.com, if you’ve purchased a wildcard certificate then use *.domain.com instead
• Organization: The name of the business owning the domain. If you’re an individual you should put your name here instead
• Organization Unit: This is the business name as it’s commonly known so we would use ‘borwell’ here instead of ‘borwell Ltd’
• City or Locality: This should be the full name of the city in which your business is registered
• State or Province: This should be the full name of the state in which your business is registered
• Country: The two letter ISO country code for the country your business is registered in. You can find a list of the codes here https://www.iso.org/obp/ui/#search/code/

Check with your certificate authority if you need to use a CSR challenge password or not. The challenge password only encrypts the signing request. A challenge password is used to encrypt your signing request and would have to be somehow provided to your authority for them to decrypt it. Your private key will be unencrypted at this point.

Once the OpenSSL command has finished you will have two files domain.key and domain.csr both are text files. You can go ahead and open them up.

Domain.key is your private key. It is important you keep this safe, as with it an attacker could impersonate your server or decrypt traffic between you and your applications clients.

Domain.csr is the signing request and your public key. We will be sending this to the authority for them to verify and sign (thus introducing third party trust).

At this point we upload the domain.csr (either in file or text form) to the authority. Consult their own instructions for this step. We will have to wait a day or so while they verify you own the domain (there’s no rushing them, this is an important part of certificate based trust).

Once this is complete your authority will make your signed certificate available to download and should also include any intermediary certificates they have introduced to the chain.

Step 2: Combining your signed public key with your private key and CA chain

In this step we are going to combine all the files into a Java keystore so that Glassfish can make use of them.

This step is going to deal specifically with the set of files given to us from GoDaddy. The steps may need to be modified if you’re dealing with another authority but the goal should be the same.

First you should have the following files:

• key (from Step 1)
• crt (your public key, downloaded from GoDaddy; The exact file name will be different)
• crt (An intermediate CA certificate, downloaded from GoDaddy)
• gd_bundle-g2-g1.crt (Another CA certificate, downloaded from GoDaddy)

Place the files in your glassfish domain config directory $GLASSFISH_DIR/glassfish/domains/domain1/config where $GLASSFISH_DIR is the glassfish installation directory.

At the prompt combine your public key with the intermediate CA:

• cat 27faeb87fgeg.crt gdig2.crt > domain-g2.crt

Next use OpenSSL to combine your public bundle with your private key, set the password to ‘changeit’.

• openssl pkcs12 -export -in domain-g2.crt -inkey domain.key -out domain-g2.p12 -name domain.com

Finally use keytool to import your public/private pair into glassfish’s keystore.

• keytool -importkeystore -deststorepass changeit -destkeypass changeit -destkeystore keystore.jks -srckeystore domain-g2.p12 -srcstoretype PKCS12 -srcstorepass changeit -alias domain.com

A note on keystore passwords

In the last command we passed a number of passwords on the command line. All of which were ‘changeit’. This is the default keystore password used by glassfish and as such the command should work if you’ve not modified glassfish’s security settings in the past. If you have given Glassfish a new master password then use this in place of ‘changeit’ on the ‘deststorepass’ and ‘destkeypass’ fields.

You will have been asked to set a keystore password by OpenSSL when creating the domain-g2.p12 file. Again we’ve used ‘changeit’ for simplicity but you can use anything. Replace ‘srcstorepass’ with the password you use when executing the keytool command.

Step 3: Configure glassfish to use your new certificates when communicating via HTTPS

In this step we will tell Glassfish to use our certificates.

Open the administrator console (default port 4848) and navigate to the SSL settings tab for the secure listener (this is http-listener-2 by default):

 

The page should look like the next image:

All we have to change here is the certificate nickname. It will have defaulted to ‘s1as’ which is Glassfish’s self-signed certificate.

Go ahead and change it to domain.com. This is the lookup glassfish will use when extracting a key pair from the keystore.jks file. domain.com in this case is the value we passed as -alias when importing the key pair.

Click save and restart the glassfish process. Once it’s back online you should find your application serves your new signed certificates when accessed via https (the port number can be found on the general tab of the http-listener-2 settings, default 8181) e.g. https://domain.com:8181.

Conclusion and next steps

Following this article we should now have a Glassfish server hosting up web applications with a trusted certificate. We shouldn’t be receiving any more security warnings from browsers.

Next we want to modify the incoming request so we don’t need to include a port, and lock down the cipher usage to improve security. These will be the subject of future articles.

Good luck with your improved web security, you are now done securing glassfish!

We’re hiring so make sure to check out http://www.borwell.com/career/ look at the software challenge and give it a go while you’re here.