Apple Inc. is considering allowing rival app stores for its iPhones and iPads as part of a major upgrade that aims to meet stringent European Union standards in 2024. Not long ago, Apple faced backlash for the issues caused by removing the ability to bind macOS devices to Active Directory. Here’s a compilation of the solutions we had prepared for the “Active Directory Bindpocalypse victims.”
If you are keen on a permanent solution, there is nothing better than migrating to the cloud and switching to digital certificates for passwordless authentication. Most issues related to active directories can be easily avoided if you minimize your dependency on redundant on-premise directories and credential-based security.
In this article, we will discuss the latest protocol that you can use for your iOS devices for a smooth transition to digital certificates with minimum effort.
SCEP vs. ACME: A High-Level Feature Comparison
SCEP (Simple Certificate Enrollment Protocol) is a protocol that enables devices to quickly enroll for a certificate by communicating with a PKI through a URL and a shared secret. MDM software generally uses SCEP for devices by transmitting a configuration payload to managed devices, including the SCEP URL and shared secret. This can save an admin significant time compared to manually enrolling managed devices for certificates.
Essentially, SCEP instructs devices on how to connect with the PKI using a Gateway API URL. SecureW2 customers have been simply deploying their own SCEP Gateway API URL using our software. They may then add this URL to their MDM so that it can send a payload to devices that need to enroll for client certificates.
ACME is quite similar to SCEP regarding certificate management, except that organizations can use the ACME protocol to have their managed devices automatically request certificates from the CA. ACME is relatively new, and the number of deployment requests we receive for ACME is far from the number of SCEP requests. The SCEP protocol is far more commonly recognized and used.
In general SCEP protocol, we don’t have complete control over the devices to which the certificates are issued in both MDM and BYOD devices. MDM is trusted more as they manage the devices than BYOD, but the onboarding portal still issues the certificates by assuming that the device is secure and in good shape. This is where ACME comes into the picture.
There are improved iterations of the SCEP protocol that serve a similar purpose as ACME in doing additional identity checks before certificate enrollment:
- Intune CA Partner
- SecureW2 Jamf API
Intune CA Partner
Intune CA Partner is used for creating a “Trusted Certificate Profile” for the devices you intend to use for the SCEP configuration. This trusted certificate profile helps in the deployment of the root CA or intermediate CA on the device, along with establishing trust between the device and the issuing CA. Unlike the API token method, it checks the device’s authorization in Intune before distributing certificates.
The following steps are required if you want to configure an Intune CA Partner IDP:
- Create Intermediate CA for Intune SCEP Gateway Integration
- Create Intune Certificate Template
- Create Intune Third-Party CA Partner IDP
- Configure Azure
- Exporting Trusted Certificates from SecureW2
- Configure Policy Management
SecureW2 Jamf API
Jamf and a few other MDMs operate as a SCEP Proxy, providing a more secure way of identifying devices that should enroll for certificates. By proxying the SCEP enrollment request, it gives admins greater confidence that only Jamf-managed devices will be enrolling for certificates. This differs from traditional SCEP setups, where the SCEP URL and Key are given to the device, and they independently contact the SCEP Server.
SecureW2’s API Gateway offers a layer of security over a traditional SCEP Implementation for Jamf-managed devices. The API constantly checks for new devices in a specific Computer or Device group and revokes certificates for the new devices that get added to the group. This enables admins to create sets of conditions, such as last time of use or Device Compliance, for certificate validity.
What is the ACME Protocol?
As the name implies, ACME (Automated Certificate Management Environment) protocol is a recent protocol that automates the entire lifecycle of digital certificates from issuance to renewal/revocation by eliminating human interventions.
The Internet Security Research Group (ISRG) initially developed the ACME protocol for their public certificate service, Lets Encrypt. Recently ACME was published as an Internet Standard in RFC 8555 by the IETF working members of ISRG. Since then, it has seen adoption, especially in the networking domain, such as the support of multiple CAs (Certificate Authority).
ACME has been the new talk of the town, primarily due to its ability to revolutionize the certificate issuance process by automating the entire process. Previously, this task was performed mainly by SCEP (Simple Certificate Enrollment Protocol), which we have discussed in great depth.
Components of the ACME Protocol
- ACME Server (URL)
- One-Time Token (Nonce)
- Using Secure-Enclave
- Perform Device Attestation
What is Apple’s Secure Enclave?
Apple’s Secure Enclave is a specialized security feature featured in iPhones, iPads, and Mac computers. It is intended to provide a high level of security for sensitive data while also ensuring secure device operations. It contains almost all the information related to a device’s serial number and provides cryptographic proof with the key that was given by Apple, which is exclusive and not extractable.
Consider the Secure Enclave to be small, dedicated hardware within your Apple iPhone that handles all security-related functions. It has its own CPU and memory, independent from the device’s primary processor. This separation is critical because it offers a safe and isolated environment in which sensitive data may be stored and processed without being easily accessible to other portions of the device or external threats.
One of Apple’s Secure Enclave’s basic functions is storing and managing encryption keys securely. Encryption keys function similarly to secret codes, scrambling and unscrambling data to ensure that only authorized individuals can access it. The Secure Enclave creates and stores these keys, ensuring their safety from unauthorized access.
How Does the ACME Protocol Work?
ACME enables clients to request certificate management activities through HTTPS using JavaScript Object Notation (JSON) messages. ACME issuance is similar to conventional CA issuance in that a user creates an identity, demands a certificate, and establishes control of the domain(s) in that certificate for the CA to issue the required certificate.
On a basic level, the client requests an account with the live ACME server by performing the following actions:
- Generating an asymmetric key pair.
- Specifying contact details (optional).
- Consenting to terms of service (ToS).
- Linking the account with some other system’s existing account.
After registering an account, the client must complete four critical tasks in order to obtain a certificate:
- Request the issuance of a certificate.
- Verify control over any identifiers specified in the certificate.
- Finish the order by delivering a CSR
- Wait for the certificate to be issued, and then download it.
The client’s certificate order includes the appropriate identifiers and a few extra attributes that contain data not permitted by the CSR format. If the server agrees to provide such a certificate, it responds with a list of conditions the client must fulfill before issuing the certificate.
The client wraps up the order by submitting a Certificate Signing Request (CSR) once the validation procedure is complete and the server is convinced that the client has met its demands. At last, the server will issue the desired certificate to the client.
Now let us perform an in-depth analysis of the ACME workflow to understand each step in greater detail.
A High-Level Insight into ACME Protocol Workflow
- As seen in the last section, the device first obtains ACME payload (by MDM or manual .mobileconfig download).
- Then, MDM or unmanaged solutions decide to enroll the given device for client certificates.
- MDM provides the device with a URL pointing to our PKI with a one-time token that identifies the given device along with the enrollment.
- Device contacts SecureW2 ACME services.
- Device request enrollment for “permanent-identifier” requests device attestation-based authentication.
- ACME service returns an attestation challenge to the device.
- It also requests Secure-Enclave for private key storage and device attestation.
- The device generates a key in Secure Enclave.
- The device provides information to the Apple attestation server that allows for the creation of a key attestation.
- Factors to be verified in ACME Protocol
- For Both MDM and BYOD
- Proof whether a private key is stored in Secure Enclave(for Apple devices)
- Proof of the authenticity of devices trying to enroll from the Apple attestation server(for example, serial number, IP address, etc.)
- Verify whether the device to issued certificate is not tampered with and the Secure Enclave is working properly.
- Only For MDMs
- Verify whether the respective MDMs manage the device.
- Verify whether the enrollment attempt was initiated for the respective device. (Optional)
- For Both MDM and BYOD
- Factors to be verified in ACME Protocol
- After receiving the proof and nonce, the ACME server contacts the policy engines of the given PKI server along with the Attestation Verification Server.
- It verifies the serial number and attestation with the MDM again and confirms the enrollment attempt was valid before issuing the certificate.
- Finally, the certificate is issued by the CA.
What is Device Attestation in Apple Devices?
Device Attestation in Apple devices is cryptographic proof of the validity of device attributes based on the Secure Enclave’s and Apple’s attestation servers’ security. These high-assurance IDs may be used to authenticate Wi-Fi, MDMs, VPNs, Kerberos, and other services.
Device attestation basically contains a cryptographically signed document or pseudo certificate that confirms that a key was given to it by APPLE and has proof of that, such as a serial number and newly generated key as well. The key that it is using for certificate enrollment is tied to the same Secure Enclave residing on the device.
Installing Certificate Authorities on iOS Devices
You must install the root and intermediate CAs on the device in order for its devices to be trusted in the 802.1x framework. You can easily accomplish this by enrolling each iOS device in a certificate program. Generally, you can follow the given instructions for enrolling certificate at a basic level.
- Share a trustworthy certificate link with iOS devices.
- Open the link and select ‘Install‘ when requested to download the certificate,
- Enter your login credentials.
- Click the ‘Done‘ button after the certificate has been installed,
- Follow these steps to Trusted the Root CA Configuration.
- Settings → General → About → Certificate Trust Settings
A list of trustworthy certificates is offered. Click enable the one just installed. Installing certificates on the device greatly enhances security measures. The optimal security practice allows the client to authenticate the RADIUS server using a server certificate.
Is the ACME Protocol better than SCEP for iOS?
Apple has recently introduced a new API framework to support ACME in iOS 16, iPadOS 16.1, and tvOS 16. The presence of ACME in the Apple root store certainly gives ACME the upper hand over SCEP for managing these devices, mainly because SCEP enrollment usually stores the private keys in the URL, making it potentially vulnerable to interception.
ACME’s presence in the root store also enables organizations to employ Managed Device Attestation, which gives a high level of assurance of device attributes, which can subsequently be reviewed as part of a client certificate identity authorization request.
For example, an enterprise issuing certificates via ACME might request an attestation of the enrolled device’s attributes during the initial stages of MDM enrollment. The issuing ACME can cryptographically evaluate the authenticity of the attested device attributes and optionally cross-reference them against the enterprise’s device catalog. Finally, the device is validated as the enterprise’s device only after the final verification.
In iOS 16, iPadOS 16.1, and tvOS 16, managed device attestation offers solid evidence about a device’s identity that may be employed in a trust assessment, especially as part of a zero trust architecture.
Smooth ACME Certificate Management With SecureW2
It is evident that using ACME for your Apple devices is far more advantageous than relying on the SCEP protocol. Still, certificate management is an art only a few are experienced in, especially when it comes to an organization that needs customized certificates based on varying attributes and policies for different employees and departments.
You’re in luck – SecureW2 offers much-needed onboarding support for the deployment of certificates via ACME protocol. After years of successfully providing everything needed for a smooth transition to certificates, this will be yet another feather in our caps. We are excited and, at the same time, committed to minimizing cyber threats by emphasizing the importance of zero trust.
If you’re also excited and willing to broaden your cybersecurity horizons, check our prices to learn more.
