Azure-docs: Verification of publisher domain failed

Hey @xkobal thanks for your feedback, currently we're investigating this and will get back to you as soon as possible.

Hey @xkobal could you provide the configurations you're using? Could you also please provide a screenshot of the error that you're seeing?

Here is a screenshot of the error. The error code has changed since my first try.

What configuration do you need?

I see, what is the application ID you're using? Are you sure that the app id is correct?

Here is the page with the complete domain name and the application ID. if you try to curl the URL, you will see that the App Id correspond to to the one on the page.

I see, is this a new AAD Application or is this an older AAD Application Registration?
If you create a new aad app registration, do you get the same error?

Hello:
I have the same issue. I created a new App and got the same error. My App type is Bot Channels Registration.

I see, is this a new AAD Application or is this an older AAD Application Registration?
If you create a new aad app registration, do you get the same error?

It's an old AAD application registration. It's same with another application.

hey @xkobal and @seagull33 we're currently looking into this issue and will let you know next steps to resolve this. Thanks for letting us know about this,

Hello @xkobal and @seagull3 can you try creating or using an user that was newly created or created after the AAD Tenant you're in was created and try doing the verification again?

I have created another application call 'test', id: "dc0a40ac-6182-4563-ade8-5e8174ed6343"

The error is the same.

I have forgot a point in my first message, when I click on "Verify and save domain", there is no call on the hosted file.

Hey @xkobal to clarify not a new application. try using a NEW USER in the AAD Tenant that was newly created or created after the AAD Tenant was created.

Hi, I'm having same issue here... here is my endpoint to my domain verification:

https://genial.ly/.well-known/microsoft-identity-association.json

I have adapted my Express NodeJS application to return the Content-Type to 'application/json' but I can't remove the charset part (security reasons of Express package):

This is the error that I have:

Verification of publisher domain failed. Error getting JSON file from https://genial.ly/.well-known/microsoft-identity-association. The server returned an unexpected content type header value. [snhlT]

Can you please tell me what is wrong? Thanks!

Hello,

This is a different error from what this original github issue is referring to.
@chemitaxis per the doc it has to be application/json. It will not work with the content type charset=utf-8. You will need to remove that from your headers in the nodeJS server.

Thanks @FrankHu-MSFT. If another came here for the same problem with Node, I solved the problem with this code:

res.writeHead(200, {
      'Content-Type': 'application/json'
    });

    res.write(
      JSON.stringify({
        associatedApplications: [
          {
            applicationId: 'XXXXXXXX-24f7-XXXX-XXXX-7bd7583f1ce8'
          }
        ]
      })
    );
    res.end();

thanks for providing your solution on this thread! We definitely appreciate it @chemitaxis !

Hey @xkobal and @seagull3 I'm following up on this issue. Can you please confirm whether or not the solution of using a new user in the AAD tenant resolves the issue?

If there's no response by end of day tomorrow I will be closing out this issue.

If you have anymore issues please open a new git issue with a reference to this issue.

Thanks,

• Frank Hu

@FrankHu-MSFT as my applications are "Applications from personal account", if I create another user, it can see my applications so I can't test.

Hi @FrankHu-MSFT , I was redirected to this Github issue after talking with you by email. We encounter the same problem that is described here.
I just created a new user (with "Application administrator" rights), but I'm afraid this user is not able to see the original application (which is an "application from personal account"):

Hey @pierrepinard-2 @xkobal @seagull33 unfortunately the reason that this is happening is because an application from a personal account cannot be utilized to verify the application.

You will need to create a new AAD Application under the new AAD user,

That is when you follow these steps the app domain verification will NOT work:

1. Create a new app with MSA account; close window
2. Signup for Azure
3. Go to portal again after completing sign-up/trial. Go to "Azure AD" and confirm new tenant created
4. Go to "App registration", select "Applications from personal account", select App and try to verify domain

This sort of functionality unfortunately does not work. You will need to create a new app under a new AAD User in the newly created AAD tenant.

I apologize for the inconvenience, let me know if this resolves your issue.

@FrankHu-MSFT For me it's a major issue than Applications from personal account cannot verify their domain
while a warning is displayed for application users :-/
My only option is to recreate applications which is a problem for our users by forcing them to give again their consents to another application...

hello @xkobal I understand that, and apologize for the issues that this is causing. Unfortunately that is the only resolution there is for this sort of issue.

Note that this is only for users who created the app registration under a MSA account and then created an AAD tenant afterwards with the same MSA Account. If this was not the way you created an AAD Application, then please explore different options to resolve your issue.

We're looking into this issue and are working to resolve this,

I apologize again for the issues that this may cause.

As this github issue has been resolved within the scope of this issue, I will be closing out this github issue by end of day. If you have anymore issues please file a new github issue with a reference to this github issue.

I have the same issue. I have tried the work around that I think is being suggested in this thread.

I created a new AAD user called Qwiqr.

And then I created a new app registration belonging to the new AAD user.

When I try to verify the domain I still get this error...

"Verification of publisher domain failed. Error getting JSON file from https://qwiqr.co.uk/.well-known/microsoft-identity-association. The server returned an unexpected content type header value. [PMOxq]"

The content type is "application/json", which I have seen is required elsewhere.

HTTP/1.1 200 OK
Cache-control: no-cache="set-cookie"
Content-Language: en
Content-Type: application/json
Date: Tue, 15 Oct 2019 16:04:02 GMT
Server: Apache/2.4.39 (Amazon) mod_wsgi/3.5 Python/3.6.8
Set-Cookie: AWSELB=A9FDA12F0E5ABFD665AA7054525B2A118275F6A0D1F813AE4AF9762AAD4DE5A9B64B6626B247E5F93E6ABADADDD0A462AC6A62F598F8EF4CE5AE338FB5953711E64A2BA028;PATH=/;MAX-AGE=600
Vary: Accept-Language,Cookie
x-content-type-options: nosniff
X-Frame-Options: SAMEORIGIN
x-xss-protection: 1; mode=block
Content-Length: 93
Connection: keep-alive

I have also tried giving the new user the Application Administrator" role, which didn't help either.

My app uses django. This my first attempt to use Azure and I am not having much luck even getting started with this. Any suggestions please?

just wanted to mention that, for express.js users, writing the code exactly like this does make it work. I had previously written the code like:

res.end(<JSON CONTENT HERE>)

and the verification still failed even though I was setting the content-type header correctly. However, changing the code to the snippet above ☝️just makes is magically work

@FrankHu-MSFT

This issue still presents itself when hosting the file on GitHub Pages:

As there is no control over the content-type used by GitHub Pages - what is the solution for this given the end user has no control over GitHub Pages and the content-type configured for files.

Verification of publisher domain failed. The JSON file located at www.mydomain.com/.well-known/microsoft-identity-association.json has a content length that is not set or otherwise invalid. [E/SIR]

Download fresh from Azure and put in my domain, but still failed. Any update on this?

Having the same issue here. Postman and Chome indicates the content type is "application/json". I tried creating a new user in the portal as you suggested but that doesn't fix the issue.
My file is hosted on a Apache server.

@neobie , did you solved your issue by any chance?

I am getting the same error as @abraunegg when hosting page on GitHub pages with custom domain.

When I copy and paste the following link I can see the JSON, so I know it is there:

https://my-domain-here.com/.well-known/microsoft-identity-association.json

It is just a simple HTML/CSS/JS Single Page App with no Node backend or anything like that.

_(note: I had to add a .nojekyll file to project root in order to make the file within the .well-known folder accessible via url, per this post)_

Edit:

There is related discussion here:

https://stackoverflow.com/a/33619500

which references:

https://github.com/jshttp/mime-db

and it looks like .json file are being returned with the correct type, so it looks like it is an Azure issue and not a GitHub pages issue:

https://github.com/jshttp/mime-db/blob/master/src/nginx-types.json#L11

@oshihirii , @veler , @neobie
Just to add to this: https://docs.microsoft.com/en-us/answers/questions/13291/publisher-domain-verification-fails-because-verifi.html?childToView=14181#comment-14181

I have attempted to get this resolved in 3 different area's as per above ... all folk appear not interested in fixing this issue.

thanks for the update @abraunegg , yes i can see you and others have been very thorough in researching the issue and articulating all the points, hopefully something is done soon.

i had a thought...to verify the domain another way:

https://docs.microsoft.com/en-us/microsoft-365/admin/setup/add-domain?view=o365-worldwide

So what I did was just complete the first two steps, ie add a text record to the domain and verify.

I _did not_ continue to add more records for email etc (because i don't need that setup).

And then when I went back to the Branding page for the application and clicked Update Domain, the domain was there in the Verified Domains list:

Disclaimer: I have no idea if this will create some unintended/undesired consequences, but atleast I could get the domain verified and select it.

@oshihirii
That process only works if you own the domain and can add a TXT record. If you are hosting the verification JSON on github - via github pages .. you cant follow that process ...

The issue is clear, the solution is clear - MS need to update the validation to ignore charset if it is set .. very easy to do & fix.

@abraunegg - ah sorry, i see, i forgot you didn't have a custom domain for it (i do, but am hosting on GitHub pages as well). yes, I think your conclusion seems correct.

(in case anyone needs it, and i am sure there are hundreds of other competitors, namesilo.com has cheap domain registration (with DNS management) or you can use a more basic domain registrar and then cloudflare (to add text records etc)).

@FrankHu-MSFT
So .. question is back to you ... when will Microsoft fix this issue ?

We've started seeing this across some of our Azure subscriptions as well. Verifying domains the same way we have done over the last few years does not work anymore, with the error:

Verification of publisher domain failed. The JSON file located at [YOUR_URL].com/.well-known/microsoft-identity-association.json has a content length that is not set or otherwise invalid. [hTCyp]

For reference, this very approach have worked for a long time. Only recently when we needed to verify yet another set of applications, it started to fail with the above message. It does indeed seem like the issue are with Azure, or some change in how verification works.

@Mike-Ubezzi-MSFT
Can we please get some traction here in fixing this issue?

@abraunegg This docs channel is best suited for raising issues with the documentation. If there is a specific doc issue, please open a new issue and I will redirect it to the Identity and Security engineering team to address the documentation. If you are experiencing a product issue, please create a support request. The original issue raised here was resolved, and it appears there is a second issue that is not documentation specific and opening a support request is the appropriate action to take.
I am the on-call resource this week and my role is to provide initial response and redirect the issue to the correct team. If this is product functionality not working as intended, a support request is the most efficient channel to have the issue addressed. If the documentation is not working, then I recommend opening a new issue and we can work with the content team to have the documentation updated. If you open a new issue, make sure to point out that the steps detailed in the documentation are not resulting in the stated functionality and include details about your implementation minus any sensitive information. I appreciate your understanding.

Unfortunately, the proposed solution as articulated here https://github.com/MicrosoftDocs/azure-docs/issues/39665#issuecomment-538104258 is ineffective at this point. This may be the result of further backend changes to the validation system on the Microsoft side, but at this point, ticket closure is inappropriate. I've forwarded header details to @FrankHu-MSFT as requested in the related documentation thread, and look forward to the followup.

I'm baffled that this bug hasn't been fixed. charset is a part of http header on the internet. Did you test this at all? Most people can't remove the charset header on their resources. Please fire the intern that wrote and tested this piece of shit.

It's Microsoft "not quite compliant" standard mode of operations yet again. Just fix it, ok? Why event care about the header? There are no simple workarounds and a clear bug.

For me the error code was IL2U4. I fixed it by going into IIS, MIME Types, and changing the type for .JSON to "application/json". It's pretty ridiculous how bad Microsoft error messages are. And in any case, why does the MIME type even matter? The programmers at Microsoft are just really incompetent, I've seen it in a thousand different ways over the decades.

I have the same issue...this is a bug, no ifs and or buts about it. This is ridiculous the amount of time app developers have to spend debugging, searching the internet and attempting to modify core accepted standards to comply with this ridiculous constraint. The qualification doesn't even make sense.

Echoing a comment I saw elsewhere, surely the only checks required are:

1. Does the json file exist in the proper location?
2. Does it contain the expected application Id?

The charset shouldn't matter.. Fix this bug, please.

Given that this issue is closed _and_ the original issue is unrelated to the comments the rest of us are having, I've created a new issue here.