IdP / SP Certificates Basics
SAML relies on X.509 certificates for signing and encryption. Learn the roles and operational tips to avoid outages during rotation or revocation.
🔑 Roles of Certificates
Signing and encryption have different purposes. KeyDescriptor in metadata indicates their use.
Use cases
| Item | Description |
|---|---|
| Signing | Validates SAML Response/Assertion integrity and issuer. SP verifies with the IdP signing cert. |
| Encryption | Protects attributes via Encrypted Assertions. Encrypt with SP public key, decrypt with SP private key. |
| Placement | IdP provides signing certs in metadata. SP provides its certs in metadata for signing/encryption. |
How IdP certificates are used
- 🧭 IdP signs Response/Assertion; SP verifies with the IdP public key.
- 🧭 Mostly for signing on the IdP side; encryption typically uses the SP public key.
- 🧭 Publish under use="signing" in metadata; during rotation, list old/new in parallel.
How SP certificates are used
- 🧭 IdP encrypts Assertions with the SP public key for confidentiality.
- 🧭 If SP signs LogoutRequest, it uses its private key; IdP verifies with SP public key.
- 🧭 Include the SP public key in metadata with use="signing" / use="encryption" as needed.
🧭 Operational Tips
Define how you rotate and check certs to avoid certificate-related outages.
Rotation
- Publish old and new certs in parallel before expiry to allow a grace period.
- Update metadata first and keep IdP/SP in sync.
- If key pinning is used, mind the rollout order.
Revocation checks
- CRL/OCSP applicability depends on the trust model. Direct trust in metadata keys is different from PKI certificate validation.
- Keep clocks synchronized and check assertion and metadata validity.
- Separate test and production certs to avoid mix-ups.
📑 Handling in Metadata
Metadata is the source of truth between IdP and SP; verify usage and validity regularly.
Checks
- KeyDescriptor use matches the purpose; omission indicates both signing and encryption.
- Certificate validity period and Subject/Issuer are as expected.
- ds:X509Certificate contains Base64 certificate data without PEM BEGIN/END lines.
Signed metadata handling
Per the OASIS metadata spec, verify the metadata signature and distribute it over a trusted channel.
- Validate signed metadata using a previously trusted key. Unsigned metadata still requires an agreed secure distribution and authenticity check.
- Keep the download URL stable and validate signatures periodically to detect tampering.
- Ensure entityID uniqueness and avoid mixing unintended entities.
🧾 Required vs Optional Usage
Decide the baseline checks as mandatory and apply optional ones based on your security posture.
Required (effectively required)
- Verifying IdP-signed Response/Assertion with the IdP signing certificate
- Securely provision signing keys using metadata or a supported manual configuration
Depends on requirements (optional/recommended)
- Encrypt Assertions when attributes must be hidden from browser intermediaries or policy requires it; this does not replace TLS
- Signing SP-issued messages (AuthnRequest/LogoutRequest); sometimes required by policy
- Apply certificate expiry and revocation policy according to the selected trust model and product
Specifications and related guides
OASIS SAML metadata / OASIS Metadata Interoperability Profile. Under the Metadata Interoperability Profile, accepted metadata keys are not subject to additional certificate expiry or CRL/OCSP checks. Remove compromised keys from metadata and propagate updates. Keep this separate from TLS server certificate validation.
Related SAML guide