Forums

My previous CERT is expiring at the end of this week so any help to the below would be greatly appreciated.


For my SP Initiated SSO, the top of my saml.config files looks as such.

<ServiceProvider Name="https://mycompany.net"
       Description="Service Provider"
       AssertionConsumerServiceUrl="~/Authentication/SAML/AssertionConsumerService.aspx"
     LocalCertificateSerialNumber="‎######"/>

----------------

I recently updated my webserver https cert, as the old one was expiring. (was planning to execute the rollover steps)

I updated the LocalCertificateSerialNumber to the new serial in my above SAML stanza.

I DELETED the old cert from my server and rebooted. (i did this as test with a plan to restore).

My expectation was that my SP Initiated SSO to my partner IDPs would fail.  I thought they would have to update their side with my public cert of my new https service.

I thought LocalCertificateSerialNumber was my "signing" cert and they would have to have the public cert to receive and decrypt.

My questions is, when i executed the above, expecting it to fail because my IDPs havent yet received my new pub cert; it didn't fail. 
I could sign into my IDPs using test accounts and authenticate and pass-through.

Why would that be; do I not understand the signing cert?

I would love to not have to work with each individual customer to make sure they update their side with my pub cert, but I thought I had to give them the new public cert that's defined in my SAML stanza above....
(note i want to be secure, but also looks like it's not necessary to sign the request i'm sending)

Trying to make sure that once the expiration date hits on my previous cert, im not going to have chaos with my clients not being able to sign in....

Thanks in advance,

Boyd

(sidenote: I did purge my trace file and look at it after signing in, and confirmed it's using my new serial ##, the old one i removed looks gone)

Hi Boyd,

The local certificate is used to sign SAML messages sent to partner identity providers and decrypt SAML assertions.

In many scenarios SAML assertions aren't encrypted so this isn't applicable.

The SAML authn request sent to the identity provider is signed if SignAuthnRequest="true" is configured for the <PartnerIdentityProvider>. Even if the authn request is signed, the identity provider may ignore the signature if it isn't configured to verify its signature.

I suggest checking your configuration to see if SignAuthnRequest="true" has been specified for any of the identity providers. You might also want to check with the identity providers to see if they are expecting authn requests to be signed. If you're supporting SAML logout, the same applies to signing SAML logout requests and responses.

Also, the Configuration Guide explains how you can roll out a new certificate to individual identity providers rather than all at once. This is done by specifying the local certificate configuration at the <PartnerIdentityProvider> level. This might be useful rather than attempting to coordinate the certificate update with all identity providers at the same time. 

Regards
ComponentSpace Development

Thanks for your support.  
Do I understand correctly,   within the Service Provider stanza, the LocalCertificateSerialNumber, WOULD be used to sign my request, IF my PartnerIdentityProvider stanza had SignAuthnRequest="true", which I don't have in any of my provider stanzas. 

What purpose does LocalCertificateSerialNumber serve in my service provider stanza if I'm not encrypting or signing the request?


This is my server certificate on my web server that I've already updated. 

 I had no problems this week, BUT I do see a client tonight having trouble sigining in tonight in the logs.  It may be completely unrelated but timing has me concerned as the original server CERT was set to expire today.


Anticipate I'll get a call from them tomorrow, unable to sign in.

Heres the trace file, not sure if you can illicit anything from it....

ComponentSpace.SAML2 Verbose: 0 : 6940/7: 11/8/2022 1:47:32 AM: Verifying the XML signature.
ComponentSpace.SAML2 Verbose: 0 : 6940/7: 11/8/2022 1:47:32 AM: XML signature verification was successful.
ComponentSpace.SAML2 Verbose: 0 : 6940/7: 11/8/2022 1:47:32 AM: The SAML response signature verified.
ComponentSpace.SAML2 Verbose: 0 : 6940/7: 11/8/2022 1:47:32 AM: Exception: ComponentSpace.SAML2.Exceptions.SAMLErrorStatusException: An error SAML response status was received. urn:oasis:names:tc:SAML:2.0:status:Responder
ComponentSpace.SAML2 Verbose: 0 : 6940/7: 11/8/2022 1:47:32 AM:  at ComponentSpace.SAML2.InternalSAMLServiceProvider.ProcessSAMLResponse(XmlElement samlResponseElement, Boolean& isInResponseTo, String& authnContext, String& userName, SAMLAttribute[]& attributes)
 at ComponentSpace.SAML2.InternalSAMLServiceProvider.ReceiveSSO(HttpRequest httpRequest, Boolean& isInResponseTo, String& partnerIdP, String& authnContext, String& userName, SAMLAttribute[]& attributes, String& relayState)
 at AutismPro.Classroom.SAML.AssertionConsumerService.Page_Load(Object sender, EventArgs e) in C:\Users...\Authentication\SAML\AssertionConsumerService.aspx.cs:line 22
 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.ExecuteStepImpl(IExecutionStep step)
 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)
 at System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr pHandler, RequestNotificationStatus& notificationStatus)
 at System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr pHandler, RequestNotificationStatus& notificationStatus)
 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)


Thanks again

Your understanding is correct. The certificate identified by LocalCertificateSerialNumber will not be loaded if SAML messages aren't to be signed or SAML assertions decrypted.

The SAMLErrorStatusException isn't directly related. This exception is thrown if the identity provider sends a SAML response with an error status. The identity provider should be able to look at their logs for more specific error details.

I suggest sending your SAML log file as an email attachment to [email protected]. We 'd like to see the full SSO flow including the calls to SAMLServiceProvider.InitiateSSO and SAMLServiceProvider.ReceiveSSO so we can check everything looks ok on your service provider side. Also include your saml.config with any passwords removed.

Regards
ComponentSpace Development