Search code examples
x509identityserver3

IdentityServer 3 signing certificate expiry

What happens when the signing certificate (used for signing jwt tokens) expires when using IdentityServer 3?

It's unclear to me and I can't find any documentation, other than that it's possible to get a warning that it has expired. (Ref. https://identityserver.github.io/Documentation/docsv2/configuration/events.html)

Is there any mechanism that stops the use of expired signing certs?
And what happens on the client side (client being the Web API that uses IdentityServer for authentication) when validating a token signed by an expired certificate? (For example if https://github.com/IdentityServer/IdentityServer3.AccessTokenValidation is used as a middleware.)

Solution

  • Well I've just tested this (on IdentityServer4) and it seems to continue to work happily with an expired signing certificate, here's my test cert's validity:

    enter image description here

    I'm able to login, get an ID token and an access token and then access an API with the access token. What IdentityServer does do however is to log a warning:

    2017-07-13 12:15:54.871 +02:00 [Warning] 
    Certificate "CN=test_expired_signing_certificate" has expired on "13/07/2016 14:14:37"

    This matches what the IdentityServer (3) docs say here:

    IdentityServer raises a number of events at runtime, e.g:

    snip...

    • Expired/invalid/no signing certificate

    By default these events are forwarded to the configured log provider - a custom event service can process or forward them in any way suitable for the environment.

    So this would be your way of detecting it when it's already too late. A better option is to rollover signing keys periodically and within the validity of the keys, this is the common approach which also allows for a compromised key to be revoked if necessary. See this issue where the process is discussed, basically IdentityServer can handle two keys:

    [Middleware refreshes] the metadata document ... once a day.

    The metadata doc can hold 2 keys - primary and secondary and the middleware will load and use both when present (JWTs have a key identifier that allows picking the right one).

    When you start to rollover - set both keys and at some point swap primary and secondary.