SCEP
Last updated
Was this helpful?
Last updated
Was this helpful?
Cisco first invented the Simple Certificate Enrollment Protocol (SCEP). Although there was no standard at the time, it received widespread adoption in MDM systems. Cisco even moved along and designed a successor protocol, Enrollment over Secure Transport (EST), to replace SCEP. Therefore, EST was made a public standard in RFC 7030 much earlier than SCEP, which was standardized in a lot later, when it was already the de-facto standard for certificate enrollments for MDM systems.
SCEP is HTTP-based. A SCEP Request is an encrypted and signed sent via a GET or POST request to the SCEP service. The service responds with a SCEP Response, again an encrypted and signed PKCS#7. The request contains a certificate signing request, the response contains the issued .
The PKCS#10 request contains a "SCEP Challenge" that authenticates and authorizes the signing request by some out-of-band method depending on the specific SCEP service. There are three kinds of SCEP challenges used in practice today:
The simplest possibility is a static passphrase. If the SCEP Challenge in the PKCS#10 matches a pre-defined value stored on the SCEP service, then the certificate will be issued, otherwise the request will be declined. The problem with this method is that almost no check is possible as to whether the requested properties of the certificate match the requestor. There is even a CVE for this problem.
These methods can be further differentiated:
In the case of a Direct SCEP enrollment, the entity to which the certificate shall be enrolled communicates directly with the SCEP service. For example, an MDM system tells some Android phone to do a SCEP enrollment using the SCEP Challenge "SecurePassword". The Android phone generates a CSR, hopefully with the right values, and adds "SecurePassword" as the SCEP Challenge. It then sends the CSR over to the SCEP service, receiving the issued certificate in return.
A Transparent SCEP Proxy is just like an HTTP Reverse proxy. Because SCEP is encrypted and signed, it cannot actually look into the SCEP requests or responses or even modify them, but it can control who can enroll certificates and when based on network perimeters.
A Protocol Adapter SCEP Proxy is a system that requests certificates through SCEP on behalf of some other system. For example, an MDM system like JAMF could request a certificate from a SCEP service on behalf of some iPhone. Once it has the certificate and private key, it can deploy the certificate through another protocol. This way, only the MDM system has access to the SCEP Challenge, and it can also control the contents of the certificate.
In this case, each SCEP Challenge is valid only for a single certificate request. This allows the SCEP service to identify the SCEP request and verify that the requested certificate properties match those permitted for the specific request.
There are generally two ways used in practice how an MDM system and a SCEP CA may agree upon a SCEP Challenge used for a request:
The MDM system requests a One-Time-Code for a SCEP Request from the SCEP service if it needs one.
An example is Microsoft NDES. NDES features a separate "admin" page that is authenticated with AD credentials. On each access of the admin page, it creates and displays a new one-time-code that can be used for a single SCEP request. When used in this configuration, NDES does not check any properties of the certificate, though, as the one-time-code is generic.
The MDM system generates a one-time-code when it tells a managed system to request a certificate via SCEP. When the SCEP Request arrives at the SCEP Service, the service must fetch the one-time-code from the MDM system, usually with a web hook, and check whether it matches the SCEP Challenge in the request. There is no standard for this protocol, so MDM system and SCEP Service must agree on some format and it depends on the implementation if any properties of the request are checked.
There is virtually no length restriction on the SCEP Challenge. So it doesn't have to be a human-comprehensible "passphrase", but it can also be a BLOB.
Intune uses a signed and encrypted XML as the SCEP Challenge. It creates this XML server-side and sends it to a client device when it wants to enroll a certificate and creates the SCEP Request.
The SCEP Service must send the whole PKCS#10 request to an Intune SCEP Challenge service. The SCEP Challenge service has the private key to decrypt the XML and the public key to check that it was create by a genuine Intune service.
The XML contains metadata about the request like how the Subject is supposed to look like. This is derived on the one hand from the SCEP Configuration Profile and on the other hand on the specific object data of the user or device for whom the certificate shall be issued.
For example, the SCEP Configuration Profile might configure CN={{DeviceId}} for the subject. When the device with id xyz requests a certificate, the XML then says that the subject should be CN=xyz. The SCEP Challenge service then compares the information from the XML with the subject in the PKCS#10 request. It will fail the validation if the subjects differ, and it will succeed if this and the other properties match.
The SCEP Service will only issue the certificate if the validation succeeds.
Microsoft NDES supports this with an additional NDES Policy Module, other SCEP CAs may or may not support this natively.
Microsoft features explaining this verification.
SCEP is the de-facto standard for MDM systems. All important MDM vendors support SCEP, e.g. Microsoft Intune, Jamf, Mosyle, and Kandji. Adoption among CAs is also common, for example Microsoft ADCS can support SCEP through their NDES service for an on-prem implementation. offers a cloud-only implementation.