SharePoint Error–Issuer of the Token is not a Trusted Issuer

  • Article

While experimenting with Windows Identity Foundation and SharePoint 2010, I was attempting to configure SharePoint to use a customer Security Token Provider (STS) I had written. The STS worked perfectly with a normal Federation enabled ASP.NET web site, but I got the error “The issuer of the token is not a trusted issuer” when I tried to use the STS with SharePoint.

The solution was to ensure the correct certificate was added to the SharePoint SPTrustedRootAuthority collection; however, in the process of doing that I had corrupted the collection. The following tips are provided to assist others going down this path.

As is typical in a lab environment, I was recycling through issues at a rapid pace; reissuing certificates, recompiling the IP-STS, and recreating SPTrustedRootAuthorities and SPTrustedIdentityTokenIssuers.

1. Don’t ever, ever, clear the SPTrustedRootAuthority collection. It holds some self-issued SharePoint certificates. Things won’t work if these self-issued certificates aren’t there. I had to add back the SharePoint Services certificate, which SharePoint uses internally as a self-signed certificate for authentication between web applications and service applications:

clip_image001

2. If you issue a new signing certificate for your STS to replace an old one, you have to update the certificate in 2 places:

a. Add the new signing certificate as a SPTrustedRootAuthority

b. Update the SPTrustedIdentityTokenIssuer.SigningCertificate if you are not creating a new issuer. I was able to update an existing issuer with the following PowerShell commands

clip_image003

clip_image005

3. Look in the application event log for errors. I found some very good error descriptions there.

clip_image006

4. Similarly, the ULS logs capture much of the certificate activity, that can help you determine what thumbprints are known to SharePoint:

clip_image008

5. Always, always test in a simulated domain environment with separate VMs for the domain controller, SharePoint, the STS, and the client. I found many issues don’t surface when testing everything on a single VM. You have to hope between VMs and use separate certificates for each role (signing, encryption, domain root, etc.); and of course as we all know, the golden rule to use separate least privileged accounts for each role/service rather than running everything as administrator.