Use Cases

Best Practices: PingFederate SAML Signing Certificates

The following reference guide details the best practices for managing PingFederate Security Assertion Markup Language (SAML) signing certificate settings, depending on your partners' preferences.

Component

PingFederate 10.1

What are the best practices for signing certificate administration?

There is no cryptographic difference between self-signed or certificate authority (CA)-signed certificates that use the same algorithm and key-length. From a security perspective, they’re the same, and many customers use self-signed certificates for SAML signing.

The following are some benefits to using self-signed certificates:

  • You can set a longer lifetime, decreasing the amount of update maintenance required.

  • You can use PingFederate’s automatic certificate rotation feature: a new key and certificate pair are periodically generated based on your policy, and active connections in PingFederate using the policy rotate to the new certificate without intervention.

  • If your partners have the ability to monitor and automatically reload your metadata, they are automatically updated. For partners that cannot monitor a metadata URL that you provide, it can require coordination to update.

For more information on managing certificates and certificate rotation, see Manage digital signing certificates and decryption keys in the PingFederate Server documentation.

Although there is no security benefit, your partners might require you to use a certificate issued from a Certificate Authority (CA) for trust reasons. Self-signed certificates do not have a trust chain. If the owner of the CA-signed certificate can have their recipient partners agree to an anchored trust model, this can be a great way to ease the administrative burden. In an anchored trust model, the recipient partner validates that the signing certificate was issued by an expected issuer they trust and that the subject distinguished name matches what is expected. Because the recipient partners validate the trust chain and the expected values, rather than the specific certificate, when a newly-issued certificate is used for signing that meets the same criteria, it passes validation.

Choosing between an anchored or unanchored trust model depends on what your partners support. There is no benefit to partitioning separate certificates for internal or external partners, unless the intention is to use a stronger algorithm or key-length for external partners. One certificate is acceptable if it meets your organization’s security guidelines.

For more information on whether you need a CA-signed certificate for SAML signatures, see Do I need a trusted CA-signed certificate for SAML signatures? in Ping Identity’s support community.

When all of your partners accept a self-signed signing certificate

  1. Create a new self-signed certificate in PingFederate.

  2. Set the validity period for as long as your security team allows. For example, three to five years.

  3. Configure the certificate for certificate rotation with a creation buffer threshold of at least six months before the activation buffer threshold.

    While the next new certificate approaches its expiration, you have six months to coordinate the new certificate transition with partners.

  4. Send your partners the new certificate and document which ones can add it as a secondary decryption key or which ones need a coordinated cutover.

    Inventory any unused service provider connections.

  5. Plan to stagger your cutovers in advance of the existing certificate expiry.

    Schedule your cutovers so that they all do not transition on the same day. This gives you time to test and troubleshoot while managing any amount of connections and minimizes the impact on the users of those applications.

  6. Schedule enough downtime for you and partner to update the changing connection on both sides and to test and roll back, if needed. This ensures your users are not surprised that they cannot access an application and helps them plan accordingly.

    Depending on your certificate rotation policy time settings, a new certificate is created before the current certificate expires, which gives you time to coordinate again.

  7. When the activation buffer threshold is reached, all of your partner connections in PingFederate using that certificate are automatically updated to use the new one, and you do not need to edit each connection yourself.

When your partners require a signing certificate issued by a trusted Certificate Authority

  1. Obtain a new CA-issued certificate with a validity period for as long as the issuer allows.

  2. Send your partners the new certificate and document which ones can add it as a secondary or which ones need a coordinated cutover.

    Take an inventory of any unused service provider connections.

  3. Discuss with your partners if they can and want to use the anchored trust model.

    Document which partners support and configure the anchored trust model. The next time you need to update the CA-issued certificate, there is no action needed from your partners.

  4. Plan to stagger your cutovers in advance of the existing certificate expiry.

    Schedule the cutovers so that they all do not transition on the same day. This gives you time to test and troubleshoot while managing any amount of connections and minimizes the impact on the users of those applications.

  5. Schedule enough downtime for you and partner to update the changing connection on both sides and to test and roll back, if needed. This ensures your users are not surprised that they cannot access an application and can plan accordingly.

Certificate rotation is not possible with CA-signed certificates, so when the new certification expires, repeat this process. You need to manually update each connection in PingFederate and coordinate with your partners that do not use the anchored trust model.