The Apple Multiple SCEP Policy lets you deliver one or more SCEP payloads to Apple devices from Swif, so you can issue client certificates via a SCEP/PKI solution (for example, Okta CA, SCEPman, or another CA fronted by SCEP).
This is especially useful when:
You need different certificates per use case (e.g., VPN, Wi‑Fi, app SSO).
You are integrating with Okta as a CA and need to issue device/user certificates via SCEP.
You want to standardize SCEP settings across macOS, iOS, and iPadOS from one policy.
Supported platforms and requirements
Platforms
macOS 10.7 or later
iOS 4.0 or later
iPadOS 4.0 or later
Ownership
Company‑owned devices (policy owner:
Company)
What this policy does
This policy configures one or more SCEP payloads on the device. Each payload tells the device:
Which SCEP server URL to use
How to authenticate (challenge)
What type of key and certificate to request (usage, key size)
How often to retry if the SCEP server returns
PENDINGHow to build the certificate subject and subject alternative name (SAN)
In Swif’s device management UI/API, the payloads are defined under the multipleSCEP field as an array, so you can send multiple SCEP configurations in a single policy.
Configuration fields
1. multipleSCEP – Multiple SCEP Payload Content
Display name: Multiple SCEP Payload Content
Type: Array of dictionaries
Required: Optional (policy can contain one or more entries)
Description: List of SCEP payloads. Each item defines one SCEP configuration.
Each item in multipleSCEP has the following fields:
1.1 name
Display name: Name
Type: String
Required: Optional
Description:
A string that’s understood by the SCEP server; for example, a domain name likeexample.org.
If a certificate authority has multiple CA certificates, this field can distinguish which one is required.
Use this for:
Labeling the purpose (e.g.,
Okta-Device-Cert,VPN-SCEP)Mapping to a specific CA profile on the SCEP server
1.2 url (Required)
Display name: URL
Type: String
Required: Yes
Description:
The SCEP server URL. This is typically provided by your CA / SCEP solution (for example, Okta, SCEPman).
Example:
https://trial-9486882.okta.com/pki/0CE8AF5172FBF9C8B36434F4C20A67AB09809929/scep/rac23q9j7xnXCbxiO698
1.3 challenge
Display name: Challenge
Type: String
Required: Optional (depends on your CA configuration)
Description:
A pre‑shared secret used to authenticate SCEP requests. Provided by your CA admin.
Keep this value secure. Anyone with this challenge and SCEP URL can attempt to request certificates from your CA.
1.4 keyUsage
Display name: Key Usage
Type: Integer (enumerated)
Default:
0(Default)Description:
A bitmask indicating the intended use of the key. Some CAs (such as Windows CA) support only encryption or signing, but not both simultaneously.
Options:
0– Default1– Signing4– Encryption
Use the value that matches your CA template requirements.
1.5 keySize
Display name: Key Size
Type: Integer (enumerated)
Default:
1024Description:
The RSA key size (in bits) for the generated key pair.
Options:
102420484096
Recommended: 2048 or 4096 for modern security standards, subject to your CA’s requirements and device performance constraints.
1.6 caFingerprint
Display name: CA Fingerprint
Type: String
Required: Optional
Description:
The fingerprint (hash) of the Certificate Authority certificate.
Use this if your environment or CA requires explicitly pinning the CA certificate by its fingerprint.
1.7 retries
Display name: Retries
Type: Integer
Default:
3Description:
The number of times the device should retry when the SCEP server returns aPENDINGresponse.
Increase this if your CA often takes longer to issue certificates, or decrease for faster failure feedback.
1.8 retryDelay
Display name: Retry Delay
Type: Integer (seconds)
Default:
10Description:
Number of seconds the device waits between subsequent SCEP retries. The first retry is attempted after this delay.
1.9 subjectArr – Subject (X.500 Name)
Display name: Subject
Type: Array of dictionaries
Description:
Representation of an X.500 distinguished name (DN) as an array of{ key, value }pairs.
Each item supports:
key
Display name: Key
Type: String
Description: DN component key (for example,
CN,O,OU,C, etc.).
value
Display name: Value
Type: String
Description: DN component value. Supports special tags:
{{MAIL}}– Assigned user’s email (falls back as described above){{SERIAL}}– Device serial number{{DEVICEID}}– Device MDM ID
Example:
"subjectArr": [
{
"key": "CN",
"value": "{{MAIL}}"
},
{
"key": "O",
"value": "Example Corp"
}
]
1.10 subjectAltName
Display name: Subject Alt Name
Type: Dictionary (expressed as array of dictionaries in UI/config)
Description:
Optional Subject Alternative Name values required by your CA. You can specify a single string or array of strings per key (implementation‑dependent). Typical values include DNS names, email addresses, or URIs.
Sub‑fields:
dNSName
Display name: dNSName
Type: String
Description: The DNS name to include in the certificate SAN.
ntPrincipalName
Display name: ntPrincipalName
Type: String
Description: NT principal name (commonly used in Kerberos/AD scenarios).
rfc822Name
Display name: rfc822Name
Type: String
Description: An RFC 822 email address for the SAN.
uniformResourceIdentifier
Display name: uniformResourceIdentifier
Type: String
Description: URI to include in SAN.
Example:
"subjectAltName": [
{
"dNSName": "device.example.org"
},
{
"rfc822Name": "user@example.org"
}
]
Verification and troubleshooting
For scenarios like Okta Verify + SCEP:
On the device
Confirm the SCEP payload is installed (via Profiles or equivalent).
Check that the expected client certificate is present (Keychain Access on macOS).
Ensure Okta Verify or the consuming app sees and uses the certificate.
In Okta (or your CA / SCEP provider)
Use the admin console to verify that a client certificate issuance event was logged.
For Okta, follow guidance like:
Reports → System Logs → Search ("Issue client certificate").
Check retry behavior
If certificates are not issued immediately and the CA returns
PENDING, ensureretriesandretryDelayare sufficient.
When to use Apple Multiple SCEP Policy vs single SCEP policies
Use Apple Multiple SCEP Policy when:
You want to define several SCEP configurations (for different apps/services) in one policy.
You’re standardizing SCEP for Okta CA or a similar provider across multiple device groups but with per‑use‑case payloads.
You need clear separation between different CN/SAN templates, key usages, or key sizes while keeping management centralized.
If you only need one simple SCEP configuration, a single‑SCEP policy type (if available in your environment) may be simpler; otherwise, you can still use this policy and just configure a single multipleSCEP entry.