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

0
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 performs 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.

Previous articles of this series

Long Post Alert! Get your cup of coffee for 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 to the device with which it will make the cert enrolment request?

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

  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 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 active assignment of the profile created to a deployment group.

The activities that follows 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 remains 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 which 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 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 to 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 device, thanks to Oliver Kieselbach, we can have a SyncML trace which 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>2+joymalya@joymalya.xyz;11+joymalya@joymalya.xyz</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 like 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 profile deployed to end device, it tries to create a cert enrolment request almost on the 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 be 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 are 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).

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

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 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 how the content of a CRS file looks like, when you open it.

<?xml version="1.0" encoding="utf-8"?>
<CertRequestStatus xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://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 most 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 a Intune SCEP issue.

Till then, Stay Safe!

LEAVE A REPLY

Please enter your comment!
Please enter your name here

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