Intro to certificates 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 or iPadOS 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. See the list of available trusted root certificates in iOS.
iOS and iPadOS devices can update certificates wirelessly 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 wireless certificate updates.
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 and (.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 the install certificates section. 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 installed manually on unsupervised iOS and iPadOS devices through a profile will display the following warning, “Installing the certificate 'name of certificate' will add it to the list of trusted certificates on your iPhone or iPad. This certificate will not be trusted for websites until you enable it in Certificate Trust Settings.”
The user can then trust the certificate on the device in 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.