JWT validity and expired X.509 certificates

Issue #113 new
Former user created an issue

Summary

When jose4j is validating a JWT signed with a private key that came from a X.509 certificate with public/private key pair, for which the public certificate is provided to jose4j, can jose4j's validator chain fail validation if say, the certificate is expired?

Detail

Using an expired X.509 certificate:

  • Create a signed JWT using PublicJsonWebKey, the private key and the certificate (which presumably josej4 uses to derive the public key. I ensure that the thumbprints are exposed in JWS instead of a keyID.
  • Create a new JwtConsumer and add a X509VerificationKeyResolver with the public certificate.
  • Currently, validating the JWT (i.e. processClaims()) does not throw any error.

Notes ##

  • If this functionality already exists (short of implementing a custom validator), can you highlight any quick points on how to make this work?
  • Given that one can provide the Public Key directly in a JWKS to a token consumer, it may be the case that the standard is loose on X.509 usage outside it being a vehicle to grab a public/private key, but coming from the SAML world, using X.509 without the certificate verification piece feels unnatural.

Thanks!

Comments (1)

  1. Brian Campbell repo owner

    So basically, yes, the certificate is treated as just a holder for the public key. It's not universally true but, in general, applications of JOSE/JWT are using bare keys or treating a self-singed certificate as only a wrapper around the public key (some might argue that SAML should have done the same).

    So there's nothing in this library that will check if certificate is expired or do path validation or revocation checking etc..

    If you do need such functionality, the application using the library will need to perform the checks as needed. Checking the certificate(s) before creating the X509VerificationKeyResolver and only giving it the ones you consider valid might be an easy(ish) way to approach it. Also it sounds like you are maybe only dealing with one certificate per JwtConsumer. If so, you don't really need a X509VerificationKeyResolver - you could potentially check the cert first and, if okay, use its public key on a call to setVerificationKey(Key verificationKey) on the JwtConsumerBuilder.

  2. Log in to comment