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?
I am trying to apply the requirements to my Palaolto self-generated certificate but I wonder if you can help me on how to apply/configure the following requirement. Can you share more information on how to apply these requirements on the firewall?
TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID.
I also had this problem on my iPhone (13.5.1) and the Global Protect app. After successfully establishing a connection to my company network most websites would not load and displayed a certificate error due to SSL decryption. Here is the resolution:
1. Verify that your certificate profile is showing up under Settings > General > Profile. You should have been prompted to install this when connecting to GP for the first time.
2. This is the part that I was missing. Settings > General > About > Certificate Trust Settings (scroll to the bottom).
3. "Enable Full Trust" for your GP root certificate.
Once I did this I could browse to any site without certificate issues. Good luck!
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 = firstname.lastname@example.org
name = John Doe
surname = Doe
givenName = John
initials = JXD
dnQualifier = some
[ my server exts ]
extendedKeyUsage = 184.108.40.206.220.127.116.11.1
# 18.104.22.168.22.214.171.124.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
@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.
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!