1

My client is running Tomcat 5.5 and is using SSL. Their certificate is about to expire and they have purchased a renewal. I was given a .cer file and asked to update Tomcat.

The existing server.xml contained the following connector:

<Connector port="443" maxHttpHeaderSize="8192"
           maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
           enableLookups="false" disableUploadTimeout="true"
           acceptCount="100" scheme="https" secure="true"
           clientAuth="false" sslProtocol="TLS"
           keystoreFile="companyname.keystore" keyAlias="tomcat2" />

I ran %JAVA_HOME%\bin\keytool -list -keystore companyname.keystore

Keystore type: jks
Keystore provider: SUN

Your keystore contains 3 entries

root, Aug 7, 2007, trustedCertEntry,
Certificate fingerprint (MD5): 8F:5D:77:06:27:C4:98:3C:5B:93:78:E7:D7:7D:9B:CC
tomcat, Jun 12, 2007, keyEntry,
Certificate fingerprint (MD5): 33:80:6F:75:5A:B4:BC:C7:7A:7D:4F:3F:FA:C0:95:2F
tomcat2, Jun 14, 2008, keyEntry,
Certificate fingerprint (MD5): 0A:9B:73:6A:EE:2F:18:99:61:49:28:F3:CD:1E:DF:96

SSL still works if I delete the entry with the alias "tomcat". I'm assuming that's an artifact from a previous expired certificate.

%JAVA_HOME%\bin\keytool -import -keystore companyname.keystore -alias tomcat3 -file 2009cert.cer

I updated server.xml to set keyAlias to tomcat3. When I restart Tomcat, I see this in the log:

SEVERE: Error initializing endpoint
java.io.IOException: Alias name tomcat3 does not identify a key entry
    at org.apache.tomcat.util.net.jsse.JSSE14SocketFactory.getKeyManagers(JSSE14SocketFactory.java:143)
    (etc.)

When I re-run the keytool -list command:

Keystore type: jks
Keystore provider: SUN

Your keystore contains 4 entries

root, Aug 7, 2007, trustedCertEntry,
Certificate fingerprint (MD5): 8F:5D:77:06:27:C4:98:3C:5B:93:78:E7:D7:7D:9B:CC
tomcat, Jun 12, 2007, keyEntry,
Certificate fingerprint (MD5): 33:80:6F:75:5A:B4:BC:C7:7A:7D:4F:3F:FA:C0:95:2F
tomcat3, Jul 21, 2009, trustedCertEntry,
Certificate fingerprint (MD5): 8E:9F:F9:52:7B:07:B1:DB:BF:F3:96:BD:5F:49:2E:9F
tomcat2, Jun 14, 2008, keyEntry,
Certificate fingerprint (MD5): 0A:9B:73:6A:EE:2F:18:99:61:49:28:F3:CD:1E:DF:96

Does this have something to do with the tomcat3 entry being marked as "trustedCertEntry" rather than "keyEntry"?

What am I doing wrong?

Improve this question
1

The fact that it's registering as a TrustedCert would seem to indicate that there's no key for tomcat3. It's likely that the new certificate was requested for the existing key tomcat2. Keys themselves don't expire, just the certificates.

You can request a new certificate at any time either by generating a new cert signing request or by reusing the original one either of which is fine. Take a backup copy of your keystore and then import the certificate for the tomcat2 alias.

%JAVA_HOME%\bin\keytool -import -keystore companyname.keystore -alias tomcat2 -file 2009cert.cer

After that, you'll also want to point your tomcat instance back at tomcat2.

Improve this answer
3
  • When I try that, I get this error: keytool error: java.lang.Exception: Public keys in reply and keystore don't match – Jeremy Stein Jul 20 '09 at 11:49
  • 1
    By the look of it, the only other key in the keystore is tomcat, so give that a try instead of tomcat2. Failing that, someone has gotten a csr from another key elsewhere. Importing keys into a keystore is possible but it's non trivial. – Frenchie Jul 20 '09 at 13:10
  • You nailed it. It turns out the client had created a new private key and CSR and hadn't mentioned that fact. Thanks! – Jeremy Stein Jul 20 '09 at 17:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.