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.

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.

Patch My PC
Does it involves a standard process? If yes, what protocol(s) is/are used?

Let’s check out.

Video Tutorial

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).

However, of all the protocols listed above, the focus of this article is 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.

Adaptiva

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 IISSCEP, 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.

NDES - RA Certificates - CEP Encryption and Exchange Enrollment Agent
NDES – RA Certificates – CEP Encryption and Exchange Enrollment Agent

SCEP supported deployment models

SCEP supported deployment models - Enterprise CA and Standalone CA deployment
SCEP supported deployment models – Enterprise CA and Standalone CA deployment
  • Standalone CA model – The CA is not domain joined and as such supports the NDES role to be 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 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 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 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 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 cert 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) 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.
SCEP General Workflow - Admin configures device to generate RSA key pair and Transaction Identifier
SCEP General Workflow – Admin, configures the device to generate RSA key pair and Transaction Identifier

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).
SCEP General Workflow - Device Admin configures device to make a call to the SCEP service to retrieve the CA cert chain
SCEP General Workflow – Device Admin configures the device to make a call to the SCEP service to retrieve the CA cert chain
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.
SCEP General Workflow - Device Admin retrieves Enrolment Authorization Challenge from SCEP service
SCEP General Workflow – Device Admin retrieves Enrolment Authorization Challenge from SCEP service

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
SCEP General Workflow - Device Admin configures the device with the information required to make the certificate enrolment request
SCEP General Workflow – Device Admin, configures the device with the necessary information to make the certificate enrolment request

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
  • 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.
SCEP Workflow General - Device prepares the Certificate Signing Request
SCEP Workflow General – Device prepares the Certificate Signing Request

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.

SCEP General Workflow - Device sends the cert enrolment request to the SCEP service. SCEP verifies the signature to ensure origin authenticty and then decrypts the request message to retrieve the CSR and challengePassword.
SCEP General Workflow – 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

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

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.

SCEP General Workflow - RA makes request to CA to generate certificate
SCEP General Workflow – RA makes a request to CA to generate a 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.

SCEP General Workflow - NDES/RA (SCEP service) delivers the certificate package as recieved from CA to the Requestor
SCEP General Workflow – NDES/RA (SCEP service) delivers the certificate package as received from CA to the Requestor

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, nor 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, and 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!

Resources

8 thoughts on “Knowing SCEP – The General Workflow Intune PKI Made Easy With Joy – Part 2”

  1. Hi Joymalya,

    Thanks for the great 4 part series. For the first time in life, I now understand what purpose does digital certificate and signature solves. I am at the 2nd part right now – and I am trying to wrap my head around NDES. Could you please explain in a bit more detail about NDES?

    Thanks!

    Reply
  2. Great article, but somehow I did not find any mention of operation = PKIOperation. How can SCEP discussion be ever complete without mentioning this? It seems that you are suggesting that the the Certificate signing Request is sent using the same GetCACert operation which does not sound right.

    Reply
  3. Standalone CA model – The CA is not domain joined and as such supports the NDES role to be installed on the CA itself.

    So can we install the Intune connector to the same server with the above model?

    Do we need EA permission to install NDES?

    Reply

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.