Verification failed for domain... even it shows up just fine in curl

Question

Created Sep ’19

Replies 6

Boosts 0

Views 4k

Participants 7

When I run `curl https://subdomain.example.com/.well-known/apple-developer-domain-association.txt` (not the real subdomain/domain), I get a hit in my server logs:

2019-09-09T22:51:23.294771+00:00 heroku[router]: at=info method=GET path="/.well-known/apple-developer-domain-association.txt" host=subdomain.example.com request_id=0a924401-0e45-4713-a9b3-600d657d5c57 fwd="xx.xx.***.***" dyno=web.1 connect=1ms service=4ms status=200 bytes=5961 protocol=https

And the validation certificate is returned are returned. (e.g. "MIIP5AYJKoZIhvcNAQcCoIIP1TCC..."). But, when I press the "Verfy" button on my Service ID "Web Authentication Configuration" dialog for Apple SSO, "Verification failed for domain" is returned but no request arrives at my server. No new logs are created. The browser developer tools XHR console for the request simply returns:

{
creationTimestamp: "2019-09-09T22:54:49Z"
httpCode: 200
protocolVersion: "QH65B2"
requestUrl: "https://developer.apple.com/services-account/QH65B2/account/ios/identifiers/verifyDomain"
responseId: "70f5f9b0-a342-4eac-a527-df7f2981401e"
resultCode: 13004
resultString: "Verification failed for domain"
userLocale: "en_US"
userString: "Verification failed for domain"
}

How can I learn more about the issue? This seems like there's a bug on the Apple Servers that''s preventing the request from being sent off. Could it be because the domain I'm trying to validate has a dash in it? (e.g. sub-domain.example.com)

Boost

Answer 1

danappel OP

Sep ’19

Same exact issue here. You have to undergo the same process to work with Apple Pay, and people seemed to have issues with that too. What are we missing?

For more context. I have a subdomain through cloudflare (caching disabled) with a ".app" TLD. The file is reachable at the correct url, ie https://subdomain.domain.app/.well-known/apple-developer-domain-association.txt. Anybody else with a similar setup get their domain verified?

0

Answer 2

Ant.Mann OP

Sep ’19

I'm having the same issue. Were you able to solve it? Did you try it again later on?

0

Answer 3

Meatotommy OP

Sep ’19

I e-mailed support and got this answer:

"Your server must support the Transport Layer Security (TLS) 1.2 protocol and one of the cipher suites listed below:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

TLS_RSA_WITH_AES_128_GCM_SHA256

TLS_RSA_WITH_AES_128_CBC_SHA256

Please make sure your server meets these requirements and then place the file in a path starting with “https://“"

What I did was get an SSL Certificate from LetsEncrypt, then on my Digital Ocean server, set up the SSL Cipher to only be set to "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256" and it then verified. Hope this helps anyone with this problem, this information should really be documented.

0

Answer 4

dmaascoreplane OP

Sep ’19

I got my domain verified successfully!

I think Meatotommy is on to something with regards to the specific SSL cipher that Apple wants to see.

It appears that CloudFlare - which we use as our primary HTTP front-end - does NOT support whatever specific flavor of SSL the Apple verification process requires. (I made many attempts while flipping various SSL configuration switches on the CloudFlare dashboard. No options I could see would satisfy the Apple verification query. Though I do not have a Pro/Enterprise account so I'm not sure if there is some advanced higher-tier option that would work).

What I did was, create a subdomain for verification that is not proxied via CloudFlare. This subdomain is an A record that points directly at a DigitalOcean droplet running their "LEMP Stack" image. To set up that droplet, I logged in, used the documented certbot command to create a Let's Encrypt certificate for the subdomain, and then dropped the apple verification file in /var/www/.well-known/... After that, the verification process completed successfully.

0

Answer 5

dpedrinha OP

Nov ’19

OK.

Seems like I'm having the same problem and your solution makes much sense. Problem is, I have no idea on how to follow the same steps.

0

Answer 6

sammcoe OP

Jan ’20

Here's what worked for me.

My setup:

- Linode-hosted Apache server, with HTTPS redirects enabled

- LetsEncrypt SSL certificate

- Cloudflare with proxying and full encryption enabled

What I did:

- Disabled the redirect module in the apache virtual site config-- essentially, just make sure you have no redirects happening (when you hit https://yourdomain.com, it doesn't return a 301)

- Enabled development mode in CloudFlare to disable caching on their end

- Set proxy to 'DNS Only' in the DNS settings for the A and CNAME records

I didn't have to change any encryption settings in CloudFlare or update any cipher settings on the server.

I'm not sure the HTTPS redirect actually needs to be disabled, but I was trying a number of solutions and the majority of issues seemed to come from redirects to 'www'.

Hope this helps some people.

0