How to install root CA certificates on iPhones and iPads

What is a root CA certificate?

X.509 certificates are electronic credentials used by devices (e.g., servers, clients) to authenticate themselves. Each certificate binds the subject identity (for instance, the server's hostname or IP address) to a public or private key pair. The subject's identity and public key are included in the certificate, along with the issuing root certificate authority name and signature.

CAs are responsible for confirming subject identity before issuing requested CA certificates. They are also responsible for renewing and -- when appropriate -- revoking select certificates. In effect, CAs operate like passport offices, handing out official passports to authorized individuals who have proved their identity.

Once a person has been issued a passport -- or a server has been issued a certificate -- these credentials can be presented with a signature as proof of identity. This kind of CA certificate validation occurs every time a user browses a Secure-Sockets-Layer-protected website. When validating the web server's certificate, the browser also checks the issuing CA's signature. This check usually passes because public-facing websites tend to have CA certificates from one of the trusted root CAs that are configured by default into every operating system.

The importance of trusted root certificates

CA certificates from trusted root CAs are essential for public-facing servers such as e-commerce sites, but many companies prefer to use their own CA to issue certificates to corporate email, web, VPN and other servers not intended for public use. Applications running on iPads and iPhones can authenticate corporate servers using privately issued certificates that are given instructions to trust them.

One high-risk option is to simply let users select and accept unknown CA certificates. By making such exceptions, however, users can fall for a self-signed certificate and those issued by untrustworthy CAs, exposing devices not just once but forevermore to a litany of man-in-the-middle attacks.

A far better option is for IT to explicitly add a trusted CA certificate to employee devices, configuring applications to recognize and trust servers that prove their identity using your company's CA certificates. In this way, IT can permit secure connections to trustworthy servers without throwing the door wide open.

Install root certificate on iPhone or iPad

All Apple iPads and iPhones support PKCS1-formatted X.509 certificates, stored in files ending with .crt, .cer, .pem or .der. You can use these certificates to identify CAs, servers or individual users and devices. Here's how IT should approach the installation of CA certificates during enterprise web, email, VPN or wireless LAN (WLAN) server authentication:

Email distribution certificate: The least secure method is to simply email your trusted CA certificates to employees. Any user that clicks on this attachment launches an Install Profile dialog that warns that the CA certificate about to be installed is not trusted. If the user clicks Install root certificate, he will be further warned that the authenticity of the subject cannot be verified and that installing the profile will add it to the list of trusted certificates on that iPad or iPhone.

When using this method, counsel users to make a one-time exception and never install root certificate or any other CA certificates, even if they appear to be from the IT department.

Web distribution certificate: Direct employees to a webpage where your CA certificate is posted. Any user who clicks on the certificate file URL will launch a dialog similar to that described above. Although this method is also vulnerable to phishing, it can be strengthened by hosting the CA certificate on a secure website, and you can advise users to ensure that they reach the legitimate website before downloading your certificate by logging into a corporate web portal first, for example.

Configuration profiles: A more automated and stronger method of adding CA certificates is to use iOS configuration profiles. Configuration profiles are files that deliver settings to iOS devices. Each profile consists of XML-formatted payloads, which include the certificates and the settings for applications that use those certificates. No matter how profiles are deployed, their XML payload content has the same format.

There are three types of profile payloads carry certificate settings: Exchange payloads, which are used to configure Transport Layer Security (TLS) protected email access; Internet Protocol Security VPN payloads, which are for configuring certificate-authenticated VPN access; and Wi-Fi payloads, which are used to configure Extensible Authentication Protocol authenticated WLAN access.

A list of TLS Trusted Server Names may also be included to tell iOS devices specifically which WLAN servers they should trust, and "allowUntrustedTLSPrompt" may be included in profiles to stop users from accepting connections to untrusted HTTPS servers.

Simple Certificate Enrollment Protocol (SCEP): Another scalable, robust method to install root certificates is SCEP. Apple iOS devices can use SCEP to remotely request certificates from your company's CA for subsequent device and user authentication, including enrollment with your company's mobile device management (MDM), enterprise mobility management or unified endpoint management server or cloud platform.

You can associate any certificates obtained via SCEP with Exchange, VPN or Wi-Fi configuration payloads described above, and it's done by including SCEP payloads in configuration profiles to retrieve client certificates from SCEP servers. A SCEP payload includes your company's SCEP server URL, along with any optional values such as the name of the CA and the client's X.500 subject name.

Once a CA certificate is added to an iPhone or iPad, it can be removed at any time, either by MDM or by users themselves. Apple iOS also uses the Online Certificate Status Protocol (OCSP) to check for possible revocation of OCSP-enabled certificates. Organizations that intend to issue certificates from their own CA should consider supporting OCSP for ongoing management of trust relationships.