SSL Decryption with iOS 13 Devices

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

SSL Decryption with iOS 13 Devices

L0 Member

We began testing of the iOS 13 beta last week on several test devices that are connected to our internal mobile device network.  This network passes traffic through the Palo with SSL decryption.  We are finding that iOS 13, even with our cert installed on the device via MDM, does NOT accept the decrypt cert.  We are still testing, but so far we have found several applications that will not work (some give errors, some just don't do anything), Safari will not open HTTPS sites, and our MDM environment cannot send commands to the devices.  In all cases, once we take the device off of the internal WiFi, eliminating SSL decrypt, everything works.

 

I have not yet been able to find any documentation from Apple indicating that they are enforcing certificate pinning across the OS, but it sure seems like they might be.  Has anyone else encountered this yet?

 

Thanks

23 REPLIES 23

You may struggle generating a cert on the firewall with an OID/EKU field. Some options:

 

Roll your own root CA. Something like this.

 

Or, create a file named "cert_config" with similar attributes:

 

[ req ]

prompt             = no

distinguished_name = my dn

[ my dn ]

# The bare minimum is probably a commonName

commonName = secure.example.com

countryName = XX

localityName = Fun Land

organizationName = MyCo LLC LTD INC (d.b.a. OurCo)

organizationalUnitName = SSL Dept.

stateOrProvinceName = YY

emailAddress = ssl-admin@example.com

name = John Doe

surname = Doe

givenName = John

initials = JXD

dnQualifier = some

[ my server exts ]

extendedKeyUsage = 1.3.6.1.5.5.7.3.1

# 1.3.6.1.5.5.7.3.1 can also be spelled serverAuth:

# extendedKeyUsage = serverAuth

# see x509v3_config for other extensions

 

 

You may also want to look into more EKU attributes, for example, encipherment, decryption, etc..

 

Use openssl to generate the certificate:

 

$ openssl req -x509 -config cert_config -extensions 'my server exts' -nodes -days 365 -newkey rsa:4096 -keyout myserver.key -out myserver.crt

 

 

Source

Help the community! Add tags and mark solutions please.

L4 Transporter

@davisjj @george.v.bowles @RocRaider Did you guys ever find an resolution to this issue? Experiencing the same issue on IOS 14 and 15. Windows devices working fine.

@Ben-Price  We did, sort of.  The only solid solution is to not decrypt/inspect the traffic.  Apple is taking a pretty strong stance that allowing any intercept is a detriment to the overall security of their platform.  I think we are seeing this more and more.  It's hard to argue with the logic.

L4 Transporter

@davisjj Thanks for your response.

 

Its strange, this was working for these iOS devices until we renewed our forward trust certificate as the old one was going to expire, Now with the new renewed certificate the iOS clients don't work. No version iOS config or version change.

L5 Sessionator

Did you import the full chain of trust to the iOS devices? 

 

I had issues generating the cert, then fixed that, but only found in some forum later that even with your own correct CA/intermediate CA and client cert, you need all 3 as trusted on an iOS device for things to work. 

 

With an ESM or MDM, sure that's easy. Doing it one-off with an app like configurator 2, tough times. 

Help the community! Add tags and mark solutions please.

L4 Transporter

@LAYER_8 Thanks for your reply. Yes, we did try to import the Root CA and new SubCA onto the iOS device but no luck. The new SubCA is signed by the same Root CA as the original certificate that was working before it expired.

If you don't mind me asking, who is the root CA?

 

Let's encrypt X1 CA expired so they allowed for multiple paths/chains of custody and this continues to break many devices as applications see a default path to an expired cert and block the session. 

Help the community! Add tags and mark solutions please.

L4 Transporter

@LAYER_8 the root CA is generated from the clients Windows CA server. 

And you are able to confirm those certificates have EKUs on them? That's really strange 

Help the community! Add tags and mark solutions please.
  • 16239 Views
  • 23 replies
  • 1 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!