SharePoint: Quick Troubleshooting TIP: Check SAML token-signing Certificate
When the SAML Identity Provider (ADFS, SiteMinder, Ping Federate, OKTA, etc) token-signing certificate is renewed or rolled over, SharePoint can be in trouble.
This is because there’s currently no functionality in SharePoint to automatically update the certificate within the Trusted Identity Token Issuer on the SharePoint side when it’s been updated on the Identity Provider side.
Suddenly, no one can log in because the cert used to sign the SAML tokens is not the same cert you told SharePoint to trust.
Problems can avoided by manually updating the certificate on the SharePoint side using Set-SPTrustedIdentityTokenIssuer, like in Example 1 here.
However, there can be times when you’ve updated the certificate on the SharePoint side and it’s still not working, so you start to wonder if your Identity Provider is really using the certificate you expect.
You don’t have to assume. You can find out which certificate is being used with a simple Fiddler trace.
First, clear your browser cache and cookies to make sure the entire authentication process is captured in Fiddler.
Then, start Fiddler and configure it to decrypt SSL: http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/DecryptHTTPS
Then browse your SAML authentication SharePoint site and attempt to log in.
Find the SAML assertion within the Fiddler trace.
The way this looks in the Fiddler trace will vary, depending on the configuration of your SAML Identity Provider. However, you will typically see a redirection from your SharePoint site to your SAML provider, and then back to your SharePoint site. It’s the requests to the SAML provider that we’re interested in. If you’re unsure about your SAML provider endpoint, you can check on the SharePoint side with this PowerShell:
Get-SPTrustedIdentityTokenIssuer | select provideruri
Example:
In my example, I’m using ADFS, and my provider URI is “https://adfs.joroar.local/adfs/ls/” so I’m looking for requests to that in the Fiddler trace.
If I find those requests and look at the “TextView” tab of the server response (lower right-hand pane in Fiddler), I should be able to find one with a SAML assertion.
Click the “View in Notepad” button to open the SAML assertion in Notepad.
Search for “x509certificate” and copy all of the text between the “x509certificate” tags.
Paste that into a new Notepad file and save it with a “.cer” file extension.
Open the .cer file. It should open in the familiar certificate format.
Then you can easily check the Details tab for the thumbprint, validity dates, etc.
Now we know, without a doubt, which certificate the Identity Provider is using to sign the SAML assertions (tokens) with. This certificate must match the one SharePoint is configured to accept, which you can double-check with this PowerShell:
Get-SPTrustedIdentityTokenIssuer | select SigningCertificate | fl
Example:
