Other MDM Solutions
Last updated
Was this helpful?
Last updated
Was this helpful?
You can use SCEPman to issue certificates via MDM systems other than Intune. You must configure a static challenge password (see for the formal specification) in both SCEPman and the MDM system. Virtually all MDM systems support this mode of SCEP authentication.
Note however, that this does not provide the same level of security as the authentication mode employed with Intune. The challenge password authenticates requests from the MDM system, so SCEPman knows they come from a trusted source. But if attackers steal the challenge password, they can authenticate any certificate request and make SCEPman issue them whatever certificate they want.
It is therefore crucial to keep the challenge password secure. This can be achieved when the MDM system acts as the SCEP client and delivers the final package comprising certificate and private key to the end-user devices. This way, the challenge password is used only available to SCEPman and the MDM system, but not on the end-user devices.
There are two SCEP endpoints to choose from when configuring SCEPman for MDM systems other than Intune and Jamf Pro:
Static-AAD
Static
The Static-AAD endpoint is recommended for MDM systems with Entra ID integration such as Kandji and Google Workspace. User certificates distributed from the Static-AAD endpoint will benefit from when the respective user has been disabled in Entra ID.
The Static endpoint is recommended for all other MDM systems.
Add the following settings to your SCEPman App Service > Environment Variables > Add.
Once the settings have been added, save the settings and restart your SCEPman App Service.
Enable Static-AAD validation
true to enable, false to disable
generate a 32 character password
(optional)
Days certificates issued via the Static-AAD endpoint are valid
365
(optional)
Store requested certificates in the Storage Account, in order to show them in SCEPman Certificate Master
true to enable, false to disable
Note that there are two variants of SCEP proxy implementations, only one of which is secure in this configuration:
Your MDM system may act as a SCEP client, generate the secret keypair, and deliver the complete package consisting of certificate and private key to the end-user devices. This is secure, as the challenge password is used only between MDM system and SCEPman.
Your MDM system relays SCEP messages between end-user device and SCEPman. The end-user device generates the secret keypair and adds the challenge password to the certificate request. This is less secure, as an attacker with control over a single end-user device may steal the challenge password and request all kinds of certificates from SCEPman. Furthermore, the MDM system cannot control whether the client has correctly requested a certificate or whether the certificate request is incorrect, possibly allowing for identity theft or other threats.
Certificate signing requests sent to SCEPman for signing are authenticated with this secure static password Recommendation: Store this secret in .
Certificate signing requests sent to SCEPman for signing are authenticated with this secure static password Recommendation: Store this secret in .
(optional)
(optional)
The specific steps depend on the MDM system you are using. You must add as SCEP URL somewhere and you must add the challenge password to your MDM system's SCEP configuration. For security reasons, please make your MDM system a SCEP proxy.