What happens after asymmetric key expiration?
-
Maybe I'm not searching through the docs thoroughly enough, but the effect of the asymmetric signing key expiration is not clear to me. Will it be automatically re-generated based on original configuration or will it be just marked inapplicable for cryptographic operations? If the latter is correct, what will happen with configuration relying on such key - I am referring to tenant or application JWT keys settings?
-
Hiya,
Can you please point me to where you see an asymmetric key that might expire configured in FusionAuth?
Or are you asking what will happen if the "Access token signing key" is revoked?
-
I'm referring to keys generated under Settings > Key Master. Generated asymmetric keys (RSA and ECDSA) are marked by FusionAuth to be valid for 10 years. I'm asking what happens to the key entry after validity period passes?
-
Ah, thank you for clarifying. I had a conversation with an engineer. The default key is valid for 10 years, as you noted. It is possible to upload a certificate that expires sooner. Right now we would not delete that key pair, and it may be possible to sign a JWT with that certificate. The JWT could not be verified however.
I filed an issue to discuss how we may want to enhance this in the future with an expiration policy. https://github.com/FusionAuth/fusionauth-issues/issues/580
Please vote it up, as that factors into our product roadmap.
Thanks!
-
Your finding is pretty important from the security perspective, but it is still not quite exactly the matter I'm asking about. However, because the expired keys can be used in cryptographic operations, I suppose that handling procedure of the case I am referring to is not yet covered in the current implementation. I'll try to explain with an example. Let's say we have FusionAuth instance with only one asymmetric key pairs in the key master. The key is defined as an JWT signing key in the tenant configuration. 10 years passed by, and - assuming fix is introduced - configured JWT signing key cannot be used. The user logs in - what key will be utilized to sign his JWT?
-
Well, since we're talking about behavior based on a fix that isn't written yet, things are a bit theoretical.
Here's one approach we'd consider. An expired key pair cannot be used to sign a JWT, so we would either have to generate a new key pair ahead of the expiration, or start failing login operations. The former is a better user experience, so a user will either have to regenerate the key, or we would do it based upon a configured policy.
Also, wanted to be clear that we are aware of this limitation, which is why we set the default expiration period to 10 years (so we have a bit of time to solve this in the best way possible).
Hope this helps. Let me know if you don't have the information you need.
-
This post is deleted!
