Giters

SkyLothar / lua-resty-jwt

JWT For The Great Openresty

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

How to properly cope with certificate renewal?

fermaem opened this issue · comments

commented

The lib provides a way to validates certs through jwt:set_trusted_certs_file("/path/to/may/cert.pem").

We're currently assessing the integrity of jwts by

  • first validating the public cert exposed by the x5u claim against a trusted root one (set through jwt:set_trusted_certs_file("/path/to/may/cert.pem"))
  • then checking the signature of the signed jwt

However, it is unclear for me how we should cope with a renewal of the trusted root cert. Should the old one and the new one be concatenated in the .pem file?

commented

I don't use x5u personally, I'm not sure about the best practice.

  • Use kid or some claim to specify a .pem file?
  • Accept multiple certs file or single concatenated .pem file while renewal is in transaction?
commented

I'm not sure about the best practice.

Me neither 😢

Use kid or some claim to specify a .pem file?

It looks like kidactually exposes the fingerprint of the public cert exposed by the x5u claim.

Accept multiple certs file or single concatenated .pem file while renewal is in transaction?

I'll try to check if having multiple root certs in a single pem file plays well with the lib. Wouldn't that be the case, I'll work on a Pull Request to propose something (maybe some kind of a "if-that-doesn't work-with-that-pem-file-try-this-other-one" fallback mechanism)

commented

a few comments:

kid in a JWT is a key identifier in the generic sense; it may contain a fingerprint but that is a deployment choice, not dictated by any spec, so you can't rely on it; if you want to base validation on fingerprints, x5t is the way to go

checking multiple certs in a fallback scenario it a typical solution in e.g. SAML/SSO scenario's where the signing key is rolled over and peers need to have a chance to do the rollover at their own pace, without requiring a big bang

slightly better is to be able to provide a JWKs structure as the secret, which holds key material as well as key identifiers, so the receiver can lookup the right key in the set of configured JWKs based on the kid value (note though that you can implement the same scenario with x5t with multiple plain certs, yet x5t is only optional)