I have a my software and library working with a couple IDP providers. However I had one that wasn’t working. I was pretty sure it was a cert mismatch but now I have a second one with the same issue. I want to confirm this before I go back to the client to tell them that the cert published in their metadata file doesn’t match the one that they are using to sign. Any Idea why that would be?
This is the pertinent part of the log I think. I stripped out the specific implementation stuff but left in the serial numbers.
entSpace.SAML2 Verbose: 0 : 11468/9: 3/28/2018 9:05:29 AM: Verifying the SAML assertion signature.
ComponentSpace.SAML2 Verbose: 0 : 11468/9: 3/28/2018 9:05:29 AM: Retrieving the signature certificates for the _ configuration partner identity provider _
ComponentSpace.SAML2 Verbose: 0 : 11468/9: 3/28/2018 9:05:29 AM: Loading the X.509 certificate from the file
ComponentSpace.SAML2 Verbose: 0 : 11468/9: 3/28/2018 9:05:29 AM: The X.509 certificate with subject name CN=ADFS Signing - _ and serial number 1136C7547E10589B493A37DBCFD2E7AD has been loaded.
ComponentSpace.SAML2 Verbose: 0 : 11468/9: 3/28/2018 9:05:29 AM: The X.509 certificate with subject name CN=ADFS Signing - _ and serial number 1136C7547E10589B493A37DBCFD2E7AD has been cached.
ComponentSpace.SAML2 Verbose: 0 : 11468/9: 3/28/2018 9:05:29 AM: The X.509 certificate with subject name CN=ADFS Signing - f and serial number 1136C7547E10589B493A37DBCFD2E7AD is being used to verify the XML signature.
ComponentSpace.SAML2 Verbose: 0 : 11468/9: 3/28/2018 9:05:29 AM: Verifying the XML signature.
ComponentSpace.SAML2 Verbose: 0 : 11468/9: 3/28/2018 9:05:29 AM: Failed to verify the XML signature.
ComponentSpace.SAML2 Verbose: 0 : 11468/9: 3/28/2018 9:05:29 AM: Signed XML:
ComponentSpace.SAML2 Verbose: 0 : 11468/9: 3/28/2018 9:05:29 AM: The X.509 certificate with subject name CN=ADFS Signing - and serial number 6E2301DBA06F8B814946672D023A6732 is embedded in the XML signature.
ComponentSpace.SAML2 Verbose: 0 : 11468/9: 3/28/2018 9:05:29 AM: The verifying key type is RSACng.
ComponentSpace.SAML2 Verbose: 0 : 11468/9: 3/28/2018 9:05:29 AM: The verifying key’s associated cryptographic service provider, “Microsoft Software Key Storage Provider”, doesn’t support SHA-256 signatures.
ComponentSpace.SAML2 Verbose: 0 : 11468/9: 3/28/2018 9:05:29 AM: Exception: ComponentSpace.SAML2.Exceptions.SAMLSignatureException: The SAML assertion signature failed to verify.
ComponentSpace.SAML2 Verbose: 0 : 11468/9: 3/28/2018 9:05:29 AM: at ComponentSpace.SAML2.InternalSAMLServiceProvider.VerifySAMLAssertionSignature(Object samlAssertion) in C:\Sandboxes\ComponentSpace\SAMLv20\Library\InternalSAMLServiceProvider.cs:line 443
at ComponentSpace.SAML2.InternalSAMLServiceProvider.GetSAMLAssertion(SAMLResponse samlResponse, XmlElement samlResponseElement) in C:\Sandboxes\ComponentSpace\SAMLv20\Library\InternalSAMLServiceProvider.cs:line 463
at ComponentSpace.SAML2.InternalSAMLServiceProvider.ProcessSAMLResponse(XmlElement samlResponseElement, Boolean& isInResponseTo, String& authnContext, String& userName, SAMLAttribute[]& attributes) in C:\Sandboxes\ComponentSpace\SAMLv20\Library\InternalSAMLServiceProvider.cs:line 792
at ComponentSpace.SAML2.InternalSAMLServiceProvider.ReceiveSSO(HttpRequest httpRequest, Boolean& isInResponseTo, String& partnerIdP, String& authnContext, String& userName, SAMLAttribute[]& attributes, String& relayState) in C:\Sandboxes\ComponentSpace\SAMLv20\Library\InternalSAMLServiceProvider.cs:line 1266
at IDS.assertionconsumer.Page_Load(Object sender, EventArgs e) in _ 31
at System.Web.UI.Control.OnLoad(EventArgs e)
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.ProcessRequest()
at System.Web.UI.Page.ProcessRequest(HttpContext context)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
at System.Web.HttpApplication.PipelineStepManager.ResumeSteps(Exception error)
at System.Web.HttpApplication.BeginProcessRequestNotification(HttpContext context, AsyncCallback cb)
at System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context)
at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)
at System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)
Hi Matthew
The PartnerCertificateFile’s serial number is 1136C7547E10589B493A37DBCFD2E7AD.
The serial number embedded in the XML signature is 6E2301DBA06F8B814946672D023A6732.
These should be the same therefore the wrong certificate is configured.
It’s possible that ADFS has rolled over to a new certificate and they’ve supplied you with old metadata.
You should ask for updated metadata.
Alternatively, you can copy the base-64 encoded string that is the from the XML signature in the SAML log to a text file with a .cer extension and use this certificate file.
You’re welcome to send the complete SAML log file as an email attachment to support@componentspace.com and we can assist with this if required.