We currently have about thirty SAML federated partners in our production environment and our current SAML signing SSL certificate (defaultenterpriseprivatekey) has an expiration date approaching. Given that we have 30+ number of SAML service providers that we need to coordinate for the switching of our SAML signing certificate, we are seeking for best practice approach or methods to accomplish this with minimum impact or down-time with all of our SAML federated partners.
My first though is to create a new SSL certificate private/public key pair in the policy store and choose one SAML service partner at a time to coordinate the swapping out the SAML signing public certificate and then arrange to do the same with the next SAML service partner at another date. Perhaps there is a better and more simple way of accomplishing this?
This may be a dumb question, but just thought I ask anyway to confirm. I understand that the SAML signing SSL certificate is NOT a server identification certificate so if our current SAML signing certificate expires will the SAML federated SSO connection with our current SAML service provider still work?
Forgot to provide the versioning information:
Policy Server = r12.52 SP1 CR05 RedHat 6
Policy Store = CA Directory Server
This can be implemented in a single window with SAML Partners coordination.
I would suggest to use smkeytool utility to renew the expiring certificate(eg:fedcert) as below:
1. Import new certificate into cert store using SM AdminUI with a new Alias(eg:fedcertnew).2. Rename the existing/expiring cert(eg:fedcert) Alias to some Alias(eg:fedcertexpired) using smkeytool.3. Then rename the new cert(eg:fedcertnew) Alias to the actual Alias(eg:fedcert) using smkeytool.
This approach just swaps the content of the cert under the same alias and you don't have to modify each partnership's manually to switch the certificate. Also you will have to share the renewed cert with SAML Partners and ask them to update it on their end during the maintenance window.
I think our issue/concern is primarily with the coordination of the swapping of the certificate with all of our SAML service partners. We find that it had been difficult to setup a specific time for a maintenance window with some of our federated partners in recent efforts so trying to setup one specific maintenance window time for all 30+ partners would be nearly impossible so in that case a one-time update/renew of the SAML signing certificate would not work unless we can get all thirty partners to agree to make the update on their end at the same time.
To answer your initial question, Federation login will be interrupted, should the signing certificate expires.
Policy Server will fetch and verify the signing certificate validity when signing is required:
Can not sign Assertion with ID: _abc123 Error: Caught an Exception calling signXMLDocument using IXMLSignature. XMLSignatureApacheImpl.signXMLDocument(): Signing certificate has expired. Exception Message: java.security.cert.CertificateExpiredException: NotAfter: Mon Jan 25 03:22:22 PST 2016java.lang.Exception: XMLSignatureApacheImpl.signXMLDocument(): Signing certificate has expired. Exception Message: java.security.cert.CertificateExpiredException: NotAfter: Mon Jan 25 03:22:22 PST 2016at com.netegrity.smkeydatabase.api.XMLSignatureApacheImpl.signXMLDocument(XMLSignatureApacheImpl.java:302)at com.netegrity.smkeydatabase.api.XMLDocumentOpsImpl.signXMLDocument(XMLDocumentOpsImpl.java:1041)at com.netegrity.SAML2Security.DSigSigner.signSAMLEnveloped(DSigSigner.java:308)at com.netegrity.SAML2Security.DSigSigner.signSAMLEnveloped(DSigSigner.java:237)at com.netegrity.assertiongenerator.saml2.ProtocolBase.signOrEncryptAssertion(ProtocolBase.java:325)at com.netegrity.assertiongenerator.saml2.AuthnRequestProtocol.closeupProcess(AuthnRequestProtocol.java:1616)at com.netegrity.assertiongenerator.saml2.AssertionHandlerSAML20.postProcess(AssertionHandlerSAML20.java:262)at com.netegrity.assertiongenerator.AssertionGenerator.invoke(AssertionGenerator.java:382)at com.netegrity.policyserver.smapi.ActiveExpressionContext.invoke(ActiveExpressionContext.java:286)
Understood the challenges with the coordination, we have new enhancement in SSO R12.6 release:
Signing key rollover support using secondary verification certificates—You can configure a secondary verification certificate alias at the IdP and SP to verify the signatures on messages. A remote entity can issue a new verification certificate any time. The reasons can include a key being compromise, certificate expiry, or a change in key size. Specifying a secondary verification certificate eliminates the need to coordinate system-wide updates of signing and verification certificates simultaneously. An entity first tries to verify the message signature with the primary certificate. If the verification fails, the entity uses the secondary certificate for signature verification. The Secondary Verification Certificate Alias field is configurable in the remote IdP and SP configurations and in the Signature and Encryption step of any SAML 2.0 partnership. To aid in troubleshooting, log messages have been added to the Policy Server trace log, smtracedefault.log. Refer to the instructions for configuring an SP-to-IdP partnership to enable these new features.
No secondary certificate option is available for encryption.
I think what Ashok suggested is better way to accomplish (minimize the time engage with different SP) compare to your first thought that arrange different time with different SP.
Both IDP and SP side need to update the certificate in order to get the federation works. Unfortunately, I don't think there is an approach can guarantee no down time for the process. Though we can miminize the down time by having a proper plan.
For your question:
I understand that the SAML signing SSL certificate is NOT a server identification certificate so if our current SAML signing certificate expires will the SAML federated SSO connection with our current SAML service provider still work?
R: Federation will not work as the certificate expired and cannot use to sign SAML assertion thus federation cannot proceed.
Hope this helps.
As Kelly(wonsa03) mentioned, the enhancement handles the condition.
Any certificate that is involved in the federation expires, it will break the federation.
That includes the encryption and decryption certificates.
It would be good if you can submit an "Idea" below:
1. Extend the secondary certificate feature for encryption/decryption
2. AdminUI to popup an alert with a list of certificates that will expire in 3 months(for example). Or send out emails to the administrator with the list and which partnerships involved.
Much thanks for all of your responses, very much appreciated it.
We just upgraded to r12.52 so I don't think the option to sign with secondary certificate is available. We use our Active Directory server as a certificate authority server and can issue SSL certificates. So here's my plan to tackle this issue. We have around 30 SAML service providers out there that has the public key to our current SAML signing certificate which expires in October of next year. We use our Active Directory server as our SSL certificate authority server to sign and generate our own SSL certificates so I have the option to generate a 10 year certificate to be used as our SAML signing certificate and coordinate with one SAML service provider at a time to switch over to the new SAML signing certificate alias. Once all of them are switched to the new certificate then we won't have to worry about this again for another 10 more years.
Thinking long term with this 10 year certificate, should we generate a 256/512/1024/2048 bit certificate for the sake of our SP client's security requirement down the road?
R: This link talk about SSL and RSA might help you.
As per NIST guidelines, using a certificate with long duration for validity is not secure