SAML certificates explained: How they work and how to manage them

In SAML, there are two main parties: the Identity Provider (IdP), which verifies who the user is, and the Service Provider (SP), which gives the user access to an application. They exchange information through XML messages, but for these messages to be trusted, they need to be protected. That’s where SAML certificates come in.

These certificates, based on the X.509 standard, act like digital keys. They let IdPs and SPs prove the messages really came from them (signing) and, when necessary, keep sensitive data private (encryption and decryption). Without certificates, there would be no reliable way for one side to know that the other is genuine.

In this article, we will explain how SAML certificates work, what makes signing and encryption certificates different, and how they are structured. We will also cover common mistakes such as expired or mismatched certificates and share best practices to keep your SSO flows secure and reliable.

What are SAML certificates?

In SAML, a certificate is almost always an X.509 certificate, which is the universal standard for encoding and exchanging public key certificates. X.509 is the foundation of public key infrastructure (PKI) and is widely used to secure websites, authenticate users, and encrypt data.

An X.509 certificate:

• Binds a public key to an identity, such as an individual, organization, or system.
• Contains details like the issuer, subject, validity period, and cryptographic algorithms.
• Is digitally signed, either by itself (self-signed) or by a trusted Certificate Authority (CA).

X.509 certificates are used in many contexts. such as securing websites with TLS/SSL, authenticating users, and encrypting data.

In the context of SAML, X.509 certificates are used to:

• Sign messages so that recipients can verify their authenticity and integrity.
• Encrypt assertions so that sensitive data is only readable by the intended party.‍
• Establish trust between Identity Providers (IdPs) and Service Providers (SPs), often through metadata exchange.

!!A SAML assertion is an XML message that carries authentication and authorization data and is exchanged between an IdP and an SP. For more details, see What are SAML assertions?!!

Without certificates, there would be no way for either side to confirm that a SAML response truly came from its trusted partner.

Types of SAML certificates

There are two main types of SAML certificates: signing certificates and encryption certificates. Each one plays a unique role:

• Signing certificates are used to prove the authenticity of SAML requests, responses, and assertions.
• Encryption certificates are used to protect sensitive data within the assertions, so only the intended recipient can read it.

Signing certificates are the most commonly used type in SAML. The most common scenario is:

1. The SP will initiate a request.
2. The IdP will generate and sign the response with their private key and send it to the SP.
3. The SP will verify the signature using the public SAML certificate of the IdP (included in the message).

Some IdPs may require or provide the option to use a SAML signing certificate for the SAML request as well. In these cases, the IdP verifies the authenticity of the SAML request.

How do SAML certificates work?

Here’s how certificates are used during a typical SAML login flow:

1. The SP initiates a SAML flow when the user tries to log in by sending a SAML request to the IdP. SPs may sign authentication requests to IdPs.
2. If the auth request is signed, then the IdP verifies it using the SP’s public key (from the SP’s signing certificate).
3. The IdP authenticates the user, compiles the SAML Response, and signs it with the IdP’s private key. Here is how signing works:
   
   1. The IdP generates a cryptographic hash of the assertion’s content and encrypts that hash with its private key.
   2. This digital signature is attached to the message.
   3. The corresponding public key is embedded in the signing certificate and shared with the SP.
4. If the assertion contains attributes such as personal details or authorization statements, the IdP might use the SP’s encryption certificate (its public key) to encrypt those elements. Only the SP can decrypt with its private key.
5. When the SP receives the signed assertion, it uses the IdP’s public key to decrypt the signature. The SP recomputes the hash of the assertion and compares it to the decrypted value. If they match, the assertion is authentic and untampered.
6. After that, the user is authenticated. If there is encrypted data, the SP decrypts using their private key.

!!Note that during the initial setup of a SAML connection, the IdP and SP carry out a metadata exchange. In this step, they share XML files with details such as endpoints and certificates, which establish the trust used in later login flows.!!

Although less common, SPs can also use encryption certificates to protect sensitive data they send back to IdPs.

Some organizations use a single certificate for both signing and encryption, though best practice is to separate them for stronger security and easier key management.

Structure of a SAML certificate

Certificates are Base64-encoded and usually shared in PEM format:

  
-----BEGIN CERTIFICATE-----
MIIDezCCAmOgAwIBAgIESSFi0jANBgkqhkiG9w0BAQsFADBLMRMwEQYDVQQDEwpF
eGFtcGxlIENBMR0wGwYDVQQKExRFeGFtcGxlIE9yZ2FuaXphdGlvbjEPMA0GA1UE
BhMGVVMgICAgMB4XDTIzMDEwMTAwMDAwMFoXDTI0MDEwMTAwMDAwMFowSzETMBEG
A1UEAxMKZXhhbXBsZS5jb20xHTAbBgNVBAoTFEV4YW1wbGUgT3JnYW5pemF0aW9u
MQ8wDQYDVQQGEwZVUyAgICAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCvHhMzB9O/dPwfDM1k7vV9XjY4NWwMKr4Sxm6ftWQfLOurwjLgZmrwxWRbYsEz
9zrXfN3ZY2ic0EtP6yMtZIjM0u/rHLsjR8+8VEWm1ZjU/YjxMdzLOiIZ+CrXE8Zy
5SZp8ZMiyRjODKGTVVWUVS1YTOhpd6dVvj5LZhZHi1vcRClV3E9i5hVz1y0tXo6X
5EXFcZMRR2YhMWZx+EzLjh8IXvRDVhXzjz3eO/VKhC6c7xvLOYXtHgW1BPmgD9GG
QVXuWmPjYEh40lDZjq1ZtkHBgUdWy5ufQV+w9sxSoZyWAMi3OEeXq9+/zE4+KRyE
oN8+wlYFSl93Tqr1nFnZAgMBAAGjYDBeMAsGA1UdDwQEAwIEsDAeBgNVHREEFzAV
gg1leGFtcGxlLmNvbYIKZXhhbXBsZS5zZTAdBgNVHQ4EFgQU5U7+J4YXyM8Ybzw8
lhG3o3X6jGIwDAYDV0TBAUwAwEB/zANBgkqhkiG9w0BAQsFAAOCAQEATYjOmIwP
+9d5KwdspGPhIcLjFfEcLUjfQmBL5uUhMbGdOdgiQehnpyA7LWVylQEURv4nEwXe
3+YtjKU3MdHNvRumOOMqoUiexIVIuD1UyJFM2O+2PqZ90zvyUcwOZ4KZFsI/G4M2
-----END CERTIFICATE-----
  

This is a text-based representation of the certificate, which we can decode to view details like the subject, issuer, validity period, and the public key.

Here’s an example of a decoded, human-readable X.509 certificate. This is what you would see if you run a PEM certificate through a tool like openssl x509 -in cert.pem -text -noout:

  
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1234567890 (0x499602d2)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=Example CA, O=Example Organization, C=US
        Validity
            Not Before: Jan  1 00:00:00 2023 GMT
            Not After : Jan  1 00:00:00 2024 GMT
        Subject: CN=example.com, O=Example Organization, C=US
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:af:1e:...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: 
                Digital Signature, Key Encipherment
            X509v3 Subject Alternative Name: 
                DNS:example.com
    Signature Algorithm: sha256WithRSAEncryption
         4d:88:...
  

• Version: Indicates which version of the X.509 standard the certificate follows. Version 3 is common for SAML because it supports extensions like Key Usage.
• Serial Number: A unique identifier assigned to the certificate by its issuer. Used for revocation or tracking.
• Signature Algorithm: The algorithm used to sign the certificate (here, SHA-256 with RSA).
• Issuer: The Certificate Authority (CA) or entity that issued the certificate. If it’s self-signed, the issuer and subject are the same.
• Validity: The time window during which the certificate is valid. Expired certificates are one of the most common causes of SAML failures.
• Subject: The entity the certificate belongs to, such as an IdP or SP.
• Subject Public Key Info: The public key and algorithm. This key is used by the other party to verify signatures (for signing certificates) or to encrypt data (for encryption certificates).
• X509v3 Extensions: Extra information about how the key can be used. For SAML, common values include Digital Signature (for signing) and Key Encipherment (for encryption). Subject Alternative Name lists additional identities.
• Signature: The digital signature that proves the certificate was issued by the stated issuer.

!!Most SAML connections do not require a CA-signed certificate. In practice, self-signed certificates are widely accepted because trust is established through metadata exchange between the IdP and SP. Some organizations or compliance rules may require CA-signed certificates, but this is the exception rather than the norm. For more see, CA-Signed Certificates in SAML.!!

Managing SAML certificates

All certificates have a validity period. Once a certificate expires, signatures created with it are rejected. This means if an IdP forgets to rotate its signing certificate, or an SP does not update the metadata with a new certificate, users will suddenly lose the ability to log in.

Rotation is not only about expiration, though. Organizations may rotate keys earlier for security policies, to move to stronger algorithms, or in response to a potential compromise.

Who manages what

• Identity Providers (IdPs) generate and control the signing certificates used to sign SAML responses and assertions. If the IdP encrypts attributes, it also manages the encryption keys.
• Service Providers (SPs) must store the IdP’s public certificates in order to verify signatures. If the SP signs authentication requests, it also manages its own signing certificate and private key. SPs also provide their encryption certificates so IdPs can encrypt assertions for them.
• Federation platforms like WorkOS often sit between IdPs and SPs, simplifying this process. They can automate metadata refresh, support multiple active certificates during rotation, and provide expiration alerts before a certificate causes an outage.

Best practices for managing certificates

• Track expiration dates: Keep an inventory of all active certificates and their expiration dates. Set alerts at 90, 60, and 30 days before expiration so you always have time to rotate without impacting users.
• Use overlapping certificates: During rotation, publish the new certificate while keeping the old one active. This overlap period allows both certificates to be valid at the same time, so partners can update metadata without downtime. Remove the old certificate only after confirming the new one is in use.
• Automate metadata refresh: Whenever possible, configure IdPs or SPs to pull updated certificates automatically from a metadata URL. This eliminates manual steps and reduces the chance of human error during certificate updates.
• Separate signing and encryption keys: Some systems allow one certificate to be used for both roles, but it is better to separate them. This makes rotation easier and reduces security risks if one key is ever compromised.
• Secure private keys: Always store private keys in secure environments such as a hardware security module (HSM) or a managed key vault. Limit access to them as much as possible. If a private key is exposed, attackers could forge or decrypt SAML assertions.
• Test in staging before production: New certificates should be validated in a staging or test environment before being rolled out. This helps catch issues like incorrect formats (PEM vs DER) or misconfigured usage settings before they affect real users.
• Communicate changes early: Certificate updates almost always involve coordination between an IdP and an SP. Notify partners well in advance of upcoming rotations, share updated metadata, and align on a timeline to avoid mismatches.
• Log and alert on verification failures: Set up monitoring for signature verification and decryption errors. Alerts can help you detect problems like expired certificates or mismatches before they impact all users.

Both IdPs and SPs are accountable for keeping certificates valid and trusted. If either party fails to update metadata or rotate in time, authentication will break. Using a federation platform like WorkOS or building automation around certificate rotation is the most reliable way to keep SAML integrations running smoothly.

For more on this topic, see Managing SAML X.509 Certificates.

Common SAML certificate errors

Even small certificate misconfigurations can break SAML logins. The challenge is that most SAML toolkits and platforms produce vague error messages, which makes troubleshooting difficult. Below are the most common issues that lead to authentication failures:

• Expired certificates: Every certificate has a defined validity period (Not Before and Not After dates). If the certificate has expired, the receiving party will reject it. This is one of the leading causes of sudden login failures in production systems.
• Metadata not updated: When a certificate is rotated, the new certificate must be shared in updated metadata. If an SP or IdP is still using old metadata, it will not recognize the new certificate and will reject signed or encrypted messages.
• Wrong certificate uploaded: Sometimes, the wrong certificate is provided altogether. For example, an administrator may upload a staging certificate to production, or mistakenly provide an encryption certificate instead of a signing certificate. Since the key pair does not match, verification fails.
• Rotation errors: During certificate rotation, both the old and new certificates should remain valid for an overlap period. If the old certificate is removed too early, partners still relying on it will be unable to validate messages, causing outages.
• Incorrect formats: Certificates come in different encodings, such as PEM (Base64 with -----BEGIN CERTIFICATE-----) and DER (binary). Uploading the wrong format, or pasting a PEM incorrectly (extra spaces, missing headers), often leads to parsing failures.‍
• Clock skew: If the system clocks of the IdP and SP differ, a certificate might appear to be “not yet valid” or “already expired” even when it is within its validity period. Time synchronization (for example, using NTP) is critical in distributed systems like SAML.‍
• Encryption mismatches: Encryption errors occur when the IdP encrypts assertions with one key but the SP attempts to decrypt with another, or when the wrong encryption certificate is configured. This prevents the SP from accessing user attributes, blocking authentication or authorization.

Keep in mind that these issues typically manifest as generic “invalid signature,” “cannot decrypt,” or “unknown certificate” messages, which provide little context. Because of this, proactive monitoring and alerting on certificate lifecycles, along with clear rotation processes, are essential to keeping SAML integrations reliable.

!!For more on how to debug SAML assertions, see our debugging guide.!!

Final thoughts

SAML certificates may seem like a small piece of the federated identity puzzle, but they are often the single point of failure for trust between providers. Understanding how they work, preparing for common errors, and following best practices for rotation and management are key to keeping SSO both reliable and secure.

Whether you use self-signed certificates or ones issued by a Certificate Authority (CA), the most important factors are proactive monitoring, smooth rotations, and clear coordination between partners. This is exactly where WorkOS can help. By automating metadata refresh, managing certificate lifecycles, and providing expiration alerts, WorkOS takes the complexity out of certificate management and reduces the risk of downtime. With the right platform in place, your users can enjoy seamless Single Sign-On without ever needing to think about certificates.

Sign up today.

FAQ

What is the difference between a SAML request signing certificate and a SAML response signing certificate?

• SAML Response Signing Certificates are the most common in SSO setups and are used by IdPs to sign SAML Responses.
• SAML Request Signing Certificates are required by some IdPs as an extra security measure and are used by SPs to sign AuthnRequests. While not always mandatory, request signing adds protection against tampered authentication requests.

What is the difference between a SAML signing certificate and a SAML encryption certificate?

• Signing certificates ensure messages are authentic and untampered.
• Encryption certificates ensure sensitive data (like user attributes) stays confidential.

Many deployments only use signing, but encryption is recommended if sensitive personal or financial information is transmitted.

What are SAML signing certificates, and how do they work?

SAML signing certificates are used to prove that SAML requests and responses come from a trusted source and have not been tampered with. The IdP (and sometimes the SP) signs messages with its private key, and the recipient verifies them using the public key from the certificate.

What are SAML encryption certificates, and how do they work?

SAML encryption certificates protect sensitive data inside SAML assertions. The IdP encrypts data with the SP’s public key, and only the SP can decrypt it with its private key.

Do I need a Certificate Authority (CA)-signed certificate for SAML?

Not usually. In SAML, trust is established by exchanging metadata that includes certificates, so both sides explicitly agree which certificates to trust. Because of this, self-signed certificates are often sufficient and far easier to manage.

However, there are cases where CA-signed certificates may be required:

• Compliance requirements: Some industries mandate the use of CA-signed certificates to satisfy audit or regulatory frameworks.
• Policy enforcement: Certain organizations enforce stricter security policies and only allow CA-issued certificates.
• Trust anchoring: CA-signed certificates can help when multiple parties need a shared root of trust instead of managing direct certificate exchanges.

The trade-off is that CA-signed certificates add cost and operational overhead, while self-signed certificates are free and simple. Unless there is a specific requirement for CA-signed certificates, most SAML integrations work well with self-signed ones.