Sp-dev-docs: Invalid issuer o signature error in SPO Provider-Hosted AddIns affecting Remote Event Receivers

[jcgonzalezmartin]

Category

• [ ] Question
• [ ] Typo
• [x] Bug
• [ ] Additional article idea

Expected or Desired Behavior

we are having problems with SPO Provider-Hosted Add-Ins were we are using remote event receivers...all of these Add-Ins were working last week, but have stopped working Today. Could you please help us with identifying what's happening? We are seeing the problem in 4-5 tenants and with 2-3 different applications. I have attached a document with the troubleshooting we have done and also our findings. As you can imagine, it's quite urgent for us to get information and a workaround about how to fix it...we also opened a support case, but support folks told us that they don't provide help for this kind of issues. Thanks in advance!

Observed Behavior

Starting Today, several of our customers are experiencing problems with SPO Provider-Hosted AddIns when getting the Context Token. The generic error we get is the following one: Invalid issuer o signature. Of course, we have already verified that this is not a problem with expired client secrets

Steps to Reproduce

I have included a document explaining all the troubleshooting we have done and also our findings

Submission Guidelines

Invalid_isuer_or_signature_error_in_SPO.docx

[OliverZeiser]

We are seeing the same issue. It looks like MS is posting back the wrong URL. In our case the application is hosted on azure and the url is https://xxxx.azurewebsites.net/services/service.svc. But the URL in OperationContext that MS is sending is https://xxxx/services/service.svc, so the domain seems to get lost.

[jcgonzalezmartin]

Thanks Oliver,
Just exactly what is causing the exception and so far we have not found a way to solve it. If you find a solution, please post it here. I will do the same.

[OliverZeiser]

We have changed to an app-only context in our case for now. This is working and we don't really need a user context. But this might not be a solution in your case...

[jcgonzalezmartin]

Thanks Oliver, we have done this for some cases, but as you well mention this change is not OK for other cases where we need the user context

[AGerben]

We have experienced the same issue and found that this only occured for Client Secrets created using the New-MsolServicePrincipalCredential Cmdlet. We could not get support on this issue either. Our workaround is as follows:

1. Fully remove the serviceprincipal (Remove-MsolServicePrincipal)
2. Register the app again on appregnew.aspx, using the same Client ID

[jcgonzalezmartin]

Hi again Oliver,
It seems we are not alone with the issue and there is also another posible workaroudn we have no tested yet: https://techcommunity.microsoft.com/t5/SharePoint-Developer/Invalid-issuer-o-signature-error-in-SPO-Provider-Hosted-AddIns/m-p/165697#M4444

[OliverZeiser]

This is not an option for us because we are already using Secondary ClientSecret which has to be created via Powershell...

[jcgonzalezmartin]

We have tried this and worked partially after doing a hack in the TokenHelper class...but this hack is not applicable to other customer experiencing this same error

[jcgonzalezmartin]

Sincé I have received a small update in other channel where we have reported our issue, I wanted just to confirm that the workaround mentioned by @AGerben does not work for us so 4 days later our customer cannot use the App due to this issue

[jcgonzalezmartin]

Steps_To_Reprocuce_AddIn_Error_Invalid_Issuer_Or_Signature.docx
Just for the reference to anyone having this issue, I have attached here the steps to reproduce the issue we are having

[matmig]

We have the same issue on our North Europe Tenant. 2 Provider Hosted Add-Ins (with Remote Event Receiver) stopped to work 3 days ago. Locally Add-In is working fine, but after deploying to Azure Web App, SPRemoteEventType.AppInstalled is not working. We are using AllowAppOnlyPolicy="true" in all add-ins.

[Suresh-Meenakshisundaram]

The Invalid AudienceUri exception is happening due to, the context token carries abc.azuresites.net, the host url gives only abc. Hence it is failing in audience validation. . Use web.config’s HostedAppHostNameOverride in appsettings like which solves the issue. Seems like something happened on the azure side for host machine name, though not 100% sure.

[jcgonzalezmartin]

Thanks Suresh,
We will give a try to your workaround and update here our results.

[matmig]

I have tryied @Suresh workaround to hardcode the azure Web Url in web.config, but it ddidn't help me. The problem is in TokenHelper.CreateAppEventClientContext(properties, false)) method. The Add-in fails in the line with CreateAppEventClientContext. Locally it is working, but after publishing to new created Azure Web App and trying to execute affected method on SPRemoteEventType.AppInstalled it fails.

[jcgonzalezmartin]

Hi all,
We have also tried this workaround and it have worked for a solution of one of our existing customers. We are in the process to apply it to other customer and see if it works

[paulpascha]

The HostedAppHostNameOverride application setting work around also helped us out

[pandiarajank]

Hi Everyone,
After adding _HostedAppHostNameOverride_ app setting in Web.config, I was able to install the Provider-hosted app. App Events(ReR) have started working but list item events(ReR) still has an issue.

Thanks,
Pandiarajan

[rubencabo]

Hi all,
We have sucess with the workarround.
By adding <add key="HostedAppHostNameOverride" value="<hostname>.azurewebsites.net" /> in webconfig the addin is installed but the event receiver url was wrong.
By changing the setting of ReceiverUrl to
receiver.ReceiverUrl = "https://" + HostedAppHostNameOverride + "/Services/AppEventReceiver.svc"; (Previously we have defined:
string HostedAppHostNameOverride = WebConfigurationManager.AppSettings.Get("HostedAppHostNameOverride");)
the event receiver is working fine.

Thank you all

[pandiarajank]

@rubencabo Thanks for your reply. Your workaround is working fine after updating ReceiverUrl.

@VesaJuvonen Hope, this workaround is a _temporary_ fix and we'll get a proper fix for this issue?

Thanks

[timoschwarte]

Hi,

this still seems to be an issue. Ran into this after renewing the client secrets for Add-ins deployed one year ago. AppOnly contexts seem to work, but Add-ins using the user context fail with the "Invalid issuer or signature." exception after client secret renewal.

-Timo

[chackman]

If this is a remote event receiver hosted in Azure, and the hostname is now incorrect, please follow up with Azure.
We have a couple of workarounds mentioned earlier for the remote event receiver issue.

If this is not an issue with remote event receivers please create a new issue.

[jcgonzalezmartin]

@chackman might I ask why you close the issue? The problema is still present for a customer of mine and I have already opened a ticket in both Office 365 and Azure with no much help for now. The workarounds here here does not provide a solution for all cases and I'm still waiting for an official answer about what was changed in the backend that is the cause of the problem

[jcgonzalezmartin]

Ok @chackman if you are not going to re-open this issue, I will créate a new one with the same details. You cannot close an issue that indeed is not solved.

[pandiarajank]

@chackman Please re-open this issue. You cannot close this issue without providing a proper solution.

[jcgonzalezmartin]

Issue re-opened here: https://github.com/SharePoint/sp-dev-docs/issues/1575

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues