Intune SCEP Certificate Workflow Analysis – Intune PKI Made Easy With Joy – Part 4

Today, we will do an In-depth Analysis of Intune SCEP Certificate Workflow

  • Does Intune perform any behind-the-scenes activity when you configure and deploy a SCEP cert profile?
  • How Intune SCEP certificate connector works?
  • What errors can occur and at what stage of the workflow?

Want to get the answers to the above questions and also clarify your own knowledge regarding Intune SCEP certificate workflow? Well, you are at the right place then.

Welcome to Part 4 of the series Intune PKI Made Easy With Joy.

Long Post Alert! Get your cup of coffee for the company as we start.

Intune SCEP Certificate Workflow

In Part 3, we already did a compare-and-contrast of the Intune SCEP workflow with the General SCEP Workflow, which brought us to the core component of the Intune SCEP PKI architecture –  Intune SCEP Certificate Connector.

We have learned that Intune leverages this connector for automated SCEP Certificate Enrolment Authorization – verification of the challengepassword. But how does Intune request for the enrolment challenge in the first place to provide the device with which it will make the cert enrolment request?

With this question in mind, we can break the Intune SCEP Certificate Workflow into two parts, namely

Adaptiva
  1. SCEP Challenge Generation and Profile Deployment
  2. Verification of the SCEP Cert Request and Cert delivery

As already explained in Part-3 of this series, Intune utilizes a Policy Module to overcome the inherent SCEP vulnerability of enrolment authorization, whereupon request is received, NDES by default validates only the authorization info (challengePassword), but not the request itself.

SCEP Challenge Generation, Intune Profile Validation, and Deployment

Intune SCEP Certificate Workflow - Behind-the-Scenes activity that Intune performs before actual SCEP profile deployment to the endpoints.
Intune SCEP Certificate Workflow – Behind-the-Scenes activity that Intune performs before actual SCEP profile deployment to the endpoints.
  • (1) Admin configures the SCEP profile from Intune console.
  • (2) Admin makes an active assignment of the profile created to a deployment group.

The activities that follow are as below

  • (3) Intune reaches out to Azure AD to retrieve the CN and SAN details for the members of the deployment group and generates the SCEP challenge.
Intune SCEP Certificate Workflow - Intune generates the SCEP challenge as part of behind-the-scenes activity
Intune SCEP Certificate Workflow – Intune generates the SCEP challenge as part of behind-the-scenes activity

The format of CN and SAN is defined by the Admin in the SCEP profile. This information is required by Intune to request NDES/SCEP service for the Enrolment Challenge.

A unique challenge string is generated per SCEP profile configured in Intune. A unique challenge is generated for each member of the deployment group to which the SCEP profile is deployed.

Since cert deployment is possible for only enrolled devices, as such, the SCEP challenge created by Intune is always against the Intune DeviceID.

The details of the challenge generated remain stored with Intune (to be later used for the challenge verification)

  • CN with which the challenge is being generated
  • DeviceID and UserID for which the challenge is being requested
  • Timestamp of the challenge generation

There are two more backend activity that happens before actual deployment (not included in the workflow activity diagram)

  • Effective Group Association/Membership Calculation

Azure AD functionality determines the association of one profile with another profile (in this case, the SCEP profile with the Root cert profile) and/or association of a profile with a user/device.

The reason why it’s recommended to deploy the SCEP profile and Trusted Cert profile (the Issuing CA cert profile) to the same group. Else the profile deployment will fail.

  • Validation of the SCEP profile in itself

The thumbprint of the certificate defined as Root within the SCEP profile should match the thumbprint that which NDESPolicy module reports.

This is why, for a multi-tier PKI, you need to select the trusted cert profile against the CA with which the NDES is configured and not the original Root CA.

If you have created User type SCEP cert profile, but have deployed it to the All Devices group, the profile deployment fails. Intune does not deliver the profile to the device. This is because the SN/SAN attributes are different for Users and Devices.

If the above validation returns True

  • (4) Intune deploys the SCEP profile to the device.

The Enrolment Challenge is injected into the SCEP payload that is delivered to the device, as OMA-DM instructions in the form of SyncML data.

For Windows devices, thanks to Oliver Kieselbach, we can have a SyncML trace that shows the SCEP profile being deployed as below

Truncated to show just an overview
 
<Atomic>
      <CmdID>19</CmdID>
      <Replace>
        <CmdID>3</CmdID>
        <Item>
          <Target>
            <LocURI>./User/Vendor/MSFT/ClientCertificateInstall/SCEP/ModelName_AC_d70bf40e-1822-44b4-9ee5-0cc777c5bf70_LogicalName_3b597a2d_27d2_45ff_bca6_57d2db6f17fb_Hash_1399397888/Install/ServerURL</LocURI>
          </Target>
          <Data>https://joyndes-blueear.msappproxy.net/certsrv/mscep/mscep.dll/</Data>
        </Item>
      </Replace>
      <Replace>
        <CmdID>4</CmdID>
        <Item>
          <Target>
            <LocURI>./User/Vendor/MSFT/ClientCertificateInstall/SCEP/ModelName_AC_d70bf40e-1822-44b4-9ee5-0cc777c5bf70_LogicalName_3b597a2d_27d2_45ff_bca6_57d2db6f17fb_Hash_1399397888/Install/Challenge</LocURI>
          </Target>
          <Data>PENlcnRFbnJvbGxUb2tlbj48RGF0YT48Q2VydEVucm9sbENoYWxsZW5nZT5NSUlOQVFZSktvWklodmNOQVFjRG9JSU04akNDRE80Q0W4+</Data>
        </Item>
      </Replace>
      <Replace>
        <CmdID>7</CmdID>
        <Item>
          <Target>
            <LocURI>./User/Vendor/MSFT/ClientCertificateInstall/SCEP/ModelName_AC_d70bf40e-1822-44b4-9ee5-0cc777c5bf70_LogicalName_3b597a2d_27d2_45ff_bca6_57d2db6f17fb_Hash_1399397888/Install/SubjectName</LocURI>
          </Target>
          <Data>CN=joymalya</Data>
        </Item>
      </Replace>
      <Replace>
        <CmdID>14</CmdID>
        <Item>
          <Target>
            <LocURI>./User/Vendor/MSFT/ClientCertificateInstall/SCEP/ModelName_AC_d70bf40e-1822-44b4-9ee5-0cc777c5bf70_LogicalName_3b597a2d_27d2_45ff_bca6_57d2db6f17fb_Hash_1399397888/Install/CAThumbprint</LocURI>
          </Target>
          <Data>0C93E3B330AC0F3770CCED39CE5EDCBD23919305</Data>
        </Item>
      </Replace>
      <Replace>
        <CmdID>15</CmdID>
        <Item>
          <Target>
            <LocURI>./User/Vendor/MSFT/ClientCertificateInstall/SCEP/ModelName_AC_d70bf40e-1822-44b4-9ee5-0cc777c5bf70_LogicalName_3b597a2d_27d2_45ff_bca6_57d2db6f17fb_Hash_1399397888/Install/SubjectAlternativeNames</LocURI>
          </Target>
          <Data>[email protected];[email protected]</Data>
        </Item>
      </Replace>
      <Exec>
        <CmdID>18</CmdID>
        <Item>
          <Target>
            <LocURI>./User/Vendor/MSFT/ClientCertificateInstall/SCEP/ModelName_AC_d70bf40e-1822-44b4-9ee5-0cc777c5bf70_LogicalName_3b597a2d_27d2_45ff_bca6_57d2db6f17fb_Hash_1399397888/Install/Enroll</LocURI>
          </Target>
        </Item>
      </Exec>
  </Atomic>

From above, you can see the Challenge being provided to the device, which is base64 encoded. Decoding the same, we get the structure below

<CertEnrollToken>
<Data>
<CertEnrollChallenge>MIIN…</CertEnrollChallenge>
<SignerThumbprint>B5B8…</SignerThumbprint>
</Data><Signature>308202...</Signature>
<DeviceID>58c120b7-a22a-428f-89de-7b0856e0c43e</DeviceId>
<CertificateRequestId>ModelName=AC_d70bf40e-1822-44b4-9ee5-0cc777c5bf70/LogicalName_3b597a2d_27d2_45ff_bca6_57d2db6f17fb;Version=1;Hash=1399397888</CertificateRequestId>
<Timestamp>2020-05-24T10:15:52.8276436Z</Timestamp>
</CertEnrollToken>

This completes the backend activity that Intune service performs to deploy a SCEP profile to a device.

SCEP Cert Request Verification, Certificate Generation, and Certificate Deployment

With the profile deployed to the end device, it tries to create a cert enrolment request almost on an immediate basis.

For Windows 10, you can easily track the deployment via Event Viewer

DeviceManagement-Enterprise-Diagnostics-Provider Admin events Event ID 306
SCEP: CspExecute for UniqueId : (ModelName_AC_d70bf40e-1822-44b4-9ee5-
0cc777c5bf70_LogicalName_3b597a2d_27d2_45ff_bca6_57d2db6f17fb_Hash_1399397888)
InstallUserSid : (S-1-12-1-3546063745-1309206162-2641703837-3589660599)
InstallLocation : (user) NodePath : (clientinstall)  KeyProtection: (0x2)
Result : (Unknown Win32 Error code: 0x2ab0003). 

Don’t worry about the Win32 Error code: 0x2ab0003 as returned. This is similar to the friendly error 403 that we expect when we ping the mscep URL. If you get any other error code, that may indicate an underlying issue.

SCEP profile retry count is 3 so it will try to retry certificate enrolment for 3 consecutive times if it encounters any failure, post which Global Re-evaluation Scheme (GRS) kicks in so it will wait 24 hours and then again retry if the profile is still assigned.

DeviceManagement-Enterprise-Diagnostics-Provider Admin events Event ID 309
SCEP: InstallFromRegEntries. CorrelationGuid : ({B3456689-299E-49BF-96D2-
5C8AD7672762}) UniqueId : (ModelName_AC_d70bf40e-1822-44b4-9ee5-
0cc777c5bf70_LogicalName_c087d2cb_d36b_4e81_9629_7f6febd7d88c_Hash_-2086345593)
Certificate Thumbprint : (33E1D2ED6F4BDA72AC543B4987CE4A8C23201DC5) 
Respondent Server : (https://joyndes-blueear.msappproxy.net/certsrv/mscep/mscep.dll//pkiclient.exe) 
Install Status : (0x1) Current Retry Count :  (0x1) 
Result : (The operation completed successfully.)

In the above, you see my Windows 10 client successfully enrolled SCEP cert on 1st attempt [Retry Count: (0x1)]. Any reason for which the SCEP cert enrolment fails, you would have the below event

DeviceManagement-Enterprise-Diagnostics-Provider Admin events Event ID 307
SCEP: Failed LogError Message : (SCEPInstallCertificateWithScepHelper:
Failed to Initialize SCEP enrollment with NDES Server 'https://joyndes-blueear.msappproxy.net/certsrv/mscep/mscep.dll//pkiclient.exe', CA cert 
thumbprint '0C93E3B330AC0F3770CCED39CE5EDCBD23919305' and server certs ''. )

The actual error is reflected in Event ID 32 which follows the above event.

DeviceManagement-Enterprise-Diagnostics-Provider Admin events Event ID 32
SCEP: Certificate enroll failed. Result: (Gateway timeout (504).).
SCEP: Certificate enroll failed. Result: (Bad Gateway (502).).
SCEP: Certificate enroll failed. Result: (Internal server error (500).).
SCEP: Certificate enroll failed. Result: (Service unavailable (503).).
SCEP: Certificate enroll failed. Result: (Request entity too large (413).).
SCEP: Certificate enroll failed. Result: (Request uri too long (414).).

Since our aim is to check the activities that are performed for the cert enrolment request that the device makes, let us continue with that.

Intune SCEP Certificate Workflow - SCEP Cert Request Verification, Certificate Generation and Certificate Deployment
Intune SCEP Workflow – SCEP Cert Request Verification, Certificate Generation and Certificate Deployment

From this point onwards, I have tried to map the errors that we face commonly with SCEP, to each step of the workflow. This would help you understand the breakpoints in the Intune SCEP Certificate activity workflow.

The resolution to the errors is already present in the Microsoft documentation of troubleshooting SCEP.

  • (1) Device prepares the CSR as per the information provided by Intune via the SCEP profile and makes the cert enrolment request to the SCEP URL. [App Proxy External URL]

This can again be tracked in the Event Viewer as below

DeviceManagement-Enterprise-Diagnostics-Provider Admin events Event ID 36
SCEP: Certificate request generated successfully. Enhanced Key Usage: (2.5.29.37.0),
NDES URL: (https://joyndes.msappproxy.net/certsrv/mscep/mscep.dll//pkiclient.exe).
Container Name: (), KSP Setting: (0x2), Store Location: (0x1).

The error that can occur at this stage:

Proxy ErrorSCEP endpoint URL is not accessible.

502 Bad Gateway
504 Gateway Timeout
This page cannot be displayed/Can't reach this page

However, if the proxy is working fine, then

  • (2) App Proxy (WAP or Azure) maps the incoming request to the original (internal) SCEP endpoint.

/certsrv/mscep virtual app running in SCEP application pool of IIS is the intended receiver for the request. However, the actual SCEP cert request call that the device makes is not logged in the IIS. But you can always see the call via a network trace capture of the client device.

GET /certsrv/mscep/mscep.dll/pkiclient.exe operation=pkiOperatio&message=
<URL Encoded Encrypted CSR>

IIS only records the GetCACert and GetCACaps call that the device makes.

Log reference C:\inetpub\logs\LogFiles\W3SVC1
2020-05-24 10:16:03 fe80::8cc4:3d89:80d0:ac2c%5 GET /certsrv/mscep/mscep.dll/pkiclient.exe operation=GetCACaps&message=default 443 - fe80::8cc4:3d89:80d0:ac2c%5 Mozilla/4.0+(compatible;+Win32;+NDES+client+10.0.18362.1/19h1_release) - 200 0 0 0

2020-05-24 10:16:03 fe80::8cc4:3d89:80d0:ac2c%5 GET /certsrv/mscep/mscep.dll/pkiclient.exe operation=GetCACert&message=default 443 - fe80::8cc4:3d89:80d0:ac2c%5 Mozilla/4.0+(compatible;+Win32;+NDES+client+10.0.18362.1/19h1_release) - 200 0 0 11

The error that can occur at this stage:

SCEP URL not giving the expected 403 Error.

Http Error 500 - Internal Server Error
Http Error 503. The service is unavailable
Http Error 414 - URI Too Long
Http Error 413 - Payload Too Large
  • (3) NDESPlugin module intercepts the incoming request to verify and validate the SCEP Cert request calls.

To start intercepting the incoming requests mscep URL the NDESPlugin needs to initialize.

Log reference C:\Program Files\Microsoft Intune\NDESPolicyModule\Logs\NDESPlugin.log

<![LOG[==========[ NDES policy module started in process 3708 ]==========]LOG]!>
<![LOG[Calling Initialize...]LOG]!>
<![LOG[certificate registration point web server is NDES.joymalya.xyz]LOG]!>
<![LOG[NDES thumbprint is d00593a15526f6026d4e4ebafcf85eccd5389f01.]LOG]!>
<![LOG[certificate registration point webservice URL is CertificateRegistrationSvc]LOG]!>
<![LOG[CA Issuer Name is WIN-2CQQDB9STE6.joymalya.xyz\\joymalya-WIN-2CQQDB9STE6-CA]LOG]!>
<![LOG[Certificate registration port number is 443]LOG]!>
<![LOG[Exiting Initialize with 0x0]LOG]!>

NDESPlugin module looks for the information required for initialization from the following reg_path HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MSCEP\Modules\NDESPolicy

Intune SCEP Certificate Workflow - NDESPlugin Module Initialization - Information is retrieved from Registry
Intune SCEP Certificate Workflow – NDESPlugin Module Initialization – Information is retrieved from Registry

Errors that can occur in this phase:

NDESPlugin module initialization failure resulting “Http Error 503. The service is unavailable.” 

Plugin fails initialization if,

  • the thumbprint of the NDESPolicy module certificate does not match the thumbprint of the IIS SSL binding certificate.

This mainly happens when you have not selected the same SSL cert used for IIS port binding while installing the Intune SCEP certificate connector.

  • the NDESPolicy module certificate [IIS SSL Binding Cert] has expired.

It may also happen that you used the same SSL cert initially, but post renewal of the SSL cert, the NDESPolicy module registry still holds the old cert value.

  • (4) NDESPlugin invokes CRP to perform validation checks for request verification. This is the VerifyRequest call.
Log reference C:\Program Files\Microsoft Intune\NDESPolicyModule\Logs\NDESPlugin.log
<![LOG[Calling VerifyRequest ...]LOG]!>
<![LOG[Sending request to certificate registration point.]LOG]!>

This is the corresponding POST you see in IIS log

Log reference C:\inetpub\logs\LogFiles\W3SVC1
2020-05-24 10:16:06 fe80::8cc4:3d89:80d0:ac2c%5 POST
/CertificateRegistrationSvc/Certificate/VerifyRequest - 443 - fe80::8cc4:3d89:80d0:ac2c%5 NDES_Plugin - 201 0 0 1191

Error that can occur in this phase:

error 12175 in the nedsplugin.log -- WINHTTP_CALLBACK_STATUS_FLAG_CERT_CN_INVALID  
Verify challenge returns -- 403 - Forbidden: Access is denied.
Verify Challenge returns False - CRP log captures the following event Signing certificate could not be retrieved.

CRP handles the VerifyRequest function. It retrieves the signing cert and encryption cert details from registry, verifies message signature, and decrypts the enrolment request message to retrieve the CSR and enrolment challenge-response information.

VerifyRequest is performed in 3 validation phases

  • Phase 1 Validation – The message signature is verified and message body is decrypted to retrieve the CSR and the enrolment challenge response which is to be verified in the next step.
  • Phase 2 Validation – Checks if the challenge has expired.
  • Phase 3 Validation – The CN (Subject Name) is retrieved from the CSR to check if it matches the one for which the challenge was generated.
Log reference C:\Program Files\Microsoft
Intune\NDESConnectorSvc\Logs\Logs\CertificateRegistrationPoint_<datetime>.svclog
Intune SCEP Certficate Workflow - CRP Log Analysis - Cert Request Validation for Challenge
Intune SCEP Certficate Workflow – CRP Log Analysis – Cert Request Validation for Challenge

Error that can occur in this phase:

Special characters in CN will result in a failure resulting in CRP output – Subject Name in CSR and challenge do not match.

Check this MS document for reference.

  • (5)Once you see VerifyRequest function exiting with Success status, the same is recorded in NDESPlugin.log
Log reference C:\Program Files\Microsoft Intune\NDESPolicyModule\Logs\NDESPlugin.log
<![LOG[Verify challenge returns true]LOG]!>
<![LOG[Exiting VerifyRequest with 0x0]LOG]!>
  • (6) NDESPlugin makes Notifyrequest call to invoke CRP again

NDESPlugin calls the Notifyrequest function to start the notify process to Intune service. The function is again handled by CRP.

Log reference C:\Program Files\Microsoft Intune\NDESPolicyModule\Logs\NDESPlugin.log
<![LOG[Calling Notifyrequest ...]LOG]!>
<![LOG[Sending request to certificate registration point.]LOG]!>

The subsequent IIS log [reference C:\inetpub\logs\LogFiles\W3SVC1] entry for the same is

2020-05-24 10:16:17 fe80::8cc4:ac2c%5 POST /CertificateRegistrationSvc/Certificate/Notify - 443 - fe80::8cc4:3d89:80d0:ac2c%5
NDES_Plugin - 204 0 0 53

As a part of this function call

  • (7) CRP makes certificate request to the CA

CRP uses the template specified in MSCEP registry that matches the CSR to make the certificate request to CA on-behalf using the NDES service account. CA returns the created cert package back to CRP.

  • (8) CRP drops the Certificate Request Status (.CRS) file
Log reference C:\Program Files\Microsoft
Intune\NDESConnectorSvc\Logs\Logs\CertificateRegistrationPoint_<datetime>.svclog
Dropping file D6CB79962ED142C7B045DC2ED8384609.CRS for Certificate Request Status
Data for User : d35ca381-e692-4e08-9d33-759db7dff5d5, Device : 58c120b7-a22a-428f-89de-7b0856e0c43e, CertificateRequestId : ModelName=AC_d70bf40e-1822-44b4-9ee5-0cc777c5bf70/LogicalName_3b597a2d_27d2_45ff_bca6_57d2db6f17fb;Version=1;Hash=1399397888, Transaction: 59d8b46f903cefd84e9886384eac32c19d266dfa
Successfully dropped file.
  • (9) Exit status of Notifyrequest function tells NDESPlugin the Success or Fail status.

The activities [6, 7, 8, 9] are represented in CRP log as below

Intune SCEP Certificate Workflow - CRP Log Analysis - Notifyrequest function call
Intune SCEP Certificate Workflow – CRP Log Analysis – Notifyrequest function call

The corresponding entry in the Plugin log

Log reference C:\Program Files\Microsoft Intune\NDESPolicyModule\Logs\NDESPlugin.log
<![LOG[Exiting Notify with 0x0]LOG]!>
  • (10) NDESPlugin uploads the Certificate Request Status data [.CRS] to Intune via connector communication.

This is a concurrent process that happens alongside the Notifyrequest function call made by NDESPlugin.

Log reference C:\Program Files\Microsoft Intune\NDESConnectorSvc\Logs\Logs\NDESConnector_<datetime>.svclog
Processing upload operation: CertificateData.
Retrieving certificate request status data.
Reading records from certificate request processing directory.
Reading files from C:\Program Files\Microsoft Intune\CertificateRequestStatus\Processing.
Reading file C:\Program Files\Microsoft Intune\CertificateRequestStatus\Processing\D6CB79962ED142C7B045DC2ED8384609.CRS.
ModifyData source file: C:\Program Files\Microsoft Intune\CertificateRequestStatus\Processing\D6CB79962ED142C7B045DC2ED8384609.CRS.
Inserting file C:\Program Files\Microsoft Intune\CertificateRequestStatus\Succeed\D6CB79962ED142C7B045DC2ED8384609.CRS.
ModifyData resoulting file: C:\Program Files\Microsoft Intune\CertificateRequestStatus\Succeed\D6CB79962ED142C7B045DC2ED8384609.CRS.
Deleting modified file C:\Program Files\Microsoft Intune\CertificateRequestStatus\Processing\D6CB79962ED142C7B045DC2ED8384609.CRS
Cleaning up stale processing files...
Done processing certificate upload operation.

It is because of this upload operation, that you get the certificate details up in the Intune console

Intune SCEP Certificate Workflow - Plugin uploads processed cert data to Intune to be visible from the Intune console
Intune SCEP Certificate Workflow – Plugin uploads processed cert data to Intune to be visible from the Intune console
  • (11) The certificate package is delivered to the device.

This is the corresponding POST you see in IIS log

Log reference C:\inetpub\logs\LogFiles\W3SVC1
2020-05-24 10:16:17 fe80::8cc4:3d89:80d0:ac2c%5 POST /certsrv/mscep/mscep.dll/pkiclient.exe operation=PKIOperation 443 - fe80::8cc4:3d89:80d0:ac2c%5 Mozilla/4.0+(compatible;+Win32;+ NDES+client+10.0.18362.1/19h1_release) - 200 0 0 11977

Device end, this can be tracked in the Event Viewer as below

DeviceManagement-Enterprise-Diagnostics-Provider Admin events Event ID 39
SCEP: Certificate installed successfully.

Miscellaneous

IN NDES box, check the location

C:\Program Files\Microsoft Intune\CertificateRequestStatus

Intune SCEP Certificate Workflow - File location where you can see Proecssed cert request data
Intune SCEP Certificate Workflow – File location where you can see Proecssed cert request data

When the SCEP service receives a certificate request, the certificate request is processed in the Processing folder as a Certificate Request Status (CRS) file. During this time NDESPlugin is verifying and validating the request as part of the VerifyRequest function call. Once validation completes and CRP makes the cert request to CA to get the cert package, post that, the CRS file is moved to the Uploading folder, from where NDESPlugin uploads the cert details to Intune. Once the upload is complete, the CRS file is moved to the Succeed folder.

This is what the content of a CRS file looks like when you open it.

<?xml version="1.0" encoding="utf-8"?>
<CertRequestStatus xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance">
  <Version>9</Version>
  <CertSerialNumber>310000002D6DCE18E89139A74000000000002D</CertSerialNumber>
  <UserID>d35ca381-e692-4e08-9d33-759db7dff5d5</UserID>
  <DeviceID>58c120b7-a22a-428f-89de-7b0856e0c43e</DeviceID>
  <IssuerCA>WIN-2CQQDB9STE6.joymalya.xyz\joymalya-WIN-2CQQDB9STE6-CA</IssuerCA>
  <UploadAttempt>1</UploadAttempt>
  <UploadStatus>2</UploadStatus>
  <Thumbprint>584206D25F2384491CC55AD28B77E1DA7BD6821D</Thumbprint>
  <CertificateRequestID>ModelName=AC_d70bf40e-1822-44b4-9ee5-0cc777c5bf70/LogicalName_c51ae254_120a_4b23_8821_7ac9b77f82fd;Version=4;Hash=588295043</CertificateRequestID>
  <TransactionID>4802535d6cdeb195fce65c97aadc1163f855488e</TransactionID>
  <CertExpirationDate>4/11/2022 4:26:36 AM</CertExpirationDate>
  <Status>0</Status>
  <HResult>0</HResult>
</CertRequestStatus>

CRS for failed cert request will land in the Failed folder.

The End

The purpose of this article was to empower you with the complete Intune SCEP Certificate workflow knowledge so that you can confidently determine the scope of the issue while working on any SCEP-related issue.

I know at first glance, this stuff seems hard but believe me, once you get through the lab yourself, you will agree that this is the easiest thing to troubleshoot in the Intune world.

Don’t worry, my next post will be a Troubleshooting Checklist for Intune NDES to help you have an easy tracker of things that you need to confirm or validate while working on an Intune SCEP issue.

Till then, Stay Safe!

16 thoughts on “Intune SCEP Certificate Workflow Analysis – Intune PKI Made Easy With Joy – Part 4”

  1. Hello Joymalya,

    deploying SCEP certificates became a lot easier after reading your blog posts, especially troubleshooting them. However, I am encountering a problem right now that I can’t solve and I can’t really read out why I am stuck.
    The current situation is that the SCEP certificate seemingly gets deployed correctly to all devices, except to our Surface Pro ones. The process seems to “get lost” somewhere after the profile got deployed/the cert request. The last thing I can track is a seemingly successful 306 event, after that I can find nothing. Any idea in what direction I should go or look now?

    Reply
    • Hi Tobias,

      Is there any sort of AV on your surface pro. Turn off AV and initiate a MDM sysnc and check.
      I have seen 3rd party AV blocking SCEP cert deployment, even if you have successful events. The cert just “stays in the air”

      Reply
      • Hi Joymalya,

        it’s ironically another problem that there are no AV solutions that seem to work besides Windows Defender, due to the different processor architecture. At least when I got that right. We didn’t even try that and just run Windows Defender with ATP on the Pro X.

        I found out by now that multiple sysadmins seem to have that problem, together with the Microsoft Support seemingly not responding to support requests (maybe to stall time while they fix the problem.).

  2. Hi Anoop

    Your blogs are very helpful and very well explained in detail.

    I have questions:

    1. Does Intune connector installed on NDES server need any direct connectivity? I mean through firewall. If i configure the connection through proxy, is that suffice?

    2. which network channel CRP use to deliver certificate to device?

    Thanks
    Swaran

    Reply
    • Hi Swaran,

      Intune connector communication is outbound as it polls intune in regular intervals to check for new cert requests.
      You can definitely route the connection via a Proxy, you just have to set proxy config in the connector setup UI.
      Related to your query with CRP, as far as I know, for Intune, CRP delivers the cert back to NDES service which is intercepted by the NDESPlugin component and is uploaded to Intune. Intune then delivers it to the endpoints.
      I hope this helps.

      Regards,
      Joy

      Reply
      • Thanks Joy for your response…this is definitely helpful.
        One more clarification: Does Intune store the cert for endpoints in blob.
        Thanks
        Swaran

  3. Thanks for wonderful blog. This really helped me clarifying many doubts. Really appreciate !!
    I have one more clarification regarding the environment where we have two AD forests with their individual PKI infrastructure and synchronizing to same tenant. I hope we can use SCEP for users/devices of both the forests and upload Root CA from individual PKI environment to push on devices by scoping them by group membership. Can you provide some issues that we can face in such scenario ?
    Thanks
    Parveen Khanna

    Reply
    • Hi Praveen,

      Thanks for your query. To be honest, I have yet not checked or worked with SCEP where multiple forests are involved syncing to the same tenant, and each forest has it’s own PKI infrastructure.
      As per MS, there can only be one issuing CA for a tenant, but this again goes on the topic of HA and I need to check in my lab before I can give you any definite answer to this.

      Hope you would understand.

      Regards,
      Joy

      Reply
  4. Hi,

    I am, unable to get my Inmtune SCEP working and i get the below error.

    Could uou please help in pointing to the right direction what might be wrong here?

    I have checked the NDES SSL cert and binding and also registry values and all seems to be OK.

    Thanks

    Reply
  5. Hello Joymalya,
    Thanks for the explanation.

    Assuming SCEP certificate for Windows 10 clients is rolled out via Intune, I’m curious about the process when a client certificate has expired. Will the windows clients automatically receive a new certificate?

    Kind regards,

    Reply
    • Hi Cor,

      Yes, when a SCEP certificate pushed via Intune nears its expiration, based on the Renewal Threshold value you have defined in the SCEP profile, it will automatically try to get renewed within that threshold period, provided the user and device are active.

      Regards,
      Joy

      Reply
  6. Do you have any list of Use cases that why we needed NDES/SCEP profile for Intune.
    Even, we can configure the profiles manually, where NDES is not required.

    Reply
    • Hi Naveen,

      If you deliver the same cert to all your endpoints, then there is no requirement for NDES/SCEP.
      However, if you want that your users/devices will receive uniques certs to be used for specific purposes, then it would require either NDES/SCEP implementation or the simpler PKCS, whichever be the need as per security.
      Organizations do prefer SCEP due to more security, but it comes with its own complexity to setup.

      If you don’t want to bear through all the complexity of SCEP setup on-premises, there is SCEP-as-a-service from SCEPMan. Ref: https://scepman.com/
      My colleague has a blog on it if you would like to know more about the how-to. https://hmaslowski.com/home/f/scepman-an-intune-scep-as-a-service-certificate-authority

      Hope I was able to answer your original question.

      Regards,
      Joy

      Reply
  7. Hello Joymalya,
    Thanks for the blog, it has been very useful for me!

    However, during the installation, I have faced an error that I am not able to solve, even having opened a support case with Microsoft Team.

    The error comes when the NDES_Plugin sends the VerifyRequest to the CRP, because it answers with a 404 Error.

    I have 2 environments and the deployment works well on the Testing Environment, but when I make the installation on the Production Environment, it fails with that error.

    Here you can see the IIS logs for both environments:
    https://imgur.com/a/77aRnpz you can see

    Have you ever seen this error before? Do you know how I can solve it?

    Thanks in advance, best regards!

    Reply
  8. Hi

    A customer or mine is attempting to configure a router so that it will authenticate with their client’s NDES server; using SCEP to sign its certificate

    I had previously set up a SCEP requestor prototype for my customer using FreeRadius/Debian; in lieu of NDES.
    It wasn’t a simple setup since there was also dot1x in the mix.

    The requestor is a Mikrotik Routerboard device running RouterOS

    The initial SCEP certificate signing request works fine; thanks to the use of an OTP

    The problem is that we can’t get the certificate renewal process to work.

    The NDES server receives the renewal request from the RouterBoard and fails with the following error message:

    Error,19/01/2021 17:26:08,Microsoft-Windows-NetworkDeviceEnrollmentService,28,None,The Network Device Enrollment Service cannot locate a required password in the certificate request. Either a password must be present in the certificate request or the certificate request should be signed with a valid signing certificate. The signing certificate must chain up to a trusted root in the Enterprise store. The signing certificate and the certificate request must have the same subject name or subject alternate name.

    When you read it it seems as if either :

    – RouterOS isn’t providing the necessary security info – AFAIK OTP is only required to sign the initially certificate – so this looks like a “red herring”

    – the original certificate isn’t (properly ?) signing the CSR – I assume that this part of RouterOS’ automated renewal process. Not sure what I can do about this

    – the issue could be linked to a difference in common or subject alternate name between the CRT and the CSR.
    I would assume that the RouterOS SCEP implementation generates the CSR based on the existing CRT,
    therefore the common and subject alternate names should coincide

    Any ideas, questions or suggestions ?

    Thanks for reading

    regards
    yann

    Reply
  9. No words to your clear explanation of scep – i was been trying to understand of PKI of scep in many sites but i could not get it later the exact i got from your posts 1,2,3,4
    If a bike mechanic knows how it works then he know where to troubleshoot same like that now i understood exact scep flow so I by myself can come to know where and what could be issues also now I analyze the issues by splits and troubleshoot appreciate for your effort
    Thanks again

    Reply

Leave a Comment

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