Intro to certificate management for Apple devices
Apple devices support digital certificates and identities, giving your organization streamlined access to corporate services. These certificates can be used in a variety of ways. For example, the Safari browser can check the validity of an X.509 digital certificate and establish a secure session with up to 256-bit AES encryption. This involves verifying that the site’s identity is legitimate and that communication with the website is protected to help prevent interception of personal or confidential data. Certificates can also be used to guarantee the identity of the author or “signer” and to encrypt mail, configuration profiles, and network communications.
Using certificates with Apple devices
Apple devices include a number of preinstalled root certificates from various Certification Authorities (CAs), and iOS, iPadOS, and macOS validate the trust for these root certificates. These digital certificates can be used to securely identify a client or server, and to encrypt the communication between them using the public and private key pair. A certificate contains a public key, information about the client (or server), and is signed (verified) by a CA.
If iOS, iPadOS, or macOS can’t validate the trust chain of the signing CA, the service encounters an error. A self-signed certificate can’t be verified without user interaction. For more information, see the Apple support article List of available trusted root certificates in iOS 16, iPadOS 16, macOS 13, tvOS 16, and watchOS 9.
iPhone, iPad, and Mac computers can update certificates wirelessly (and for Mac, over Ethernet) if any of the preinstalled root certificates become compromised. You can disable this feature using the mobile device management (MDM) restriction “Allow automatic updates to certificate trust settings,” which prevents certificates updates over wireless or wired networks.
Supported identity types
A certificate and its associated private key are known as an identity. Certificates can be freely distributed, but identities must be kept secure. The freely distributed certificate, and especially its public key, are used for encryption that can be decrypted only by the matching private key. The private key part of an identity is stored as a PKCS #12 identity certificate (.p12) file and encrypted with another key that’s protected by a passphrase. An identity can be used for authentication (such as 802.1X EAP-TLS), signing, or encryption (such as S/MIME).
The certificate and identity formats Apple devices support are:
Certificate: .cer, .crt, .der, X.509 certificates with RSA keys
Identity: .pfx, .p12
If a certificate has been issued from a CA whose root isn’t in the list of trusted root certificates, iOS, iPadOS, and macOS won’t trust the certificate. This is often the case with enterprise-issuing CAs. To establish trust, use the method described in certificate deployment. This sets the trust anchor at the certificate being deployed. For multitiered public key infrastructures, it may be necessary to establish trust not only with the root certificate, but also with any intermediates in the chain. Often, enterprise trust is configured in a single configuration profile that can be updated with your MDM solution as needed without affecting other services on the device.
Root certificates on iPhone and iPad
Root certificates installed manually on an unsupervised iPhone and iPad through a profile display the following warning, “Installing the certificate “name of certificate” adds it to the list of trusted certificates on your iPhone or iPad. This certificate won’t be trusted for websites until you enable it in Certificate Trust Settings.”
The user can then trust the certificate on the device by going to Settings > General > About > Certificate Trust Settings.
Note: Root certificates installed by an MDM solution or on supervised devices disable the option to change the trust settings.
Root certificates on Mac
Certificates installed manually through a configuration profile must have an additional action performed to complete the installation. After the profile is added, the user can navigate to Settings > General > Profiles and select the profile under Downloaded.
The user can then review the details, cancel, or proceed by clicking Install. The user may need to provide a local administrator user name and password.
Note: Starting in macOS 13, root certificates manually installed with a configuration profile aren’t marked as trusted for TLS by default. If necessary, the Keychain Access app can be used to enable TLS trust. Root certificates installed by an MDM solution or on supervised devices disable the option to change the trust settings and are trusted for use with TLS.