iOS 13.2.2 doesn't trust certificate chain

[habit81]

Hi, we have a case where iOS devices access intranet website via Tunnel. The intranet website's certificate is issued by company's internal Subordinate (intermediate) CA. This intermediate CA's certificate is issued by company's internal root CA. Obviously iOS doesn't trust both by default. I configured credentials payload and pushed both (root and intermediate) CA's certificates to iOS.

The problem is that iOS still warns about certificate not being valid/trusted (depending on Browser). I configured Web, Chrome and FF and all three show the initial warning. I also installed TLS Inspector and it shows “Untrusted Chain” message.

Same configuration on Android works just fine. No warning messages. If I remove those two certificates from Android I also get warning messages like on iOS.

When I go to iOS Settings -> General ->About -> Certificate Trust Settings I see that the root is fully trusted. I have a feeling that iOS doesn’t trust the intermediate hence the warning.

Has Apple changed something recently or has it been like this since the beginning?

[Stambo]

have a similar setup. our CA is three-tiered one - everything works
(yes with iOS 13.2.2 and 13.2.3)


my cert payload is root - sub1 - sub2 order - may the order makes a diffrence?

[habit81]

Thanks Matthias, I have the same order Root - Sub1. Does your root, sub1 and sub2 use SHA2 signature algorithm? Do they use at least 2048 bit public key length? I have a feeling that either root or subordinate don't meet iOS security requirements. My root uses SHA1 as signature algorithm. Not sure if that matters.

[habit81]

What is also funny is that I installed two apps to verify (TLS Inspector and SSL Detective Plus). TLS Inspector says the chain is not trusted and SSL Detective says Chain Trusted.

[GrantMcClanahan]

Check and make sure your certificates are issued for 825 days or less. Overlooking this caught me:
https://support.apple.com/en-us/HT210176

Additionally, all TLS server certificates issued after July 1, 2019 (as indicated in the NotBefore field of the certificate) must follow these guidelines:

TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID.
TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate).
Connections to TLS servers violating these new requirements will fail and may cause network failures, apps to fail, and websites to not load in Safari in iOS 13 and macOS 10.15.

[habit81]

Hi Grant,

thanks for that URL. Very helpful. I noticed that my server's certificate exceeds 825 days but it was issued in 2017. According to Apple's article it should not matter as the rules apply to certificates issued after July 1, 2019.

Also the root CA uses SHA1 but on the other hand it is not considered an issuing CA. Any other ideas?

[habit81]

We've analyzed the iOS logs today using Xcode and we've found that iOS was unable to resolve the hostname that keeps issuing CA public certificate. Basically this URL is stored in the server's certificate in ' Authority Info Access'  attribute. In our scenario this hostname is not publicly available and exists only internally in DNS. If I put that URL into browser, it can easily download it so the DNS does resolve. This makes my head hurt because I'm starting to think that iOS mechanism tries to connect to those URLs outside of tunnel.

Matthias, Grant, can you confirm that your issuing CA certificates are also not available publicly? Thanks in advance.

[habit81]

Matthias, Grant,

can you please confirm that URL taken from ' Authority Info Access'  attribute of your server's certificate is accessible via Internet?

[troysp]

Just curious if this was ever answered.  We are having the same exact issue and it is happening in an application we want to use internally where it no longer trusts the SSL certificate of the internal server that was signed by our internal CA.  We basically have the same setup with a root CA and a secondary CA that was signed by the root.  I have deployed the certificates in the same order as you have to the devices.  Any information you can offer is greatly appreciated.

[ITdanknight]

I know this is likely a dead thread, but troysp, do you ever figure this out?