Automated Certificate Management Environment (ACME) MDM payload settings for Apple devices
You can configure the ACME Certificate payload to obtain certificates from a certificate authority (CA) for Apple devices enrolled in a mobile device management (MDM) solution. ACME is modern alternative to SCEP. It is a protocol for requesting and installing certificates. Use of ACME is required when using Managed Device Attestation.
The ACME Certificate payload supports the following. For more information, see Payload information.
Supported payload identifier: com.apple.security.acme
Supported operating systems and channels: iOS, iPadOS, Shared iPad device, macOS device, macOS user, tvOS, watchOS 10, visionOS 1.1.
Supported enrollment methods: User Enrollment, Device Enrollment, Automated Device Enrollment.
Duplicates allowed: True—more than one ACME Certificate payload can be delivered to a device.
You can use the settings in the table below with the ACME Certificate payload.
Setting | Description | Required | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
Client identifier | A unique string identifying a specific device. The server may use this as an anti-replay value to prevent issuing multiple certificates. This identifier also indicates to the ACME server that the device has access to a valid client identifier issued by the enterprise infrastructure. This can help the ACME server determine whether to trust the device. Though this is a relatively weak indication because of the risk that an attacker can intercept the client identifier. | Yes | |||||||||
URL | The address of the ACME server, including https://. | Yes | |||||||||
Extended Key Usage | The value is an array of strings. Each string is an OID in dotted notation. For instance, [”1.3.6.1.5.5.7.3.2”, “1.3.6.1.5.5.7.3.4”] indicates client authentication and email protection. | No | |||||||||
HardwareBound | If added, the private key is bound to the device. The Secure Enclave generates the key pair, and the private key is cryptographically entangled with a system key. This prevents the system from exporting the private key. If added, KeyType must be ECSECPrimeRandom and KeySize must be 256 or 384.) | Yes | |||||||||
Key type | The type of key pair to generate:
| Yes | |||||||||
Key size | The valid values for KeySize depend on the values of KeyType and HardwareBound. | Yes | |||||||||
Subject | The device requests this subject for the certificate that the ACME server issues. The ACME server may override or ignore this field in the certificate it issues. The representation of an X.500 name represented as an array of OID and value. For example, /C=US/O=Apple Inc./CN=foo/1.2.5.3=bar, which translates to: [ [ [“C”, “US”] ], [ [“O”, “Apple Inc.”] ], ..., [ [ “1.2.5.3”, “bar” ] ] ] | No | |||||||||
Subject Alternative Name Type | Specify the type of an alternative name for the ACME server. Types are RFC 822 Name, DNS Name, and Uniform Resource Identifier (URI). This can be the Uniform Resource Locator (URL), Uniform Resource Name (URN), or both. | No | |||||||||
Usage Flags | This value is a bit field. Bit 0x01 indicates digital signature. Bit 0x10 indicates key agreement. The device requests this key for the certificate that the ACME server issues. The ACME server may override or ignore this field in the certificate it issues. | No | |||||||||
Attest | If true, the device provides attestations describing the device and the generated key to the ACME server. The server can use the attestations as strong evidence that the key is bound to the device and that the device has properties listed in the attestation. The server can use that as part of a trust score to decide whether to issue the requested certificate. When Attest is true, HardwareBound must also be true. | No | |||||||||
Note: Each MDM vendor implements these settings differently. To learn how various ACME Certificate settings are applied to your devices, consult your MDM vendor’s documentation.