Architecture and operating model
In SAML single sign-on, the identity provider (IdP) signs an assertion or protocol message with a private key, and the service provider (SP) validates it with the public key published in metadata. When a certificate expires, the main risk is not the encryption algorithm but the parties using different trust keys at different times. Treat rollover as a measurable transition of distributed trust state.
A zero-downtime method publishes the old and new verification certificates together during an overlap window. Generate the new key and add it to metadata as a second KeyDescriptor; start signing with it only after every SP is proven to have consumed the metadata. Remove the old certificate after the rollback window and the longest metadata cache interval have elapsed.
Do not treat SPs that refresh metadata automatically like applications that require manual certificate upload. Inventory the entityID, metadata URL, refresh interval, fingerprint, owner, test account and emergency rollback route. The SAML signing certificate and the HTTPS server certificate have separate lifecycles; renewing one does not update the other.
- 1Inventory SPs and metadata
- 2Publish the new key as a second verifier
- 3Switch signing to the new key
- 4Retire the old key under change control
Design parameters
- Overlap duration
- It must cover the longest SP metadata cache, the change window and rollback allowance.
- Key custody
- Generate the private key in an HSM, managed key vault or protected IdP store and document its export policy.
- Algorithm and size
- Validate IdP/SP compatibility in a lab; do not infer algorithm support from a certificate label.
- Time accuracy
- IdP, SP and monitoring systems need a common reliable time source for NotBefore, NotAfter and assertion time checks.
Worked example
If 30 of 42 SPs refresh metadata every six hours, eight daily and four are manual, a 24-hour overlap is insufficient by assumption. Keep the old certificate until all four manual owners complete validation; 24 hours of cache, a four-hour change window and eight hours of rollback allowance produce a 36-hour technical minimum.
Roll out to a low-risk application, a noncritical SaaS and then business-critical applications. At each stage test metadata containing both certificates, sign-in with the new signature, rollback to the old signature and rejection of an invalid signature.
Example commands: replace lab values and confirm permissions and software versions before use.
# List verification certificates from metadata
xmlstarlet sel -N md='urn:oasis:names:tc:SAML:2.0:metadata' \
-N ds='http://www.w3.org/2000/09/xmldsig#' \
-t -m '//md:KeyDescriptor[@use="signing"]//ds:X509Certificate' \
-v 'normalize-space(.)' -n idp-metadata.xml
# Inspect dates and fingerprint in a controlled temporary file
openssl x509 -in signing-cert.pem -noout -subject -issuer -dates -fingerprint -sha256Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Some applications reject sign-in | The SP metadata cache may be stale or the product may accept only one certificate. | Obtain the SP’s effective metadata copy and expected fingerprint from its owner. |
| Signature validation failed | The entityID, XML canonicalization or signing key may differ from expectations. | Compare issuer, certificate and signature algorithm in a controlled SAML trace; mask assertion content in logs. |
| Sign-in works intermittently | Nodes behind a load balancer may have different trust stores. | Target each node separately and compare configuration versions and certificate lists. |
Acceptance checks
- Record owner, entityID and metadata refresh method for every SP.
- Validate old and new certificates in the same metadata document.
- Confirm that only the IdP holds the new private key.
- Run successful and invalid-signature tests on at least one pilot SP.
- Monitor sign-in error rate and signature validation events during the change.
- Do not remove the old certificate before the rollback interval ends.
Related concepts
Authentication and sessions
Authentication proves who a user or workload is; authorization determines what that identity may do. Successful sign-in does not grant access to every resource. User sessions, service identities, API tokens and device certificates have different lifecycles. Design session duration, token renewal, employee departure, lost-device handling and emergency access alongside initial sign-in. Measure which existing sessions remain usable and which new access attempts are denied when the identity provider becomes unavailable.
Trust boundary and failure domain
A trust boundary separates components governed by different access decisions; a failure domain groups resources that one event can affect together. Two VLANs do not create a strong trust boundary when routing between them is unrestricted. Backups in different folders still share a failure domain if one administrator can delete both. Assess physical location, identity provider, management account, network path and power source separately. Test which access paths and recovery options remain available when a component is lost.
Version and support lifecycle
Installability does not prove production support. Review the compatibility chain across OS, application, drivers, extensions and management tools. Update plans should record version, support end, restart needs and rollback methods. A test environment that does not reflect production can produce misleading results. Validate service health and existing workflows after a change, not just version numbers. Remember that pinning a version can also prevent future security fixes.
Availability versus recovery
High availability aims to keep service running through specified failures with a short interruption; backup recovers lost or corrupted data from an earlier point. A cluster can replicate an accidental deletion to another node. HA therefore does not replace backup. Consider DNS, identity, network, storage and power dependencies together. Successful node failover is insufficient by itself: measure user sessions, application writes and external integrations after the transition as well.
Telemetry and time correlation
Telemetry combines logs, metrics and events that explain system behavior. A log describes an event, a metric shows behavior over time, and a distributed trace follows a request across components. Clock differences can make one event appear to occur at several times. Use synchronized clocks, reliable source identifiers and consistent time-zone handling. Alarm design should consider duration and user impact alongside thresholds. Monitor gaps in collection separately: absence of logs must not be interpreted as absence of incidents.
TLS and certificate validation
TLS protects confidentiality and integrity in transit; certificate validation helps verify the peer’s identity. Evaluate names, chains, validity periods and trusted roots together. Encryption does not prove correct application authorization. If a reverse proxy or inspection device is used, show where TLS terminates. Disabling validation is not a permanent troubleshooting solution: investigate hostname mismatch, missing intermediate certificates and incorrect device clocks separately.
Primary documentation
Prepared by the Doz Teknoloji technical team using the primary references below. Calculations and lab scenarios state their assumptions; validate the applicable product version before rollout.