Knowing SCEP – The General Workflow Intune PKI Made Easy With Joy – Part 2

Hi, welcome to Part 2 of the series Intune SCEP Certificate Enrolment Workflow  Made Easy With Joy.

In Part 1 of this series (Learn The Basic Concepts of PKI – Intune PKI Made Easy With Joy Part-1), we learned the basic concepts of PKI, such as encryption, signature, digital certificate, third-party PKI trust, and chain building.

If you are not aware of or well-versed in the concepts of PKI, I suggest reading this series sequentially to help clarify the basics before proceeding.

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.

Index
Video Tutorial
Certificate Provisioning Protocols
Understanding SCEP
General Implementation of SCEP with NDES
SCEP-Supported Deployment Models
Enrollment Authorization
SCEP Protocol Certificate Enrolment Request
To be contd. (Part 3 coming soon)
Resources

Video Tutorial

In this video, we will learn how an end entity requests the Certificate Authority (CA) to get a certificate.

Certificate Provisioning Protocols

The IETF RFCs define different protocols that an end entity can use to obtain 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, this article focuses on SCEP. 

Understanding 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 the Internet Engineering Task Force (IETF) draft that an end entity can use to request 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 the Device Configuration profile of each supported platform 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.

This is because 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, creating 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 configuring the NDES role.

SCEP-Supported Deployment Models

• Standalone CA model: The CA is not domain-joined and, as such, supports the NDES role being installed on the CA itself.
• Enterprise CA model: The CA is domain-joined, and the NDES role needs to be configured on a separate server from 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 detail 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.

Enrollment Authorization

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 PENDING State till the CA operator authorizes or rejects the request. The authorization data is based on the SHA-1, SHA-256, SHA-512 or MD5 hash of the CSR (PKCS#10), sent out-of-band to the CA operator, who must compare the value received with the certificate request. In this mode, the requestor (end entity) enters into POLLING state, periodically sending a GetCertInitial PKI message to the CA/RA until the operator authorizes the request.

• Automated Authorization – In this mode, a pre-shared secret is 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 challengePassword attribute [PKCS#9].

SCEP Protocol Certificate Enrolment Request – General Workflow [Enterprise Model, Automated Authorization]

1 – Requestor Initialization – Admin configures the 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
• Both.

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) consists of 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, which 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 call the SCEP service to obtain the 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 in the device’s 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 challengePassword. 

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 Alternative 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 – The 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 –

• CSR
• dev_pub_key
• challenge password (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 – The 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.

The device sends the cert enrolment request to the SCEP service. SCEP verifies the signature to ensure origin authenticity and then decrypts the request message to retrieve the CSR and challengePassword.

7 – NDES makes a request to CA to generate a 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 – the 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 by 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)

As outlined above, the SCEP cert enrolment request workflow is the general workflow. The Microsoft Intune implementation of SCEP for certificate deployment is a bit different, which we will cover in Part 3…

We have not brought Intune into the picture yet, nor have we talked about how it works with SCEP. The reason was to start with the basics, building the foundation.

Now that we are ready, in the next part, I will discuss how Microsoft Intune implements SCEP, the function of the Intune NDES certificate connector, and 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!

Resources

• Active Directory Certificate Services (AD CS): Network Device Enrollment Service (NDES)

We are on WhatsApp. To get the latest step-by-step guides and news updates, Join our Channel. Click here –HTMD WhatsApp.

Author

Joymalya Basu Roy is an experienced IT service professional with almost five years of experience working with Microsft Intune. He is currently working as a Senior Consultant and architect with Atos India. He is an ex-MSFT employee, where he worked as a Premiere Support Engineer for Microsoft Intune. In the early stages of his career, he was also associated with Wipro and TCS. In 2021, he was awarded the Microsoft MVP award for Enterprise Mobility. You can find all his latest posts on his blog, MDM Tech Space, at https://joymalya.com.