5

I maintain an old Java app that deploys to Tomcat and which uses SSL (and hence a keystore). It is important to note that this app will not even start up if the SSL cert is bad/expired/invalid!

Every year the SSL cert expires, and so someone has to replace the old/expiring cert stored in the JKS with a new one (provided to us by IT). I am now starting that process/fun for this year.

I started by running the keytool command that prints the contents of the JKS:

keytool -list -v -keystore myapp.jks

Unless I'm reading its output wrong, I only see a cert that expired in 2015! If that's the case, how in the heck has this app been running for the last year?!? The one thing I do see is a cert in the "chain" that expires in 2034. I guess I don't understand SSL chains as well as I should, but my theory is that (somehow) the cert that expires in 2034 is somehow keeping my main cert alive/valid - is that possible? Here's a censored/summary of the output of that list command from above:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: blah
Creation date: May 1, 2014
Entry type: PrivateKeyEntry
Certificate chain length: 3
Certificate[1]:
Owner: blah
Issuer: blah
Serial number: blah
Valid from: Thu Feb 16 15:49:19 EST 2012 until: Mon Feb 16 15:49:19 EST 2015
Certificate fingerprints:
    MD5:  blah
    SHA1: blah
    SHA256: blah
    Signature algorithm name: SHA1withRSA
    Version: 3

Extensions: 

#1: ObjectId: blah Criticality=false
AuthorityInfoAccess [

...a lot of stuff omitted for brevity

Certificate[3]:
Owner: OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
Issuer: OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
Serial number: 0
Valid from: Tue Jun 29 13:06:20 EDT 2004 until: Thu Jun 29 13:06:20 EDT 2034
Certificate fingerprints:
    MD5:  blah
    SHA1: blah
    SHA256: blah
    Signature algorithm name: SHA1withRSA
    Version: 3

...a lot more stuff, again omitted for brevity

Can anybody see any reason why this cert would still be valid?!?

smeeb
  • 4,820
  • 10
  • 30
  • 49
  • 3
    Ah, Go Daddy. The company whose core competency is sexy Super Bowl commercials. – Robert Harvey Jan 27 '16 at 15:01
  • Why are you convinced that the application shouldn't start up when the keystore certificate is invalid? Is it being loaded as a keystore and/or a trust store? Providing or requiring a network resource? What error do you expect to see? There isn't enough information here I am afraid. – maple_shaft Jan 27 '16 at 16:12

1 Answers1

6

In certificate chaining, you are essentially allowing the issuer of certificates to validate your certificates on your behalf. The GoDaddy certificate in this instance is your Root Certificate Authority and validates the identity of the Root CA. They also will issue you an intermediary certificate to represent your organization as well and this is just another certificate on the chain.

If at any point along the way if your certificate is compromised then they can stop validating your intermediary certificate and this invalidates all other domain certificates that GoDaddy issued to you. Why are they doing this? It is so a client, if they so wish, can ask GoDaddy as the CA if the identity of the server is legit. The Root CA cert identifies GoDaddy and is known to be trusted already, and then the Root CA will give the client a thumbs up or thumbs down. Most browsers have this validation functionality built in. You notice that on the browser where the certificate is presented for a secure site shows up in Green. That generally means the browser validated the presented certificate against the CA and it was deemed valid. When any certificate expires in this chain then trust cannot be established with the server by the client.

So what happens in Java? Well a JKS file is essentially not only a keystore, but also a trust store for a Java application. A trust store is something that a Java client will use to validate the identity of trusted servers that it is allowed to talk to. Generally on a typical Java application running in a typical JVM, it will not establish an SSL connection with a secure network resource unless the presented certificate exists in its truststore. Keep in mind, this certificate may not even be technically valid or it can EVEN be self signed and not validated by a Root CA, but if it exists on the specified Truststore that has been loaded into the Java application then it will still trust it.

What you didn't describe is if this certificate is for a network resource that you are providing as a server or a network resource that you require as a client. If the latter then you might get a warning about the certificate being expired, but it will still work because it is in your trust store.

maple_shaft
  • 26,401
  • 11
  • 57
  • 131
  • Thanks @maple_shaft (+1) - to answer your question this cert is being loaded by an authentication server and is therefore acting as a **keystore**. The authentication server is based on Aperero CAS which as [called out in their docs](http://jasig.github.io/cas/4.1.x/planning/Security-Guide.html) requires valid SSL in order to be able to authenticate (so you're right, the server will stand up, but all auth will fail unless SSL is valid). – smeeb Jan 27 '16 at 18:31
  • So now that you know it is acting as a keystore (not truststore), does that change your (excellent) answer? – smeeb Jan 27 '16 at 18:31
  • Nothing I said here really changes because I am still trying to understand what in fact the certificate is being used for and what behavior are you seeing that is incorrect. If I understand correctly, your Tomcat server is running an old Java app that is using CAS framework to authenticate a Servlet or other network resource being provided by that old application. CAS keystore is configured in Tomcat through a JKS file, it is serving network resources to clients but presenting an EXPIRED certificate that it has in its JKS file. You are expecting this to fail but it works? – maple_shaft Jan 27 '16 at 18:57
  • If what I said above is TRUE, then it works not because your server is wrong but because your client application for whatever reason decides to trust it anyway. If the client is a user, and that user is using a browser, typically that browser would see the expired cert and give the user a warning message. The browser has a certificate trust store as well and it could be that the user accepts the certificate problem and decides to trust it anyway. Perhaps the client is another Java system, well normally it would reject an expired cert but it may have a trust store with the expired cert. – maple_shaft Jan 27 '16 at 19:00