5

It was noticed that the default java implementation of TrustManagerFactory for PKIX trust manager algorithm (X509ExtendedTrustManager) doesn't really check the expiration date of a client's certificate during SSL authentication.

This could be easily checked: configure Apache Tomcat 7.x with SSL client auth. Put in the trust store an expired client certificate. On the client side set the system time to a past time, when the certificate was not expired. Voila, the client can successfully authenticate on the web server.

The question is: is such a behaviour correct and appropriate to RFC 3280, or it is a bug?

Andremoniy
  • 153
  • 6
  • Related: A guy trying to explicitly ignore expiration checks: SO:[*java - ignore expired ssl certificate*](https://stackoverflow.com/questions/8693991/java-ignore-expired-ssl-certificate) – StackzOfZtuff Nov 16 '15 at 12:54
  • @StackzOfZtuff wrong, that question is about absolutely different thing. I'm asking about server configuration. In mentioned SO question author deals with client side. – Andremoniy Nov 16 '15 at 15:30
  • The configuration is different, but the certificate validation logic is perfectly symmetric at the SSL/TLS level -- client validation of a server cert works exactly the same way as server validation of client cert given the same input; you've just made the input wrong. For *some* higher-level protocols notably HTTPS the client also checks the *name(s)* in the server cert against the desired name, while the server may or may not do anything with the client name(s). – dave_thompson_085 Nov 17 '15 at 22:46

1 Answers1

4

No it doesn't and no it isn't a bug. For what it's worth, I see nothing explicit in RFC 3280 mandating that path validation fail on expired certificates.

If you have a certificate in the trust store javax.net.ssl default TrustManagers will trust it regardless of expiry.

There is nothing in the JavaDoc suggesting that it checks expiry. I'd say it's by design.

I dove pretty deeply into the JCL source and it makes no attempt to check certificate expiry.

Other users have encountered and verified this behavior: https://stackoverflow.com/a/5206923/154527

You will need your own TrustManager to enforce this.

Community
  • 1
Alain O'Dea
  • 1,615
  • 9
  • 13
  • 1
    For certs in the path see rfc3280 6.1.3(a)(2), unchanged in rfc5280 -- but note the anchor is not in the path and for Java a truststore entry is an anchor. Yes, if you put a cert in the truststore it is trusted, even if expired, OR if revoked, or from a suborned or bogus CA, or just entirely fake. **Putting it in the truststore means you do trust it, whether or not it deserves that trust.** Generally you should trust only CA roots (which are usually long-lived) and let the certs issued under them be checked by normal CertPathValidator logic. – dave_thompson_085 Nov 17 '15 at 22:44