Covering J2EE Security and WebLogic Topics

Verisign’s New Intermediate CA and You

Starting in August, 2006, Verisign introduced a new intermediate Certificate Authority (CA) into its certificate hierarchy. As a result, Verisign server certificates are signed by this CA instead of being signed by the Verisign root as before. This article will guide you through the process of using keytool to install a certificate signed by this new CA certificate.

Why is this scenario different than before or with other CAs? The reason is that since the CA certificate is new, it hasn’t had time to fully propagate into the various places it needs to be, such as the cacerts trust store that comes with Java. (The new CA certificate is not in cacerts as of JDK 1.5.0_04 but it might be there in a later release.) Without the CA certificate in cacerts, you won’t be able to use keytool to import a certificate signed by the new CA.

For the purposes of this article, I’ll assume you have a JKS keystore with your private key and that you’ve submitted a Certificate Signing Request (CSR) to Verisign. Verisign signs your certificate with the new CA and sends you a cert.cer file containing your signed certificate.

Here’s what you need to do:

  1. Obtain the new intermediate CA certificate
  2. Import the intermediate CA certificate into cacerts using keytool
  3. Import your signed certificate into your keystore using keytool

Obtain the Intermediate CA Certificate

You can get the new CA certificate from here. Save the certificate contents to a file (the example below uses “NewVerisignIntermediateCA.cer”).

Before moving on, spend a few moments playing a game of Boggle with the certificate contents. 😉

Import the CA Certificate into cacerts

The keytool utility can be found in the <JAVA_HOME>\bin directory. The cacerts file it uses can be found in <JAVA_HOME>jre\lib\security. We’ll load the new CA certificate into cacerts:

keytool -import -keystore <JAVA_HOME>jre\lib\security\cacerts -file NewVerisignIntermediateCA.cer

The default cacerts password is “changeit”.

Import the Signed Certificate into the Keystore

We’ll use keytool again to load the signed certificate over the same alias as your key entry. (By the way, this is a good time to make a backup of your keystore!)

But first, a word about what Verisign sent you. The email will contain the certificate contents as part of the email text. There will also be an attachment of the same contents called cert.cer. Regardless of which one you use, ensure that there are no spaces or blank lines at the end of the file. The attached cert.cer likely has two blank lines. Remove those and ensure that there are no spaces at the end of the file.

Load the signed certificate:

keytool -import -keystore <keystore> -alias <alias> -file cert.cer -trustcacerts

where keystore is the name of your JKS file and alias is the alias of your key entry.

What you want to see from this command is

Certificate reply was installed in keystore

If you didn’t get this message, perhaps you got this beauty instead: DerInputStream.getLength(): lengthTag=127, too big.
keytool error: DerInputStream.getLength
(): lengthTag=127, too big.

If so, you played too much Boggle. Remove any blank lines and spaces from the end of your signed certificate file and try again.

Another indication of an unsuccessful load is this output:

keytool error: java.lang.Exception: Failed to establish chain from reply

If you get this message, keytool can’t find the new Verisign intermediate CA. Double-check the instructions above but skip the Boggle part or you’ll be messed up for the rest of the day.

Assuming you successfully imported your signed certificate, have a look at your handiwork with

keytool -list -keystore <keystore> -v

You should see something similar to the following:

Keystore type: jks
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: server
Creation date: Oct 3, 2006
Entry type: keyEntry
Certificate chain length: 3
Owner:, OU=Terms of use at (c)05, OU
=Department of Blogging Department, O=Bastion Blog, L=Pasadena, ST=Maryland
, C=US
Issuer: CN=VeriSign Class 3 Secure Server CA, OU=Terms of use at https://www.ver (c)05, OU=VeriSign Trust Network, O=”VeriSign, Inc.”, C=US
Serial number: 4a3b4682eab7b25b13dac435aefb3c5a
Valid from: Thu Sep 28 20:00:00 EDT 2006 until: Fri Oct 24 19:59:59 EDT 2008
Certificate fingerprints:
MD5: 9A:1E:CC:92:44:AF:CD:C0:57:67:63:3D:C0:F7:17:13
SHA1: 3D:79:41:BE:DB:DA:7B:5C:B6:F8:78:D8:60:4E:F8:80:33:E1:08:92
Owner: CN=VeriSign Class 3 Secure Server CA, OU=Terms of use at https://www.veri (c)05, OU=VeriSign Trust Network, O=”VeriSign, Inc.”, C=US
Issuer: OU=Class 3 Public Primary Certification Authority, O=”VeriSign, Inc.”, C
Serial number: 75337d9ab0e1233bae2d7de4469162d4
Valid from: Tue Jan 18 19:00:00 EST 2005 until: Sun Jan 18 18:59:59 EST 2015
Certificate fingerprints:
MD5: 2A:C8:48:C0:85:F3:27:DE:32:29:44:BB:B0:2C:79:F8
SHA1: 18:85:90:E9:48:78:47:8E:33:B6:19:4E:59:FB:BB:28:FF:08:88:D5
Owner: OU=Class 3 Public Primary Certification Authority, O=”VeriSign, Inc.”, C=
Issuer: OU=Class 3 Public Primary Certification Authority, O=”VeriSign, Inc.”, C
Serial number: e49efdf33ae80ecfa5113e19a4240232
Valid from: Sun Jan 28 19:00:00 EST 1996 until: Wed Jan 07 18:59:59 EST 2004
Certificate fingerprints:
MD5: 78:2A:02:DF:DB:2E:14:D5:A7:5F:0A:DF:B6:8E:9C:5D
SHA1: 4F:65:56:63:36:DB:65:98:58:1D:58:4A:59:6C:87:93:4D:5F:2A:B4

From this output you can see the issuer hierarchy where certificate 1 is your server certificate, certificate 2 is the intermediate CA, and certificate 3 is the Verisign root.

Enough work. Time for some more Certificate Boggle(TM). The great thing about it is that you can play all day and it’s boss-proof. When your boss asks why you’re staring at gibberish, you can say that you’re checking the server certificate for accuracy. He’ll admire your attention to detail and you’ll get a nice raise.



Bookmark this page on