Contentful SAML Certificate Rotation: 21 Sept Guide

Why metadata matters during a SAML rollover

SAML metadata communicates service-provider details such as entity identifiers, endpoints and cryptographic keys. Contentful's SSO documentation notes that most identity providers can import a metadata file instead of requiring every value to be entered manually.

The OASIS SAML metadata interoperability profile allows future signing or transport-authentication keys to appear alongside current keys to prepare for rollover. This is the technical reason a platform that can ingest multiple certificates can complete a staged change: trust the new public key while the old one is still valid, let the service provider switch, verify the new path, then remove the retired key only after the transition is complete.

Not every identity platform or application integration handles multiple service-provider keys in the same way. Some imports replace the current certificate; others merge keys; some require an administrator to select the signing and encryption uses. Treat the import result as a configuration change that must be inspected, not as a blind upload.

Build an inventory before changing the identity provider

A short inventory prevents the team from fixing one login path while leaving another exposed. Record:

• the Contentful organisation ID and SSO name;
• every SSO connection and identity-provider tenant;
• the enterprise-application owner and a second authorised administrator;
• whether request-signature verification is enabled;
• whether assertion encryption is enabled;
• the current service-provider certificate thumbprint or fingerprint;
• whether the identity provider accepts more than one service-provider certificate;
• the Contentful metadata URL or exported file used for the integration;
• the group assignments, conditional-access rules and test users attached to each connection;
• the emergency access route, change window, rollback owner and Contentful support contact.

Capture the current state before importing anything. Export the enterprise-application configuration where the platform supports it, or retain timestamped screenshots and certificate details in the change record. Do not paste private keys, tokens or recovery credentials into the ticket.

Contentful's older certificate-rotation guidance identifies an organisation-specific metadata location using the organisation ID. Prefer the current metadata link shown in your Contentful SSO configuration or current tenant communication, and verify it with Contentful documentation or support before importing it.

Use a controlled change plan

Before the cut-over

1. Assign owners. Name the Contentful organisation owner, identity administrator, test lead, communications contact and recovery decision-maker.
2. Confirm impact. Review request-signature verification and assertion-encryption settings for every SSO connection.
3. Validate recovery access. Confirm an authorised administrator can reach the required consoles without depending on the exact SSO path being changed.
4. Refresh metadata only when appropriate. For identity providers that support both keys, import before cut-over and verify that the existing key was not removed.
5. Prepare tests and communications. Select users from each SSO connection and major access policy; tell editors when the attended window will occur.

During the cut-over window

1. Watch Contentful's status and support channels and confirm the vendor change before acting on a single-certificate integration.
2. Import the current metadata through the approved identity administration route.
3. Compare the certificate details and application endpoints with the expected change; stop if unrelated settings moved.
4. Run service-provider-initiated tests from a fresh private browser session, followed by any supported identity-provider-initiated route.
5. Record the outcome, time, tester, SSO connection and relevant identity-provider log identifiers.

After access is verified

Monitor login failures and support tickets across the next business cycle. Keep the old certificate only as long as the identity platform, Contentful advice and your security process allow. Close the change after all SSO connections and recovery controls are verified—not after one administrator signs in successfully.

Prepare for a lockout without weakening security

A certificate rollover is exactly the kind of fundamental authentication change that should have a tested recovery method. The Australian Signals Directorate's system-access guidance says emergency access should be documented and tested when it is implemented and when fundamental IT infrastructure changes. It also says break-glass access should be used only when normal authentication cannot be used, restricted to authorised activities and centrally logged.

For Contentful, recovery design depends on your plan, SSO enforcement and administration model. Confirm the supported route with Contentful before the change. If SSO-exempt organisation owners form part of that route, protect them with strong MFA, named custodianship, alerting and periodic access review. Contentful's own security-check command flags SSO-exempt users whose MFA is disabled.

Do not respond to a failed login by permanently disabling signature verification, removing SSO enforcement or creating a shared administrator account. If a temporary containment step is explicitly approved, time-box it, monitor it, document every action and restore the intended control as soon as service is recovered.

Questions to ask your IT team or support partner

• Which Contentful organisations and SSO connections do we operate?
• Does each identity provider verify Contentful SAML request signatures, encrypt assertions for Contentful, both or neither?
• Can the enterprise application hold the old and new Contentful certificates at the same time?
• What did the metadata import change besides the certificate?
• Who can administer Contentful and the identity provider if this SSO path fails?
• Has that emergency route been tested, protected with MFA and monitored?
• Which user journeys and access policies will be tested after cut-over?
• What logs will identify a signature or encryption mismatch?
• Who has authority to invoke rollback or contact Contentful?
• Where will the next certificate lifecycle date and owner be recorded?

A credible answer includes exported configuration, a selected update path, named owners, a test matrix and recovery evidence. A calendar reminder without configuration evidence is not a cut-over plan.