I have a saml.config based configuration, a certificate that’s expiring soon, and new one in hand.
Am I correct to assume that the Secondary and Tertiary Certificate configuration options are for handling certificate expiration issues on the SP and IdP sides? I found nothing in the Developer Guide, or in the forums that addresses the use cases for these certificates, or how they are processed during inbound or outbound SSO.
Let’s consider the inbound SSO first. (These are unsolicited SAML Responses from a partner IdP to my site.) If I add the SecondaryLocalCertificateFile in my stanza, can I support (A) incoming SSOs from partners still using my old certificate, and (B) incoming SSOs from partners who have updated on their side to use my new certificate? Does the toolkit try signature verification with the primary certificate first, then the secondary, etc?
Now the outbound case, where my site is the IdentityProvider. I have, say, 20 service providers to whom I send unsolicited SAML Responses. How can I handle the certificate update here? Do I add the SecondaryLocalCertificateFile setting to my stanza? (That didn’t throw an exception when I tried it.) Then, how do I configure each to identify which certificate to use to sign the Response? PartnerCertificateFile is the partner’s certificate used for encryption, so I know it’s not that. Is it LocalConfigurationFile?
These are guesses, though. I would appreciate any guidance on how this all works, or a pointer to some documentation that addresses certificate expiration using the toolkit.
PartnerCertificateFiles are used when verifying signatures on message received from a partner provider.
The signature verification will be first attempted using the PartnerCertificateFile, then the SecondaryPartnerCertificateFile and finally the TertiaryPartnerCertificateFile.
This supports the scenario where the partner is rolling over their certificate.
LocalCertificateFiles are used when generating signatures on message sent to a partner provider.
Only the LocalCertificateFile will be used. The SecondaryLocalCertificateFile and TertiaryLocalCertificateFile will not be used.
However, you can specify the LocalCertificateFile on the or but also the or .
If the LocalCertificateFile is specified on the or then it will be used for generating signatures on message sent to that partner provider.
If there is no LocalCertificateFile specified on the or , the LocalCertificateFile specified on the or will be used for generating signatures on message sent to that partner provider.
This supports the scenario where the local certificate is rolling over in a staged manner.
The signature verification will be first attempted using the PartnerCertificateFile, then the SecondaryPartnerCertificateFile and finally the TertiaryPartnerCertificateFile.
This supports the scenario where the partner is rolling over their certificate.
LocalCertificateFiles are used when generating signatures on message sent to a partner provider.
Only the LocalCertificateFile will be used. The SecondaryLocalCertificateFile and TertiaryLocalCertificateFile will not be used.
However, you can specify the LocalCertificateFile on the or but also the or .
If the LocalCertificateFile is specified on the or then it will be used for generating signatures on message sent to that partner provider.
If there is no LocalCertificateFile specified on the or , the LocalCertificateFile specified on the or will be used for generating signatures on message sent to that partner provider.
This supports the scenario where the local certificate is rolling over in a staged manner.
I read this to mean that the <IdentityProvider> and <ServiceProvider> don't have to specify a certificate file at all, as long as every <PartnerIdentityProvider> and <PartnerServiceProvider> is configured with a LocalCertificateFile. (And optionally, a SecondaryLocalCertificateFile and TertiaryLocalCertificateFile for <PartnerIdentityProviders>.)
Therefore, any certificates defined in <IdentityProvider> and <ServiceProvider> are defaults, used only when the <PartnerIdentityProvider> and <PartnerServiceProvider> don't specify certificate files for inbound signature verification or outbound signature generation.
Is that it?
That’s correct.
If the LocalCertificateFile is configured on each of the or entries then it doesn’t have to be specified on the or . They are essentially defaults.
The LocalCertificateFile is for outbound signature generation.
The PartnerCertificateFile etc is for inbound signature verification.
Thank you very much.
You’re welcome.
For version 2.8.8 do you support a SecondaryLocalCertificateFile in the configuration section?
Yes, this is supported in v2.8.8.
I see you note what it is supported to use SecondaryLocalCertificateFile attribute for the ServiceProvider configuration. However, when I try this, I keep getting error about incorrect network password specified but when I use a single cert reference, the password is fine and everything works. I tried to set SecondaryLocalCertificatePassword but still same error. Do you know if I am referencing the wrong attribute name for the secondary cert password?
That’s the correct attribute name.
Just to confirm, there are no issues with the LocalCertificateFile/LocalCertificatePassword but you get an error with the SecondaryLocalCertificateFile/SecondaryLocalCertificatePassword?
If you swap these around (ie specify the secondary file/password as the primary and vice versa) does the error now occur with the primary?
Just to confirm, there are no issues with the LocalCertificateFile/LocalCertificatePassword but you get an error with the SecondaryLocalCertificateFile/SecondaryLocalCertificatePassword?
If you swap these around (ie specify the secondary file/password as the primary and vice versa) does the error now occur with the primary?
The incorrect password always occurs with the secondary file/password
Thanks for the confirmation.
Please enable SAML trace and send the generated log file as an email attachment to support@componentspace.com mentioning your forum post.
https://www.componentspace.com/Forums/17/Enabing-SAML-Trace
Hello, Is SecondaryPartnerCertificateThumbprint supported in a saml.config configuration for a rolling over certificate? I’ve tried this below with no luck.
PartnerCertificateStoreLocation=“CurrentUser”
PartnerCertificateThumbprint=“newcert”
SecondaryPartnerCertificateThumbprint=“oldexpiringcert”
However, this below does work.
PartnerCertificateFile=“SAML/newcert.cer”
SecondaryPartnerCertificateFile=“SAML/oldexpiringcert.cer”
Thank you for any info you can provide on using secondary thumbprint or remote files.
It should work.
If the secondary certificate is under the current user certificate store you also need to specify SecondaryPartnerCertificateStoreLocation=“CurrentUser”.
If there’s still an issue, please enable SAML trace and send the generated log file as an email attachment to support@componentspace.com.
https://www.componentspace.com/Forums/17/Enabing-SAML-Trace
If the secondary certificate is under the current user certificate store you also need to specify SecondaryPartnerCertificateStoreLocation="CurrentUser".
If there's still an issue, please enable SAML trace and send the generated log file as an email attachment to support@componentspace.com.
https://www.componentspace.com/Forums/17/Enabing-SAML-Trace
Well that makes sense. Thank you. I overlooked missing SecondaryPartnerCertificateStoreLocation. Thanks again :)
You’re welcome. 