Cliquez ici pour la version française
SAML Certificate rollover instructions for a Shibboleth SP
1. Purpose of the document
This datasheet describes the steps to follow to perform the rollover of the SAML encryption certificate (or SAML signature certificate if applicable) for a Shibboleth SP, without any interruption of service.
Warning:
The SAML certificate rollover for an SP is a critical operation that cannot be carried out in only one stage.
Indeeed the delay to propagate the metadata to all other SAML entities in the federation MUST be taken into account.
In order to perform this operation without any interruption of service, it is crucial to respect the order and timing of the instructions described below.
The SAML certificate rollover for an SP is a critical operation that cannot be carried out in only one stage.
Indeeed the delay to propagate the metadata to all other SAML entities in the federation MUST be taken into account.
In order to perform this operation without any interruption of service, it is crucial to respect the order and timing of the instructions described below.
2. SAML encryption certificate rollover
2.1 Use of the SAML encryption certificate by the SP
- A SAML encryption certificate is used by the SP to receive encrypted messages from IDPs of the same federation(s).
- This type of certificate is mandatory for an SP.
- Only one SAML encryption certificate can be present at a time for an SP on the federation registry.
2.2 Rollover instructions
The rollover procedure to be followed is as follows :
# Step 1 (T0) :
- At T0, the new certificate :
- Must be declared in the SP configuration as a second encryption certificate, in addition to the old one.
- Must then be declared immediately on the federation registry as the only encryption certificate for the SP, replacing the old one.
- Once the change is submitted on the federation registry, a notification is sent to the manager of the SP. This notification summarizes the change made and provides information on the rest of the rollover process and upcoming milestones.
Important:
The new encryption certificate declared on the federation registry will be used progressively by the IDPs of the same federation(s), as soon as they become aware of it via the renewal of their metadata, with an estimated delay of 48 hours for complete propagation.
During this transition period, some IDPs will then use the old certificate and others the new one to encrypt their messages to the SP. This is why it is necessary that both certificates - the old and the new - are declared at this stage in the SP configuration.
The new encryption certificate declared on the federation registry will be used progressively by the IDPs of the same federation(s), as soon as they become aware of it via the renewal of their metadata, with an estimated delay of 48 hours for complete propagation.
During this transition period, some IDPs will then use the old certificate and others the new one to encrypt their messages to the SP. This is why it is necessary that both certificates - the old and the new - are declared at this stage in the SP configuration.
# Step 2 (T0 + 48h) :
At T0+48h, the delay required for full metadata propagation is normally completed and the new SP certificate is now the only SAML encryption certificate known to the IDPs of the same federation(s).
- At T0+48h, a notification is sent to the SP manager, inviting him to update the configuration of his SP by deleting the old encryption certificate.
- The old encryption certificate can then be safely removed from the SP configuration.
3. SAML signing certificate rollover
3.1 Use of the SAML signing certificate by the SP
- A SAML signing certificate is used by the SP to send authenticated messages to IDPs in the same federation(s)
- This type of certificate is not mandatory for an SP, except to enable single logout (SLO)
- A maximum of two signature certificates can be present at a time for an SP on the federation registry, as part of the rollover process
3.2 Rollover instructions
The rollover procedure to be followed is as follows :
# Step 1 (T0) :
- At T0, The new certificate must be declared on the federation regitry as a second signature certificate for the SP, in addition to the old one.
- Once the change is submitted on the federation registry, a notification is sent to the manager of the SP. This notification summarizes the change made and provides information about the rest of the rollover process and the upcoming milestones.
Important:
The new signature certificate declared on the federation registry will be known by all IDPs of the federation in only 48 hours, which corresponds to the delay for full metadata propagation.
It must therefore not be declared in the SP configuration at this stage, otherwise messages from it will be rejected by certain IDPs that are not yet aware of this new certificate.
The new signature certificate declared on the federation registry will be known by all IDPs of the federation in only 48 hours, which corresponds to the delay for full metadata propagation.
It must therefore not be declared in the SP configuration at this stage, otherwise messages from it will be rejected by certain IDPs that are not yet aware of this new certificate.
# Step 2 (T0 + 48h) :
At T0+48h, the delay required for full metadata propagation is normally completed and the new SP signature certificate is now known to the other IDPs in the same federation(s).
- At T0+48h, a notification is sent to the manager of the SP, inviting him to update the configuration of his SP with the new certificate.
- The new certificate can then be safely declared in the SP configuration as the only signature certificate, replacing the old one.
# Step 3 (T0 + 96h) :
- At T0+96h, the old SP signing certificate is automatically deleted from the federation registry.
- A notification is then sent to the manager of the SP to inform him of this automatic deletion and to remind him - if this was not done in the previous step - to also delete the old certificate from the SP configuration.