Invalid issuer o signature error in SPO Provider-Hosted AddIns


(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

19 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 -


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: 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 ( 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 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 -

And My login Id for Azure is -  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.



We're seeing the same issue with one of our SPO Provider hosted add-ins too. Our client ID and secrets are managed via the Seller Dashboard though as it is a multi-tenant add-in. Anyone else seeing the same issue via the Microsoft Seller Dashboard? 

If you are asking whether we've experienced this issue in apps that are being distributed via the AppSource, the answer is yes - that's exactly what was happening.


That being said, using the HostedAppHostNameOverride thing solved the issue for us. Was that not the case for you?

no it wasn't the case for us, as we had both client secrets coming up to expire for a client ID, I created two new client secrets via the Microsoft Partner Center seller dashboard but didn't delete the original secrets as they were still active. So we had 4 active secrets for a client ID, it seems that the SPO Provider Hosted add-ins / Azure ACS doesn't handle having 4 active secrets. Once I deleted the original 2 client secrets leaving just 2 active secrets for that client ID, everything sprung in to life!

I'm assuming you have already found a way around this issue, but I resolved it by editing the permissions my App needed to the Host Web. Originally I was just leaving it blank, but setting those permissions explicitly in the manifest got it working.

Based on all the responses, it seems that this error can be caused by more than one thing.


@Paul Mather, I'm being curious: does it mean you had two client secrets for a single client ID? I mean by default the TokenHelper class (the one coming from MS) does support two secrets (by using the "SecondaryClientSecret" app setting), but only to make sure that an app can easily handle the period when the old secret is about to expire, and the new one hasn't been activated yet (new secrets can take some time - up to several hours, as I remember - to become "valid" - at least when they're generated manually).


You mention you had four keys in total, all for a single app - why is that?

Hello @Slawomir Bryk ,

The app was only using 2 but we had 4 in the seller dashboard registered against that client ID for a limited time whilst we were updating. Removed 2 from the seller dashboard for that client ID and the application started to work.


Hi @Paul Mather 

For how long did you wait before it started to work after you removed the two client secrets from the seller dashboard?