iOS 14 TLS/SSL certificate invalid ?

Can you tell me more about the items you fixed for iOS 13? Also, what errors are you seeing in iOS 14 and what APIs are you using while making your connection?

Are you able to provide a x509 -text dump of the public certificate redacting any sensitive information? The reason I am asking for this is it gives me a frame of reference on how your TLS server certificate is configured for misc iOS 14 testing.

Also, it looks like the link from your above post was munged up by the editor. Here is the Requirements for trusted certificates in iOS 13 and macOS 10.15.


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

Hi Matt ! Thanks for your reply.

The modifications about the certificate we fixed in iOS 13 are described below:

1. Set RSA keys sizes to 2048 bits.

2. Use a hash algorithm :SHA-2.

3. Others required in Requirements for trusted certificates in iOS 13 and macOS 10.15.

The certificate still works well in iOS 13 when our app connects to our server. But in iOS 14, it can't connect and the APIs we used display errors as below:

• [API] AFnetworking

  • error.domain : NSURLErrorDomain

  • error.code : -999

• [API] SRWebSocket

  • error.info : Invalid server cert

  • error.code : 23556

I'm sorry about that I can't provide the certificate info. In my searching ,there are some new network protocols implemented in iOS 14. The list is described below:

1. ipv6

2. http/3

3. TLS 1.3

4. Multipath TCP

5. Encrypted DNS

Are these protocols must implemented in our app and server?


Best Regards.

Thanks for your response. AFNetworking and SRWebSocket are 3rd party APIs, so I cannot comment on what is happening there. However it does look like there is something in the trust chain that our APIs do not like that is bubbling up these errors.

I'm sorry about that I can't provide the certificate info.
No problem at all. Is this an in-house certificate from your CA or a certificate from a public CA?

I am not sure about the support for the 3rd party libraries you have mentioned, but are you needing to support http/3, TLS 1.3, or Multipath TCP?

Are these protocols must implemented in our app and server?

No.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

I am having the same problem as @William0920.

I generated certs that were once valid in iOS 13, but after applying the iOS 14 update my certs are no longer valid. There is no documentation posted about trusted certificate requirement changes from iOS 13 to iOS 14 so I'm sitting here wondering why my certs are suddenly not valid.

Anybody have any advice for me? I'm totally up a creek here...

Hi, we've found a similar problem with the in-house apps downloads... and it was that the certificate had a wildcard, something like *.subdomain.domain.com, but it worked OK through a server with a certificate for server.subdomain.domain.com, that's how we solved it.

I am having the same problem as @William0920

Exchange server 2013 mail certificate works well with ios 13.
If ios 14 is updated while the certificate works fine, it will continue to work. But this certificate does not work on a new Iphone/ipad with ios 14 installed. When trying to add a mail account, I get a warning that the certificate is invalid. The resume button does not appear.

When adding an account to the outlook for ios app, the continue button appears and the certificate works.

I talked to apple support regarding this problem. It says that the secure certificate is mandatory for iOS 14, but does not agree to write this information by mail. Obviously the secure certificate is not mandatory, but iOS 14 does not allow it. the suggestions here won't work.

I am also having the same problem as @William0920. When I updated to iOS 14, the certificate stopped working (I have a self-signed CA and a server cert signed by the CA). It conforms to the requirements (ios13), worked on iPhone iOS 13, until I updated to 14 and currently works on iPad (iPadOS 13).

I submitted a 🐜 to 🍏. In Settings, the certificates (CA + signed server certificate) are both “Verified” (aka trusted).
However, connecting to the server with identical server certificate to that in settings, opening the certificate in Safari displays “Not Trusted”!! The certificates are identical (checked sha256 fingerprint), but once “Verified” — Settings, the next time “Not Trusted” — Safari, Shortcuts. ***?

Similar scenario with iOS14.
The SSL certificate is approved for a subdomain with a wild card (*.enabley.io). We noticed that when the prefix of the wildcard contains underscore (e.g. better_office.enabley.io), the certificate is not recognized. However when the prefix doesn't contain underscore (betteroffice.enabley.io), everything works perfectly.

Any clues?

Not sure exactly what is happening here but please feel free to open a TSI and I can dig into the specifics on why you are experiencing TLS issues in your environment. If you open a TSI please make sure that you are able to share a native code sample (without 3rd party libraries) and any logs you have collected during debugging this issue.


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

I am having this same issue. Has this ever been solved?

Hi there are any news regarding this problem? We are experiencing some problem with the Apple Login in our app.
We didn't change much so I suspect it was related to IOS14.

Thank you

I've just run into same issue, I've run some tests and it looks like after upgrade to iOS 14 both Safari and Chrome browsers does not support SNI anymore. I have a server with nginx and some virtual hosts on it and using different SSL certificates. Everything works fine when I open these sites from PC, however when I open some websites from iOS 14 device it shows up error with certificate. I've checked and it looks like it's default SSL certificate that I have on my server, but iOS should send SNI before initiating SSL connection to make sure it works with the right certificate, which is not happening.

It's not just me, my colleagues and other visitors reporting the same issue with these sites. If you want, Matt, I can email you few domains to reproduce the issue if you want to check this from your side.

I first thought that maybe it's because Apple rejected to work with SNI when encryption protocol is lower than TLS1.3, I've enabled TLS1.3, but it didn't help. I've checked it connection with developer tools to my Safari and it shows that connection is TLS1.3 but certificate is for wrong domain. However, if I say that I'm okay with the risks, it opens the correct site (looks like it sends 'Host:' header with correct domain afterwards).

I just ran into into this issue with a user and needed to add TLSv1.3 to the ssh settings in my web server conf

Hey everyone, good news, I've managed to fix this issue on my side. And came back with solution:

Long story short:
Looks like some Apple iOS libraries (probably connected to TLS/SSL) respects RFC (RFC 1035) too much and SNI does not work when your domain has symbols like "_" (underscore) in it. I've switched from using

Code Block 
pewpew_blast.mydomain.com

to

Code Block 
pewpew-blast.mydomain.com

and the issue disappeared.

Uncut
I've started investigation enabling security best practices in my web server configuration – enabled TLSv1.3, disabled TLSv1.1, enabled OCSP stapling, added HSTS header, generated and enabled dhparam, renewed intermediate certificate for default domain to make sure it's fully valid. Nothing helped. I've then started to think of other places I've been using SNI, I found such place, checked from my iPhone and it worked without issues. Strange, because SSLLabs grade for that domain which works was C, while my domain with iOS issue is A+. Additionally I've checked default (non SNI) virtual host for domain which works on iOS and found that I have self-signed certificate, so it's definitely not connected to invalid domain on default vhost.

I've started to compare settings and thought that maybe it's underscore, which I know is not supposed to be in domain name according to RFC. I've configured my vhost to work with both dash and underscore, opened domain with dash and surprisingly found it works fine. Both domains with underscore and with dash are processed by the same webserver and with the same vhost, so it means both domains has the same configuration and the only difference is domain name.

Conclusion
Even thought underscore is not valid character in domain name according to RFC 1035, it would be great if Apple would support it to make sure their users has more capabilities to surf the Internet.

Meanwhile domain owners should take in their considerations that underscore is not valid character for domain name and avoid using it to make sure all devices are able to access their web resources.