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, macOS, and visionOS 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, macOS, or visionOS 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 17, iPadOS 17, macOS 14, tvOS 17, and watchOS 10.
iPhone, iPad, and Mac devices 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
Certificate trust
If a certificate has been issued from a CA whose root isn’t in the list of trusted root certificates, iOS, iPadOS, macOS, or visionOS 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, iPad, and Apple Vision Pro
Root certificates installed manually on an unsupervised iPhone, iPad, or Apple Vision Pro 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: In macOS 13 or later, by default root certificates manually installed with a configuration profile aren’t marked as trusted for TLS. 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.
Intermediate certificates on Mac
Intermediate certificates are issued and signed by the Certificate Authorities’ root certificate and they can be managed on a Mac using the Keychain Access app. These intermediate certificates have a shorter expiration date than most root certificates and are used by organizations so web browsers trust websites associated with an intermediate certificate. Users can locate expired intermediate certificates by viewing the System keychain in Keychain Access.
S/MIME certificates on Mac
If a user deletes any S/MIME certificates from their keychain, they can no longer read previous email that was encrypted using those certificates.
See alsoCertificates MDM payload settings for Apple devicesCertificate Preference MDM payload settings for Apple devicesCertificate Revocation MDM payload settings for Apple devicesCertificate Transparency MDM payload settings for Apple devices
