Dear Apple Developer Support, I would like to request a technical escalation to the engineering team regarding an ongoing issue with Apple Pay domain verification.
- Error returned by Apple
Even though Apple’s request to our domain returns HTTP 200, the verification still fails with:
resultCode: 13014 resultString: "Domain verification failed. Review your TLS Certificate configuration to confirm that the certificate is accessible and a supported TLS Cipher Suite is used." requestUrl: https://developer.apple.com/services-account/QH65B2/account/ios/identifiers/verifyDomain
- TLS Certificate Validation
We performed a full TLS analysis: Certificate issued by Sectigo Public Server Authentication CA DV E36 (public trusted CA) Full and correct certificate chain No handshake errors Configuration fully valid
SSL Labs rating: A From our side, the TLS configuration is confirmed to be correct.
- Accessibility of the .well-known file
The file is publicly and accessible It returns 200 OK and the content is exactly identical to the file downloaded from the Apple Developer Portal, without any modification.
Our network team confirmed that Apple’s verification request also receives HTTP 200 when pressing “Verify” in the Apple Developer Console.
- Network-side findings
We monitored Apple’s request in real time. Findings:
TLS handshake succeeds
No cipher mismatch
File delivered correctly
Status: 200 OK
No redirect or transformation applied
Despite this, Apple still returns error 13014.
- Request for engineering review
We kindly request that an Apple engineer verify the following:
The actual TLS handshake performed by Apple's verification service (cipher suite, protocol negotiation, SNI, trust chain).
Whether the Sectigo issuing CA is fully trusted and supported by your domain-verification backend.
If there is an internal reason behind error 13014—since the external message does not provide actionable details.
Whether the response is rejected for reasons other than TLS, given that the file is accessible and the request returns 200.
The exact condition that leads Apple to report “TLS Certificate configuration is incorrect” in this case.
This issue is blocking an urgent deployment and must be resolved as soon as possible.
- Existing case reference
Case ID: 102760005987
We are fully available to provide: full response headers packet captures (PCAP) SSL/TLS diagnostics file integrity checks server configuration details or join a technical call (Teams / WebEx) Thank you in advance for the escalation. Andrea
Hi @andrea_mallia,
You wrote:
[...] Certificate issued by Sectigo Public Server Authentication CA DV E36 (public trusted CA) Full and correct certificate chain No handshake errors Configuration fully valid [...]
The Sectigo Public Server Authentication CA DV E36 is an ECDSA-based intermediate CA. Apple's verification crawler has historically had issues with:
- ECDSA-only certificate chains (no RSA fallback)
- Missing cross-signed intermediates in the chain
- The E36 intermediate not being cached/trusted in Apple's backend trust store.
Please confirm your server is sending the full chain including the intermediate. Test specifically with:
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -showcerts 2>/dev/null | grep -E "subject|issuer"
The output should have your leaf cert and the Sectigo intermediate. If only the leaf appears, your chain is incomplete.
Then, you wrote:
[...] SSL Labs rating: A From our side, the TLS configuration is confirmed to be correct. [...]
Apple's crawler doesn't negate TLS the same way SSL Labs does. SSL Labs simulates many clients and averages a grade. Apple's verification server likely uses a fixed TLS profile, you can learn more about the requirements in the technote below:
TN3173: Troubleshooting issues with your Apple Pay merchant identifier configuration
Cheers,
Paris X Pinkney | WWDR | DTS Engineer
