Extracting the correct certificate from Metadata file

We are using the ComponentSpace.SAML2.Net library version for SSO as a Service Provider in our application for 2 years. Everything is working fine except for some minor bugs which we have resolved in the past.
The only issue that remains to be resolved is that whenever the certificate rollover happens at the Identity Providers’ end, we need to update the latest certificate with the expired one at our end also so that the SSO is not affected. Until now we have been updating the certificates manually whenever they were expired. Now we want to do this automatically. We have created another standalone console application that would run once daily off-hours and use the IdP’s metadata URL, it extracts the certificate and replaces the old one stored at our end. But we are facing 2 major problems in this:

  1. According to our knowledge, the new certificate gets created 20 days before the old one gets expired and the metadata contains both these certificates during this time period. But the new certificate becomes the Primary certificate AFTER 5 days of its creation at the Identity Provider. Our standalone application extracts and replaces the latest certificate on the very first day it gets created but because it has not yet become the Primary certificate, the SSO authentication fails. Now we are assuming that the 20 days period and the 5 days gap are configurable at the IdP’s end, so we are not hard coding these values in our application and want something generic that would work for all the IdPs. We are unsure of how to proceed and have a generic solution so that it works for all the IdPs.
  2. Even if we replace the old certificate file with a new one, our web application (working as a Service Provider) still loads the old certificate from its cache unless we recycle the App Pool of our web application. Is there a cleaner way to trigger a reload of the certificate in our Service Provider web application?
Please help us resolve the above 2 issues. I am attaching a sample metadata file with the 2 certificates for your reference.


Please note the following only applies to earlier releases such as v2.8.8. In later releases we improved the syntax.

In your configuration you can specify a PartnerCertificateFile and a SecondayPartnerCerrificateFile.

When verifying signatures, the PartnerCertificateFile is first tried. If that fails, the SecondayPartnerCerrificateFile is tried.

I think configuring both the old and new certificates as the PartnerCertificateFile and a SecondayPartnerCerrificateFile should resolve both issues.

I also support contacting sales@componentspace.com to discuss options for upgrading to the latest release.

Thanks for your reply. I will apply the solution you have proposed. Will inform you if I face any other problem during this.
I will also ask concerned authorities at my place to consider upgrading to the latest release.

Thanks again.

Sounds good. Thanks.

Regarding upgrading to the latest release, currently, our web application is targeting the .NET framework version 4.5 and we are hesitant to upgrade to a newer framework due to some of the dependencies on other libraries used in the project. Could you please confirm if we can upgrade to ComponentSpace’s latest release without updating our targeting framework? Also, if our company later decides to upgrade to the latest .NET framework, can we use the same ComponentSpace DLL or would we need to upgrade the DLL again?


The latest release supports .NET framework v4.5. In fact, it supports all .NET framework versions from .NET 2.0 to the latest. The NuGet package contains SAML DLLs targeting .NET framework versions 2.0, 4.0 and 4.6.2 and 4.8. The package manager will automatically pick the most appropriate version depending on the .NET framework version your application targets. So, if you’re targeting 4.5 it will use the SAML DLL that targets 4.0. If later you move up to 4.8 it will use the SAML DLL that targets 4.8. There are only relatively minor differences in the SAML DLLs targeting 4.x. There are no differences in the SAML API.