This is a another follow up to my earlier post on changing the token signing certificate for the SharePoint STS as described here: http://blogs.technet.com/b/speschka/archive/2014/05/06/updating-trust-between-onprem-farms-and-acs-for-apps-when-your-sharepoint-sts-token-signing-certificate-expires.aspx. As I mentioned in that post, you will undoubtedly wind up in this situation if you configure your farm to use low trust apps, because as part of creating the trust with ACS you need to change the STS’ token signing certificate. As part of that process, one of the side effects is that it changes the realm associated with your SharePoint farm. The reason why that’s important to you as it relates to high trust apps is that the farm’s realm is part of the identifier used with the SPSecurityTokenIssuer used for high trust apps, as well as the identifier for individual apps. For example, here’s what the identifier looks like for one of my SPTrustedSecurityTokenIsssuers:
The first part of the identifier (before the @sign) is the issuer ID for it; the part after the @sign is the realm for the farm. The impact of this is that all of your high trust apps will no longer work after you change the token signing certificate for your farm’s STS. The work-around to get things going is as follows:
- Delete your existing SPTrustedSecurityTokenIssuers (that you created, where you are using a certificate for the token issuer). Use the Remove-SPTrustedSecurityTokenIssuer cmdlet.
- Re-create your SPTrustedSecurityTokenIssuers; you can use the same certificate and the same issuer ID as you had originally. Use the New-SPTrustedSecurityTokenIssuer cmdlet.
- Re-create the client ID / application ID / App ID (these terms mean the same thing but are used fairly interchangeably) for each high trust app. For example, go to the sites where you are using your apps, use appregnew.aspx to create a new App ID, then update your application to use the new App ID.
Once you do these steps your high trust applications should start working again.