iOS App Fails ATS system trust when https is enabled - ios

Question

I have an iOS App that I am compiling in Xcode 11.2.1. I am running MacOS Catalina 10.15.6.
My app consumes a Web Service that works fine when called unsecured over http.
I am now busy implementing security and we have bought a wildcard certificate from digicert and installed it on our API server. I have run the SSLLabs Server Security Test and the server gets an A-grading so all seems fine. We have updated the Android version of the app to use https instead of http and it is working fine. When I access the https endpoints from a browser it works fine and I don't get any security warnings or errors.
However, if I change from http to https and build and run the iOS App I get TLS errors. (I am calling the web service using URLSession and I am using Swift). I am putting a relevant section of the error log below to show the -9802 and -1200 errors I am getting.
ATS failed system trust
Connection 1: system TLS Trust evaluation failed(-9802)
Connection 1: TLS Trust encountered error 3:-9802
Connection 1: encountered error(3:-9802)
...
finished with error [-1200] Error Domain=NSURLErrorDomain Code=-1200 "An SSL error has occurred and a secure connection to the server cannot be made." UserInfo={NSURLErrorFailingURLPeerTrustErrorKey=<SecTrustRef: 0x600001082b50>, NSLocalizedRecoverySuggestion=Would you like to connect to the server anyway?, _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9802, NSErrorPeerCertificateChainKey=(
I found https://support.apple.com/en-us/HT210176 and I was wondering if it is perhaps an issue that the "Subject Alternative Name" in our cert is our wildcard domain "*.domain.com" whereas the url we are connecting to is "myapi.domain.com". Could that be the problem? What else could I be missing?

Answer 1

In case someone else stumbles upon this...we ended up adding the specific subdomain we're calling in the API from our app to the "Subject Alternative Names" field on the certificate. So instead of just having "*.mydomain.com" in the Subject Alternative Names, we included both "myapi.domain.com *.mydomain.com". After we deployed this certificate to the server and we again tried calling myapi.domain.com from our app, the error went away and everything worked. (For those worried that this requires the purchase of a new certificate...it doesn't. It's quite possible to get such a copy of your certificate without having to buy a different one. Just check the documentation of the certificate issuer you are using.)