Monday, 26 June 2017

x509 certificate chaining

Our x509 certificate supplier recently change the root and intermediate certificates needed to use them (without warning, which was unhelpful). Sorting this out caused me to have to re-learn how certificate chaining is supposed to work.

As far as I can see, the primary rule is that the 'Issuer' DN of one certificate must match the 'Subject' DN of a certificate corresponding to the key that signed the first certificate.As an optimisation or hint, certificates can contain a 'Authority Key Identifier' which should match the 'Subject Key Identifier' of a certificate corresponding to the key that signed the first certificate. Quite what a key identifier is is not defined though there are suggestions. In most cases it's some sort of digest of the corresponding public key.

If you really want to know how certificate paths are built and validated then see RFC 4158 and RFC 5280.

Monday, 10 April 2017

Updating SAML Service Provider keys for Shibboleth IdsP

SAML Service Providers (SPs) maintain one or more key pairs for use when interacting with Identity Providers (IdPs). The public part of these key pairs are distributed to IdP via SAML metadata or otherwise.
SP keys are used for two purposes:
  1. The SP uses them to sign authentication requests
  2. IdP use them to encrypt attribute assertions in responses for decryption by the SP (encryption is optional, but commonly enabled)

Keys need to be replaced occasionally. This can be difficult to achieve without service disruption because the public parts are distributed and it's impractical to update all copies simultaneously. For a Shibboleth IdP, coping with replacement of an SP key used for signing isn't problematic -- a new key can be added to the SP's metadata ahead of deployment and the IdP will be happy with signatures made with either. However once two keys appear in the metadata the IdP may use either to encrypt assertions and this will only work if the SP is happy to perform decryption with either key.
For Shibboleth SPs this isn't a problem, because they can be configured to accept multiple keys for decrypting assertions while using a nominated key for creating signatures. There's a well known procedure for rotating the key on such a SP, see for example documentation on the UK federation site and in the Shiboleth Consortium Wiki. This amounts to:
  • Create new key pair on the SP
  • Configure the SP to accept either key for decryption but not use the new one for signing (by adding the new one with use="encryption")
  • Add the new key to the SPs metadata for both use="signing" and use="encryption" (or just without a 'use' attribute)
  • Wait for the metadata to propagate, or directly update all IdPs
  • Switch the SP to use the new key for signatures (by removing use="encryption" from the new one and adding it to the old one)
  • Completely remove the old key from the SPs metadata
  • Wait for the metadata to propagate, or directly update all IdPs
  • Remove the old key from the SP configuration
Some SPs don't support this. However it is only encryption that causes a problem. The main reason for encrypting assertions is to prevent users seeing what the IdP is saying about them, but in man cases there's nothing in the assertions that the user can't see by other means. So temporarily disabling encryption while rolling a SP key is a possibility. This means that the key can be rolled without downtime with the following revised procedure:
  • Setup custom relying party on the IdP for the SP that suppresses encryption. Something like this:
<rp:RelyingParty id="<SP entityID>"
   provider="<IdP entityID>"
   defaultSigningCredentialRef="IdPCredential" >

   <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" 
       encryptAssertions="never" 
       encryptNameIds="never" />

 </rp:RelyingParty>
  • Add the new key to the SP's metadata
  • Wait for the metadata to propagate, or just update all IdPs.
  • Switch the SP to use the new key
  • Remove old key from metadata
  • Wait for the metadata to propagate, or just update all IdPs.
  • Remove the custom relying party configuration
Note that this requires coordinated work on every IdP with which the SP works so it's not practical on a large scale. It will however work where there's essentially a one-to-one SP -> IdP relationship, as in many SaaS scenarios.

Tools such as the Firefox SAML tracer, the Chrome SAML Dev Tool extension and the SAML Chrome panel are  really helpful for checking that each step of the process has completed before moving in to the next.