Fix “Subject Alternate Name” error showing up in Chrome from WebSphere.

Are you getting a ERR_CERT_COMMON_NAME_INVALID error with Chrome, even though your WebSphere server has a properly installed SSL certificate that should be ok? Read more to find out why this error is happening, and more importantly, how to resolve it easily.

A really weird problem started happening on my WebSphere boxes last spring. Up until April or so, the certificates issued by our Microsoft Certificate Services local CA worked perfectly, we always got the green padlock when we went to HTTPS URLs on all of the WebSphere boxes. It was great.

Then one day, the we started getting a warning that the site shouldn’t be trusted. Weird right? And what was even more weird, this problem was only opening happening with Chrome! Internet Explorer, Edge, and FireFox were all still happy with the certificates.

The details of the error message, ERR_CERT_COMMON_NAME_INVALID, and the release notes for Chrome Build 58 explained that as of that build, Chrome no longer used commonName to match the domain name and site certificate. Instead, it would start using subjectAlternativeName (SAN).

Ok, that’s fine, I thought, I’ll just issue a new cert and everything would be ok.

Unfortunately, WebSphere Application Server’s built-in certificate request process doesn’t provide any way to ask for a subjectAlternativeName.

But there’s always a workaround, right? YES! The workaround I figured out was to use the well-known open source OpenSSL tool to generate a CSR with a subjectAlternativeName. Then, once I got the certificate back from my internal CA, do a little magic to import the private key, newly issued  certificate, and CA certificate into WebSphere so the padlock in Chrome would return to happy green.

Here we go!

Before we get going, download and install OpenSSL. You can check the version by entering openssl version like this:

Mine was OpenSSL 1.0.2k  26 Jan 2017.

Step #1

First, create a CSR, and associated private key, with a specified text file containing all the properties we need (yourservername.cnf) – the name of the file doesn’t matter at all – just make sure you use the correct configuration file!

Here’s my configuration file:

[ req ]
default_bits = 2048
distinguished_name = dn
req_extensions = ext
prompt = no
[ dn ]
emailAddress =
organizationName = Hanselware, Inc.
organizationalUnitName = Engineering
commonName =
localityName = Seattle
stateOrProvinceName = WA
countryName = US
[ ext ]
subjectAltName =,DNS:hanxxx

(Notice the very last line of this file – I’m specifying two subjectAltName entries – this is where Chrome will now look to verify hostname.)

Once I have that configuration file ready, I can use OpenSSL to request a certificate and generate a corresponding private key, like this:

openssl req -out hanxxx.csr -newkey rsa:2048 -nodes -keyout hanxxx.key -config hanxxx.cnf

When the command finishes, I have a CSR to send to my Certificate Authority (CA), and the corresponding private key.

Step #2

Next, I submitted the CSR to my CA; luckily that role was performed by me! So I just copied the CSR file to the Certificate Services box, and from the console on that server issued the following command:

certreq -submit -attrib “CertificateTemplate:WebServer” hanxxx.csr

I copied the newly issued certificate back to my workstation (where I was running my OpenSSL commands) along with the certificate from the issuing CA.

Step #3

Next, I checked to make sure the newly issued certificate, the private key I got when I created the CSR, and the CSR itself all matched from a cryptographic standpoint. The way I did this was to ask for the modulus from each file and make sure all three of the files produced the exact same output.

Modulus from the certificate

openssl x509 -noout -modulus -in hanxxx.cer | openssl md5

(stdin)= 5bae041723f3cc90045989xxxxxxxxxx

Modulus from the private key

openssl rsa -noout -modulus -in hanxxx.key | openssl md5

(stdin)= 5bae041723f3cc90045989xxxxxxxxxx

Modulus from the CSR

openssl req -noout -modulus -in hanxxx.csr | openssl md5

(stdin)= 5bae041723f3cc90045989xxxxxxxxxx


They all match – GREAT! we can proceed.

Step 4

Next, we need to create a PFX file to import into WebSphere. We’ll create this from the newly issued certificate, the private key we got when we made the CSR, and the Binary-64 format certificate from the Certificate Authority.

Since this file contains the private key that was created when we build the certificate request, we’ll need to provide a password when we create the PFX file to provide some extra protection for the private key.

openssl pkcs12 -export -out hanxxx.pfx -inkey hanxxx.key -in hanxxx.cer -certfile myCertAuthority-Binary.cer -password pass:SomeComplexPassword

Step 5

Now, copy the PFX file to your WebSphere server so we can install it using the following steps:

Log in to your WebSphere console, and go to Security/SSL certificate and key management. Choose “Key stores and certificates”.

From that screen, choose NodeDefaultKeyStore, then choose Personal Certificates.

Next, choose “Import” and provide the fully qualified path and name for the PFX file you created in the previous step. Provide the password you used when you created the PFX file. Then, click “Get Key File Aliases” otherwise the next step will fail.

Make sure that there is a least one value in the Certificate Alias to Import dropdown list. Then click Apply; this will import the PFX file to the keystore.

Save the configuration, then restart WebSphere.

Now refresh your WebSphere console URL in Chrome – the ERR_CERT_COMMON_NAME_INVALID will be gone and the SSL padlock will be green again!