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?

Improve this question
3
  • Related: A guy trying to explicitly ignore expiration checks: SO:java - ignore expired ssl certificate
    – StackzOfZtuff
    Nov 16, 2015 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, 2015 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, 2015 at 22:46

1 Answer 1

Reset to default
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.

Improve this answer
1
  • 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, 2015 at 22:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .