Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Since each key found is evaluated, new keys can be introduced by registering them in metadata, waiting a pre-defined period of time for the change to propagate, and then finally deploying the new signing key.

Known Issues

The libraries included with SP versions prior to 2.2.1 have a bug that prevented the use attribute within a <md:KeyDescriptor> from applying. As a result, keys intended solely for encryption (use="encryption") are still accepted for signing in SP versions prior to 2.2.1.

Validating TLS and X.509 Credentials

...

Note that a change to a certificate will not necessarily require an update to metadata as long as the key hasn't changed.

Known Issues

The libraries included with SP versions prior to 2.2.1 have a bug that prevented the use attribute within a <md:KeyDescriptor> from applying. As a result, keys intended solely for encryption (use="encryption") are still accepted for TLS in SP versions prior to 2.2.1.

Since most other SAML implementations are likely to enforce the usual TLS name checking rules when evaluating a TLS server certificate, this checking is not disabled by Shibboleth. As a result, the certificate's CN or subjectAltName(s) are checked against the expected hostname. This does not add any actual security to the system since a non-matching key won't be accepted anyway, but is still a requirement for deployers.

...