iOS 18 Bug -Certificate Trust Settings for Private Root Certificates Not Available

Got the same problem, which influence my usually work with whistle. I can't capture https package without trust the private certificate.

Trust option is not appearing Certificate Trust Settings

Yes,I also facing same issue . Tried different path but still unable to find the way. Currently , i m not able to test Apps for iOS 18.i m also waiting for this fix.

Have the same issue on iOS 18 and iOS 18.1 Public beta. There some advices on the interned, but nothing works! It's really annoying and no workaround for now.

I can’t explain the behaviour you’re seeing, but this continues to work for me. I have a personal CA that I use to issue certificates. I run this CA using Keychain Access > Certificate Assistant, using roughly the process described in Technote 2326 Creating Certificates for TLS Testing.

I just installed this CA’s root certificate on an iOS 18 device by:

1. Downloading the .cer file in Safari.

2. Importing the profile in Settings.

3. Enabling the CA in Settings > About > Certificate Trust Settings.

That is, roughly the process described in QA1948 HTTPS and Test Servers.

I was then able to use Safari to access an HTTPS server whose certificate was issued by that CA.

I’ve seen problems like this in the past and they usually involve one of two things:

• Folks trying to use a self-signed server certificate. Things go more smoothly if you create a CA, have it issue the server certificate, and then trust the CA’s root certificate.

• The CA root certificate being weirdly formed, for example, the issue described here.

I’ve reported it by Feedback

What was your bug number?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I have generated my own SSL cert using openssl. The same cert worked on iOS 17. With iOS 18, I open the certificate in Safari and import it on the iPhone. I get "The authenticity of "mydomain.com" cannot be verified." To which I then click Install. But when I go to trust the cert, it does not show up.

I use NextDNS and when I import their cert, it DOES show up to be trusted as a root CA.

Something has changed to make this no longer work with self generated certs.

In a school trust with 10000‘s of iPads . If iPad upgrades to iOS 18.0.0 MDM profile certs fail. If we disable the block on vpn we can install our jamf MDM profile with certs fine. We have 10+ year certs from Sophos xg firewall.

Link seems to be - if we block vpn our jamf MDM profile breaks and so does certs.

weird how this wasn’t picked up in testing with jamf and apple for edu customers.

a reset post upgrade to iOS 18.0.0 seems to fix it.

hope this helps others

@Dooleylastword - Why not use certificates from a real CA for production use?

I encountered the same issue. I tried to investigate different scenarios with various colleagues. If a user upgrades directly from an iPhone running iOS 16 or earlier to iOS 18, or uses the migration feature to move to iOS 18, the certificate does not appear in the Certificate Trust Settings (Full Trust for Root Certificates) list. However, the same certificate can be successfully installed on an iOS 18 device that hasn’t gone through migration or on a device that has upgraded from iOS 17 to iOS 18, where it appears normally in the Certificate Trust Settings list.

We attempted many solutions and initially thought there might be an issue with our certificate. However, we then directly installed Apple's official Apple PKI webpage (https://www.apple.com/certificateauthority/) and downloaded a certificate for testing. We found that devices with these issues also failed to display the certificate in the list for enabling it.

Currently, the only workaround is to reset the entire phone and not use the migration feature or upgrade from iOS 16 or earlier to iOS 18. Only then will the certificate display correctly in the Full Trust list. I'm not sure if this bug will be fixed.

Something has changed to make this no longer work with self generated certs.

As I mentioned earlier, installing self-signed leaf certificates it definitely taking your off the beaten path and I recommend that you not do that. Instead, set up a test CA and have it issue your leaf.

Why not use certificates from a real CA for production use?

There are lots of good reasons why organisations want to use their own internal CA. A classic example of this is that you run an internal DNS using a well-known domain, like .internal, and most standard CAs won’t issue certificates for such DNS names.

Currently, the only workaround is to reset the entire phone and not use the migration feature or upgrade from iOS 16 or earlier to iOS 18.

OK, that’s a new wrinkle.

Based on this and other threads it’s clear that folks are having significant problems here. If you’re being affected by this, I strongly recommend that you file a bug describing the issue as you see it, what diagnostics you ran, and what they revealed. It would help if you included:

• A copy of the CA certificate that you’re trying to use.

• A sysdiagnose log taken immediately after installing the certificate and seeing the problem in Settings.

Please post your bug number here.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

iosNumberOne said: Currently, the only workaround is to reset the entire phone and not >use the migration feature or upgrade from iOS 16 or earlier to iOS 18. >Only then will the certificate display correctly in the Full Trust list. I'm >not sure if this bug will be fixed.

This isn't entirely accurate. It does not work when updating from iOS 17 to 18. Had this issue on an iPhone 15 Pro and an iPad Pro 11". The existing cert and process had been used as far back as iOS 16 and it worked fine.

DTS Engineer said: As I mentioned earlier, installing self-signed leaf certificates it >definitely taking your off the beaten path and I recommend that you >not do that. Instead, set up a test CA and have it issue your leaf.

While this did work, generating my own CA and then using a cert generated from that, this was not a requirement with prior iOS versions. It needs to be spelled out in the upgrade notes if this is now a requirement. Previously, I would remove and reinstall the cert (without CA) for the last two years if it needed to be regenerated. This no longer works and is an extra step to have your own CA.

We've had 4 devices out of 1,160 that have exhibited signs of this problem. A couple of things that we've noticed;

All 4 devices where on some iOS version older then 17.x

They all would have had a profile blocking VPN

On the last one, we tried installing a profile containing the certs and the profile would install but the cert never was available to trust.

On the last one, the MDM profile was showing as unverified but the device had just checked in with the MDM a day or so before and in the MDM the expiration date looked fine.

So far it's been 3 iPhones and 1 iPad that were affected

With our devices being almost 100% remote, I've not been able to get a sysdiagnose log.

We have found that the only way to recover is by doing an Erase All Contents and Settings.

It needs to be spelled out in the upgrade notes if this is now a requirement.

That’s not what I said. Quoting myself here:

it [takes] your off the beaten path and I recommend that you not do that.

My point is that the having a custom CA that issues certificates for internal servers is a well-trodden path that’s exercised a lot. Speaking personally, I’m pretty sure that works because I use this technique for my own server!

That’s not claiming that this is “now a requirement”, or that installing a leaf certificate is unsupported.

Regardless, the issue being reported on this thread is that, in situations we don’t yet understand, the custom CA path isn’t working. To move forward with that issue, we need some bug reports.

Chivalry0499, Thanks for sharing that info.

With our devices being almost 100% remote, I've not been able to get a sysdiagnose log.

Oh, tricky.

One option that might work for you is to ask a user to file their own bug report. They can do that using the Feedback Assistant app, even on stock versions of iOS. The app is hidden, but you can start it by opening an applefeedback: URL, for example, applefeedback://start.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"