Recently I was dealing with a case where the site say https://www.test.contoso.com/ which was working fine on a Windows Azure Web Role leveraging ACS for authentication started failing with the following error.
Server Error in ‘/’ Application.
ID4175: The issuer of the security token was not recognized by the IssuerNameRegistry. To accept security tokens from this issuer, configure the IssuerNameRegistry to return a valid name for this issuer.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.IdentityModel.Tokens.SecurityTokenException: ID4175: The issuer of the security token was not recognized by the IssuerNameRegistry. To accept security tokens from this issuer, configure the IssuerNameRegistry to return a valid name for this issuer.
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
[SecurityTokenException: ID4175: The issuer of the security token was not recognized by the IssuerNameRegistry. To accept security tokens from this issuer, configure the IssuerNameRegistry to return a valid name for this issuer.]
Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.CreateClaims(SamlSecurityToken samlSecurityToken) +739
Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.ValidateToken(SecurityToken token) +628
Microsoft.IdentityModel.Tokens.SecurityTokenHandlerCollection.ValidateToken(SecurityToken token) +117
Microsoft.IdentityModel.Web.TokenReceiver.AuthenticateToken(SecurityToken token, Boolean ensureBearerToken, String endpointUri) +151
Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.SignInWithResponseMessage(HttpRequest request) +583
Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args) +500
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +270
I looked at the portal and found that ACS in this case was leveraging an ADFS2.0 server as the STS(Secure Token Service). I did some research was quickly and found that the error is more of an ADFS error than ACS error since the error code doesn’t have ACS rather has ID in the starting if the error code. I did some research on the issue and found most of them indicate that the thumbprint in my web.config is wrong and may not be matching that of the local certificate.
Snippet from Web.Config
<issuerNameRegistry type=”Microsoft.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, Microsoft.IdentityModel, Version=126.96.36.199, Culture=neutral, PublicKeyToken=31bf3856ad364e35″>
<add thumbprint=”68DFAO902313WBD2F76797B27396F2AAE625AF95A6″ name=”TestSTS”/>
a. Click Start, Run, type MMC.exe, and press Enter
b. Click File, Add/Remove Snap-in
c. Double-click Certificates
d. Select Computer account and click Next
e. Select Local computer and click Finish
f. Expand Certificates (Local Computer), expand Personal, and select Certificates
But both the values were the same and hence there is no mismatch. Based on some further research I found that in ADFS 2.0, AutoCertificateRollover is enabled by default if the installation is done using GUI.
Excerpt from the article
“When the GUI Initial Configuration Wizard (ICW) of AD FS 2.0 has been executed, AutoCertificateRollover is automatically enabled by default and the token-signing and token-decrypting certificates are self-signed and maintained by the AD FS 2.0 service.”
So it may be likely that the Certificate has been autorolledover and hence the thumbprint in the Web.Config doesn’t match that of the certificate in the ADFS2.0 STS server even though it matches that of the local copy.
I requested the customer to follow-up with the STS (Secure Token Service) provider they redirect for authentication and check if the certificate in the ADFS2.0 has been rolled over. Not to my surprise it was and hence the login validation was failing. We got the new certificate and used the thumbprint in it added to the Web.Config (please type the thumbprint and don’t do a copy paste as there might be invisible characters which might get copied). Now the redirection happens successfully and the error doesn’t show up.
Angshuman Nayak, Cloud Integration Engineer, Microsoft