Hi, welcome to Part 2 of the series Intune SCEP Certificate Enrolment Workflow Made Easy With Joy.
We have learned the basic concepts of PKI, things like encryption, signature, digital certificate, 3rd party PKI trust, and chain building in Part 1 of this series.
If you are not aware or well versed with the concepts of PKI, I would suggest reading this series sequentially to help clarify the basics and then move forward.
Today in this article, we will learn how an end entity requests the Certificate Authority (CA) to get a certificate.
Does it involves a standard process? If yes, what protocol(s) is/are used?
Let’s check out.
Certificate Provisioning Protocols
There are different protocols defined by the IETF RFCs that an end entity can use for obtaining a certificate (x.509) from CA in Public Key Infrastructure (PKI).
- Certificate Management Protocol (CMP)
- Certificate Management over Cryptographic Message Syntax (CMS) [CMC]
- Simple Certificate Enrolment Protocol (SCEP)
- Enrolment over Secure Transport (EST)
However, of all the protocols listed above, the focus of this article is SCEP.
Being an Intune Administrator, we commonly refer to SCEP as a certificate (I myself do that), but that is in the generic sense of the deployment type.
SCEP is not a certificate standard but a protocol, developed by Cisco and documented in Internet Engineering Task Force (IETF) draft, that an end entity can use to make a public key certificate request to the PKI.
Simple Certificate Enrollment Protocol (SCEP) is a protocol (heavily based on CMP and CMC) for certificate enrolment, certificate renewal and certificate and CRL queries in a closed PKI environment.
It makes use of the following IETF defined standards
- PKCS#7 – Cryptographic Message Syntax (CMS) used to protect the request/response cryptographic message
- PKCS#10 – Certification Request Standard used by the client to make the actual certificate request (generation of CSR)
Off the different certificate profiles deployable from Intune, the name of the configuration item "SCEP certificate" under Device Configuration profile of each supported platform simply means, that the managed client will make a certificate request to the underlying PKI infrastructure following SCEP protocol, to gain a certificate (user/device based) which can be used as an authentication purpose (mostly used for this) for other profiles such Wi-Fi/VPN/Email.
Network Discovery Enrolment Service ADCS role is a requirement of the SCEP
General Implementation of SCEP with NDES
SCEP service is implemented as an Internet Server API (ISAPI) extension.
The reason when you install and configure the NDES role, the IIS server role also gets installed as part of the process.
The ISAPI extension runs in its own application pool in IIS – SCEP, within which it creates two virtual applications.
- /certsrv/mscep – used for communication between the NDES and the certificate Requestor (end device)
- /certsrv/mscep_admin – used to retrieve enrollment password
The NDES service itself requires two certificates to work –
- Enrollment Agent Certificate – allows NDES to send the certificate enrollment request to CA
- Key Exchange Certificate – used to protect the cert enrolment request message that the client makes to NDES
These are the Registration Authority (RA) certificates installed on the NDES server when you configure the NDES role.
SCEP supported deployment models
- Standalone CA model – The CA is not domain joined and as such supports NDES role to be installed on the CA itself.
- Enterprise CA model – The CA is domain joined and NDES role needs to be configured on a separate server than the CA.
In PKI infrastructure, Certificate Authority (CA) is the entity which issues the certificate, where Registration Authority (RA) is an entity which receives the certificate enrolment request, validates the request for authorization before sending the request over to the CA. In other words, the RA acts as a middle-man between the Requestor and the CA.
Since Microsoft Intune’s implementation of SCEP is based on the Enterprise deployment model using Automated Authorization, the general SCEP certificate enrolment request workflow as outlined below is based on the same model. This will help you to correlate to the Intune SCEP certificate deployment workflow, which will be covered in details in Part-3 of this series, “Intune PKI Made Easy With Joy.” Stay tuned!
Before starting with the actual workflow, we need to understand the following.
You can pretty well understand that without any authorization check, any entity can make a certificate request if it gets to know the details (key usage information, intended purpose, etc.) required to make the request and gain the certificate.
This essentially defies security, and as such, SCEP protocol defines two authorization modes available to authorize SCEP certificate enrolment requests. They are,
- Manual Authorization – In this mode, the certificate enrolment request is placed in
PENDINGstate till the CA operator authorizes or reject the request. The authorization data is based on SHA-1, SHA-256, SHA-512 or MD5 hash of the CSR (PKCS#10) which is sent out-of-band to the CA operator, who must compare the value as received with the certificate request. In this mode, the requestor (end entity) enters into
POLLINGstate, periodically sending a
GetCertInitialPKI message to the CA/RA until the operator authorizes the request.
- Automated Authorization – In this mode, a
pre-shared secretis generated by the SCEP server to uniquely associate with the enrollment request. The administrator needs to set the device with the secret, so that when the device (requestor) makes the certificate enrolment request, it includes the secret for automated authorization. PCKS#7 enveloping and signing of the certificate request message ensures privacy of the shared secret. This is the
SCEP protocol cert enrolment request – General Workflow [Enterprise Model, Automated Authorization]
1 – Requestor Initialization – Admin configures device to generate RSA key pair and Transaction Identifier
Admin configures the device to generate an RSA public/private key pair. The cryptographic key usage for this key pair depends on the Key Usage value that the Admin configured. It can be configured for either
- Digital Signature, or
- Key Encipherment, or
The Private Key (dev_priv_key) is stored securely and never leaves the device. The Public Key (dev_pub_key) is used for external cryptographic operations.
A PKI operation (cert enrolment request) is a transaction consisting of the messages exchanged between the Requestor (device) and the CA/RA. Thus to track a PKI operation, all messages exchanged between the Requestor and CA/RA for that particular PKI operation must have the same identifier. This is called the transaction identifier.
Since all PKI operation is initialized by the requestor, it is the responsibility of the requestor to generate a unique string to be used as the transaction identifier. It can be generated either by SHA-1, SHA-256, SHA-512 or MD5 hash of the guitar public key (dev_pub_key) as generated above.
2 – Admin configures the device to Trust the CA
Admin configures the device to make a call to the SCEP service to obtain Certificate Authority (CA) public certificate (CA_pub_key).
This is a http(s) GET REQUEST in IIS where operation=GetCACert, the RESPONSE to which is a degenerate PKCS#7 message containing the CA certificate as binary-encoded x.509 in the Content-Type. For multi-tier PKI, complete chain of certificate to Root is returned.
The CA certificate, as returned, is installed to the device trusted cert store to establish CA trust.
The GetCACert call also returns the RA encryption certificate along with the CA certificate, which will be later used by the device to protect the Certificate Signing Request (CSR).
You will also see a http(s) REQUEST where operation=GetCACaps, the RESPONSE to which contains the CA capabilities as returned. This is used by the Device Admin to configure the device to create the appropriate cert enrolment request.
3 – Admin retrieves Enrolment Authorization Challenge from SCEP service
The device admin navigates to
<NDES FQDN>/certsrv/mscep_admin to get the SCEP
The page also returns the issuing CA cert thumbprint. This is used by the Admin for validation - the thumbprint as returned must match with the CA certificate thumbprint as returned by the GetCACert call in the previous step.
4 – Admin configures the device with the information required to make the certificate enrolment request
The device admin then configures the device with the following information
- Challenge Password – To be used for authorizing the enrolment request.
- Certificate type – The CSR needs to specify the entity type of the certificate
- SCEP endpoint URL – The endpoint to which the device will make the cert request
- Subject Name and Subject Alternate Name – To identify the entity for which the certificate is being requested
- Certificate validate period – To specify the timeframe the certificate will remain valid (unless revoked)
- Key Usage – To define the certificate use-case
- Key size – To define the size of keys to be used while creating the certificate
- Hash algorithm – To define the algorithm to be used for generating the keys
- Extended Key Usage – To define the additional use-case of the certificate.
- Renewal Threshold – To define the threshold when the device should start making renewal calls for the cert
5 – Device initiates the Enrolment Transaction
With all the necessary information to make the cert enrolment request being configured by the Admin, the Requestor (device) initiates the enrollment transaction by generating a Certificate Signing Request (PKCS#10) using the device keys generated in step 1 and the information as set by the device admin in step 4.
The request contains –
- challengePassword (for enrolment authorization)
The entire package is protected with the RA encryption certificate and signed with the device private key. This is PKCS#7 enveloping and signing to prevent "man-in-middle" attacks.
6 – Device sends the enrolment request to the SCEP endpoint (NDES)
The SCEP service (NDES) receives the cert enrolment request from the Requestor and verifies the signature using the device public key to check the origin authenticity. It then decrypts the request package to retrieve the CSR and the authorization information. It first validates the authorization.
7 – NDES makes request to CA to generate certificate
Post successful validation of authorization, NDES (RA) examines the CSR to decide which template to use to create the certificate request to CA on behalf of the Requestor using the SCEP service account.
How the certificate template is decided? The CSR contains the Key Usage information - either Digital Signature, or Key Encipherment or both. Based on the key usage provided in the CSR, the RA checks the template that is to be used. The information of which template to use for different Key Usage scenario is there in the registry path HKLM\SOFTWARE\Microsoft\Cryptography\MSCEP
The service account that RA uses to generate the on-behalf request to CA must have ENROLL permission set for the certificate template.
The communication between the NDES (RA) and CA is supported by the other RA cert – Exchange Enrollment Agent certificate.
Upon receiving the request from RA, CA generates a public/private key pair as defined in the template, and also generates a x.509 certificate for the public key.
CA then protects the certificate package encrypting it with the dev_pub_key sent along with the request and signing it with the CA_priv_key (PKCS#7 Envelope and Signing) before handing it over to the RA.
8 – SCEP delivers the certificate package to the requestor
Upon receiving the certificate package from CA, SCEP service (NDES) sends out the package to the original Requestor – Device.
This completes the general workflow of the SCEP certificate enrolment request.
To be contd. (Part 3 coming soon)
The workflow of the SCEP cert enrolment request, as outlined above, is the general workflow. The Microsoft Intune implementation of SCEP for certificate deployment is a bit different, which we will cover in Part 3…
Till now, we have not brought Intune into the picture, neither have talked about how it works with SCEP. The reason was to start with the basics first, building the foundation.
Now that we are ready, in the next part, I will get into the details of how Microsoft Intune implements SCEP, the function of the Intune NDES certificate connector, dig deeper into the certificate enrollment request process that an Intune managed device makes. Stay tuned for Part 3 (coming soon) of this article!
Till then, keep reading, keep learning, and last but not least – Stay Safe!