iOS: Configure CA Certificates on iPads and iPhones

While iPads and iPhones can communicate securely with the primary servers, the fact remains that your IS must configure them to accept valid CA certificates. Fortunately, there are many ways to add these certificates to iOS.

Each secure connection to the network begins with authentication; it allows to verify the identity of the server. The majority of iPads and iPhones are configured to accept valid certificates issued by a trusted Certificate Authority (CA). The devices are then able to identify legitimate network servers. To set up CA certificates for iOS, the IT department only needs to follow these simple steps.

What is an AC certificate?

The X.509 certificate is an electronic credential used by devices (for example, servers or clients) to authenticate. Each certificate links the subject’s identity (for example, the host name or server’s IP address) to a pair of public or private keys.

The subject’s identity and the public key are included in the certificate along with the name and signature of the Certificate Authority (CA).

CAs are responsible for confirming the identity of the subject before issuing the requested certificates. They are also responsible for renewing and, where applicable, revoking certificates. CAs thus function as passport issuing offices: they provide “official papers” to authorized persons who have proved their identity.

Once the passport has been provided to the person (or the certificate provided to the server), this accreditation may be accompanied by a signature for proof of identity. And this type of AC certificate validation occurs every time a user browses a Secure-Sockets-Layer (SSL) -protected website.


When validating the web server certificate, the browser also checks the signature of the issuing CA. In most cases, this check is successful because public Web sites typically obtain their CA certificates from trusted root authorities, which are configured by default for each operating system.

The importance of trusted CA certificates

CA certificates issued by trusted root CAs are essential for public servers, such as e-commerce sites.
However, many companies prefer to use their own CAs to issue certificates for non-public servers, such as the company’s messaging, Web, or Virtual Private Network (VPN). .

Applications running on iPads and iPhones can authenticate enterprise servers using privately issued certificates that have instructions to trust these servers.

A particularly risky option is to let users simply accept unknown AC certificates. Allowing such exceptions would lead users to be tempted by self-signed certificates or untrusted CAs, exposing their devices not once, but ad vitam aeternam to a procession of HDM attacks, or attacks. of the middle man.

IT will be much better at explicitly adding an AC certificate to employee devices by configuring applications to identify and trust servers that validate their identity using the company’s CA certificates. Thus, the IT department is able to secure connections to trusted servers without opening the doors in large.

Adding CA certificates to iPads and iPhones

All iPads and iPhones support X.509 PKCS1 format certificates saved in .crt, .cer, .pem or .der extension files. These certificates allow you to identify CAs, servers, even individual devices and users. Here’s how to add CA certificates used for authentication of a mail, Web, VPN or WLAN (Enterprise) server:

Email Distribution: The least secure method is to send your trusted CA certificates to your employees by a simple email. The user who then clicks on the attachment launches a profile installation dialog. This warns him that the CA certificate that will be installed is not trusted. If the user clicks on the installation command, they are warned again that the authenticity of the subject can not be verified and that the installation of the profile will add it to the list of approved certificates on the iPad or the Iphone.

If you use this method, advise users to make ONE exception and never install another CA certificate again, even if it appears to be from the IT department.

Web Distribution: Direct employees to a web page where your CA certificate is published. The user who clicks on the URL of the certificate file launches a dialog similar to the one described in the previous case. If this method is also vulnerable to phishing, it can be enhanced by hosting the CA certificate on a secure website. You can also advise users to make sure they are on the legitimate website before uploading your certificate; for example, by logging on to a corporate web portal first.

Configuration profiles: To add CA certificates, a more automated and robust method is to use iOS configuration profiles. These are files that provide settings to iOS devices. Each profile consists of useful data (“payload”) in XML format. These integrate the certificates as well as the parameters intended for the applications that use them. Regardless of how the profiles are deployed, their XML payload has the same format.

Three types of profile payloads convey the certificate parameters: Exchange payloads, used to configure Transport Layer Security (TLS) protected access to the mail; IPS (Internet Protocol Security) VPN payloads for configuring certificate authenticated VPN access; and Wi-Fi payloads, used to configure authenticated WLAN access through Extensible Authentication Protocol (EAP).

You can also include a list of trusted TLS server names to specifically point to the iOS devices that they want to trust. It is also possible to add an “allowUntrustedTLSPrompt” element to profiles to prevent users from accepting connections to disapproved HTTPS servers.

Simple Certificate Enrollment Protocol (SCEP): SCEP is another robust and scalable way to add CA certificates. Apple iOS devices can use SCEP to remotely solicit certificates from your organization’s CA for subsequent authentication of devices and users, including registration with the company’s MDM server.

You can associate any certificates obtained through SCEP with the Exchange, VPN, or Wi-Fi configuration payloads described above.

To do this, integrate the SCEP payloads with the configuration profiles to retrieve the client certificates from the SCEP servers. A SCEP payload includes the URL of the SCEP server in your company, as well as any optional value, such as the name of the Certificate Authority (CA) and the X.500 subject name of the client.

Once the CA certificate is added to an iPhone or iPad, it can be deleted at any time, either by MDM or by the users themselves. At the same time, the iOS operating system uses the Online Certificate Status Protocol (OCSP) to check for any revocation of OCSP-compliant certificates. Companies planning to issue certificates from their own CA should consider supporting OCSP for the ongoing management of trust relationships.

Leave a Reply

Your email address will not be published. Required fields are marked *