Invalid issuer o signature error in SPO Provider-Hosted AddIns

Juan Carlos González Martín

(Note: we have already verified that this is not a problem with expired client secrets)

Hi all, 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! cc @Vesa Juvonen

12 Replies

Can you open up an issue at the following location with the sufficient details, so that we can start working on this within the engineering? We use this issue list for tracking incoming issues around SharePoint development and issues are automatically synced to our VSO for internal tracking.


Thanks for your submission advance - https://github.com/SharePoint/sp-dev-docs/issues.


This GitHub issue list is an alternative or add-on tool for opening up official support ticket through official channels with Premier support or with SPO Online support, which should be always the #1 step for any unexpected issues so that things are getting tracked using official channels.

Hi Vesa!
I have already submitted the issue: https://github.com/SharePoint/sp-dev-docs/issues/1409. Of course, we tried first to open a support ticket but support team told us that they didn't provide support to any issue related to third party development :-(. That's the reason I have decided to post here the problem and also at other channels

We've run into the same issue in the last two months. Over each tenant we provide PH solutions in (8 so far), we see that renewed client secrets do not work with the invalid issuer error. We ran into a wall with support, so we figured we would wait until others started reporting this. Well, here we are :)



As a workaround we use Remove-MSOLServicePrincipal (https://docs.microsoft.com/en-us/powershell/module/msonline/remove-msolserviceprincipal) to remove the registration and recreate it using the same Client ID on AppRegNew.aspx . When using the same client ID the granted permissions carry over. This gives a service interruption of half an hour to a couple of hours, but it's better then nothing.

Ey Jan,
Thanks! Do you mean that this workaround ended with your solutions working again after half an hour? What do you mean by service interruption?

Thanks again!!!

It is important to note that we ran into this when creating new secrets for secrets that were about to expire. The normal procedure for replacing these secrets involves a secondary client secret, which allows for a switch over without interruption. Since the new client secrets where never accepted, in our experience things kept running until the switch, and then service breaks down with the invalid issuer message.


Using our procedure, recreating the app registration, the new client secret is not immediately accepted. Something needs to propagate in the back-end. We've seen this take between 0.5 and 4 hours. During this time the invalid issuer token message was shown.


In the end it all comes down to a difference in client secrets and app principals that are created through the Create-MSOLServicePrincipal cmdlet (broken), and those that are created through the AppRegNew.aspx page (works).


One additional question here: Did you have to create a new publishing profile for your AddIn when re-placing the ClientSecret with the one created with PowerShell?

Same here. We managed to work around the error by specifying a HostedAppHostNameOverride app setting in our Application Settings. We found out that in TokenHelper's  CreateAcsClientContextForUrl the call to OperationContext.Current.IncomingMessageHeaders.To.Host resolved in the wrong Host Name. In our case we expected ourapplication.azurewebsites.net but only ourapplication was returned. 





Having the same issue.


Indeed, putting the HostedAppHostNameOverride approach seems to be working as a temporary workaround.

Hello, I tried putting HostedAppHostNameOverride below Client Id and Client Secret tags in Web. Config file. But it didn't work as expected. List is still unable to trigger remote event receivers. Please advice. 

Hello Rajat,


It did work for me, even for remote event receivers (at least the one being triggered when the add-in is being uninstalled).


The basic rule is to make sure that this value contains the text that is displayed to you in the error message "(...) is not the intended audience <important_text>". So you take the important_text value from your log message, strip if from the part before the "/" sign and the part after the "@" sign (see the content of TokenHelper.GetFormattedPrincipal method for details on what is going on there), and put it in the HostedAppHostNameOverride.


Also, as you've probably seen, the HostedAppHostNameOverride parameter can be a semicolon-separated-value, so you can put several values there.


Hope this helps.

Hello Slwomir 


Thanks for Replying, I have two questions. 

1) In order to deploy the apps on Azure and SharePoint Shall we need to have same login account for both ? 

Let's say my Login account for SharePoint is - rajat.chauhan@xyztst.onmicrosoft.com

And My login Id for Azure is - rajat.chauhan@xyz365.onmicrosoft.com  would it work ?

2) After adding the HostedAppHostNameOverride in application settings Do we need to generate new client ID and client secret to deploy apps ? 


Thank you in advance



I have no idea about the deployment thing. For me it seems that it does not matter who makes the deployment - but I guess you just need to check it.


As for the client id and secret - I didn't have to re-generate anything, luckily.