Apple iPads and iPhones can communicate with back-end servers securely in many ways, but IT has to configure the devices to accept valid CA certificates. Luckily, there are many different methods for adding the certificates to iOS devices.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Every secure connection to the network starts with authentication to verify the server's identity. Most iPads and iPhones are configured to accept valid certificates issued by a trusted certification authority (CA) so the devices can tell which network servers are legitimate. IT needs to follow a few simple steps to configure CA certificates for iPads and iPhones.
What are CA certificates?
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 CA's 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 certificates. In effect, CAs operate like passport offices, handing out official passports to authorized individuals who have proven 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.
More on public and private keys
A certificate requestor (called a subject) must create a pair of keys: one private and known only to the subject; one public to be used in future authentications. The subject will be able to prove its identity by using its private key to generate digital signatures which anyone can verify using the subject's public key.
The importance of trusted CA 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, virtual private network (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 accept unknown CA certificates. By making such exceptions, however, users can fall for self-signed certificates 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.
Adding CA certificates to iPads and iPhones
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 to add CA certificates used during enterprise Web, email, VPN or wireless LAN (WLAN) server authentication:
Email distribution: 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, 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 any other CA certificates, even if they appear to be from the IT department.
Web distribution: Direct employees to a Web page 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.
Ways to deploy configuration profiles
- Via Web
- Via email
- By connecting an iOS device to a computer running the iPhone Configuration Utility
- By pushing profiles to an iOS device workgroup using Apple Configurator (ideal for small organizations with fewer than 30 devices)
- Over the air using an MDM tool (most businesses should consider MDM for fully automated, user-transparent iOS configurations)
Configuration profiles: A more automated and robust method of adding CA certificates is to useiOS 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.
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 of adding CA 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) server.
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. The iOS operating system also uses the Online Certificate Status Protocol (OCSP) to check for possible revocation of OSCP-enabled certificates. Organizations that intend to issue certificates from their own CA should consider supporting OCSP for on-going management of trust relationships.