Home certificate intune scep troubleshooting

Troubleshooting Intune: SCEP Certificate Verification Errors and Request Failures

Updated: • 0 • min read
Table of Contents

This article provides detailed methods to resolve issues where a Simple Certificate Enrollment Protocol (SCEP) certificate request fails during the verification phase within Microsoft Intune. These failures often occur on the certificate registration point (CRP) and prevent devices, such as those running Android or iOS, from successfully obtaining necessary SCEP certificates, even when the Network Device Enrollment Service (NDES) infrastructure appears to be configured.

Symptoms of SCEP Verification Failure

When SCEP certificate requests encounter verification errors on the Certificate Registration Point (CRP), several symptoms become apparent. The primary indicator is the inability of targeted devices (e.g., Android, iOS) to receive SCEP certificates. This lack of certificates typically impacts device ability to connect to resources secured by certificate-based authentication, such as corporate Wi-Fi networks, VPNs, or internal websites. While the NDES infrastructure itself might seem operational, the breakdown occurs specifically during the request verification stage processed by the CRP component.

Further investigation into the CRP server logs reveals specific error entries that pinpoint the nature of the failure. These logs are crucial for diagnosing the root cause. A common pattern observed in the logs points to cryptographic exceptions encountered during the processing of the certificate request challenge password. These errors indicate a problem with handling the certificates used in the verification process.

Examining the CRP logs, specifically the CertificateRegistrationPoint source, will likely show entries similar to the following, repeating across different stages of the validation process:

First Error Entry Example

<Source Name="CertificateRegistrationPoint" />
Cryptography Exception: System.Security.Cryptography.CryptographicException: m_safeCertContext is an invalid handle.
  at System.Security.Cryptography.X509Certificates.X509Certificate.ThrowIfContextInvalid()
  at System.Security.Cryptography.X509Certificates.X509Certificate.SetThumbprint()
  at System.Security.Cryptography.X509Certificates.X509Certificate.GetCertHashString()
  at Microsoft.ConfigurationManager.CertRegPoint.Helper.ValidateChallenge(String base64Encodedtoken, X509Certificate2Collection encryptedCerts, X509Certificate2 SigningCert, String& decodedChallengePassword)

This initial log entry often appears when the system attempts basic operations on a certificate object, such as retrieving its thumbprint (GetCertHashString), but finds the underlying certificate handle (m_safeCertContext) is invalid. This suggests the certificate required for processing the challenge password could not be properly loaded or referenced by the application.

Second Error Entry Example

Cryptography Exception: System.Security.Cryptography.CryptographicException: m_safeCertContext is an invalid handle.
  at System.Security.Cryptography.X509Certificates.X509Certificate.ThrowIfContextInvalid()
  at System.Security.Cryptography.X509Certificates.X509Certificate.SetThumbprint()
  at System.2ecurity.Cryptography.X509Certificates.X509Certificate.GetCertHashString()
  at Microsoft.ConfigurationManager.CertRegPoint.Helper.ValidateChallenge(String base64Encodedtoken, X509Certificate2Collection encryptedCerts, X509Certificate2 SigningCert, String& decodedChallengePassword)
  at Microsoft.ConfigurationManager.CertRegPoint.ChallengeValidation.ValidationPhase1(VerifyChallengeParams value, String& decodedChallenge, PKCSDecodedObject& pkcsObj)

This second entry shows the same cryptographic exception, but this time it’s occurring within ValidationPhase1 of the challenge validation process. This phase is critical for initial decryption and processing of the SCEP challenge password submitted by the device. The failure here indicates the CRP cannot correctly process the encrypted challenge due to the invalid certificate handle, halting the verification flow early.

Third Error Entry Example

Cryptography Exception: System.Security.Cryptography.CryptographicException: m_safeCertContext is an invalid handle.
  at System.Security.Cryptography.X509Certificates.X509Certificate.ThrowIfContextInvalid()
  at System.Security.Cryptography.X509Certificates.X509Certificate.SetThumbprint()
  at System.Security.Cryptography.X509Certificates.X509Certificate.GetCertHashString()
  at Microsoft.ConfigurationManager.CertRegPoint.Helper.ValidateChallenge(String base64Encodedtoken, X509Certificate2Collection encryptedCerts, X509Certificate2 SigningCert, String& decodedChallengePassword)
  at Microsoft.ConfigurationManager.CertRegPoint.ChallengeValidation.ValidationPhase1(VerifyChallengeParams value, String& decodedChallenge, PKCSDecodedObject& pkcsObj)
  at Microsoft.ConfigurationManager.CertRegPoint.Controllers.CertificateController.VerifyRequest(VerifyChallengeParams value)

The third entry places the exception within the CertificateController.VerifyRequest method, the high-level function handling the incoming verification request. The propagation of the m_safeCertContext is an invalid handle error up the call stack reinforces that the core issue lies with the CRP’s ability to handle the necessary cryptographic certificates, which are likely referenced in the Intune Connector’s configuration used by the CRP. These certificates are essential for decrypting the SCEP challenge password and verifying the request’s authenticity.

Cause of the Cryptography Exception

The primary cause identified for the m_safeCertContext is an invalid handle cryptography exception during SCEP verification on the CRP is the absence of critical registry keys within the NDES connector’s configuration settings. The Microsoft Intune Connector, installed on the NDES server, relies on specific registry values under HKLM\Software\Microsoft\MicrosoftIntune\NDESConnector to function correctly, particularly for processing and verifying SCEP requests.

These missing registry keys are responsible for storing configuration details that the CRP component uses to locate and utilize the necessary certificates (like the signing and encryption certificates) required to validate the SCEP challenge password sent by the device. If these keys are missing, the CRP application pool identity cannot retrieve the references to these certificates, leading to the “invalid handle” error when it attempts to perform cryptographic operations. The absence of these keys can occur due to various reasons, including installation issues with the NDES connector, problems during service startup where the keys are normally written, or potential manual configuration errors.

Solution 1: Restart the Intune Connector Service

A common initial step to resolve issues stemming from service initialization or configuration loading is to restart the relevant service. The Microsoft Intune Connector service is responsible for writing necessary configuration information, including potentially these crucial registry keys, upon startup. Therefore, restarting this service can trigger the re-creation or correction of the missing registry entries.

Follow these steps carefully:

  1. Open the Services Snap-in: Access the Windows Services management console on the server where the Microsoft Intune Connector is installed. The quickest way is to open the Start menu, type services.msc into the search bar, and select Services from the list of results. This will launch the Services window, which lists all services configured on the server.

  2. Locate and Restart the Service: In the Services window, scroll through the list of services to find the entry named “Microsoft Intune Connector”. Once located, right-click on the service name. From the context menu that appears, select the Restart option. This action will stop the service gracefully and then attempt to start it again. The restart process should be relatively quick. Monitor the service status column to ensure it successfully transitions back to the “Running” state.

  3. Verify Registry Keys: After restarting the service, it is crucial to verify that the necessary registry keys have been created or populated correctly. Open the Registry Editor by typing regedit in the Start menu search and pressing Enter. Navigate to the following registry subkey: HKLM\Software\Microsoft\MicrosoftIntune\NDESConnector.

    Look for keys related to the certificates used by the connector and CRP. While a specific list isn’t provided in the source, common keys here include those referencing the signing and encryption certificates used in the SCEP process. Check if new values or keys have appeared under this path after the service restart. These keys typically store certificate thumbprints or other identifiers that allow the CRP to find and load the certificates required for validating SCEP requests. The presence of populated values under this key after the restart is a good indication that the service initialization process has run successfully.

    Registry Editor Path

    Example verification: After navigating to HKLM\Software\Microsoft\MicrosoftIntune\NDESConnector, confirm that expected configuration keys, often related to certificate identifiers or service settings, are present and populated with appropriate values. The exact keys might vary slightly depending on the connector version, but their presence is key.

If restarting the Microsoft Intune Connector service and verifying the registry keys resolves the issue (i.e., SCEP requests start succeeding and CRP logs no longer show the cryptography exception), then the problem was likely temporary configuration loss or failure during initial service startup. If the problem persists, or the registry keys do not appear/are not correctly populated after the restart, proceed to Solution 2. You may also consider restarting the NDES server itself after restarting the service as an additional troubleshooting step, as this can ensure all related components and dependencies are re-initialized.

Solution 2: Clear and Reset the Template Name Configuration

If Solution 1 does not resolve the SCEP verification errors, the issue might be related to inconsistencies or errors in how the certificate template name is configured and referenced across the different components involved in the SCEP process. This includes the Certificate Authority (CA), the NDES server’s registry, and the Intune SCEP profile. The error “m_safeCertContext is an invalid handle” can also occur if the CRP, referencing configuration from the NDES connector, cannot properly load the certificate template required for processing the request, perhaps due to a mismatch or misconfiguration related to the template name or permissions.

This solution involves carefully reviewing and potentially reconfiguring the certificate template settings to ensure they are correctly defined and accessible by the NDES connector and CRP.

  1. Verify the Certificate Template on the CA:

    • Open the Certification Authority snap-in on your issuing CA server. Go to Start, type certsrv.msc, and press Enter.
    • Navigate to Certificate Templates. Right-click and select Manage to open the Certificate Templates Console.
    • Locate the certificate template specifically configured for SCEP requests via Intune/NDES. This template is usually duplicated from the “User” or “Computer” template and modified with specific settings (e.g., Purpose set to Signature and encryption, Subject name built from Active Directory or provided in the request, permissions for the NDES server’s service account).
    • Right-click on the SCEP template and select Properties.
    • Note the exact Template display name and the Template name (for Active Directory) on the General tab. These names are often the same but can differ. Ensure the template name does not contain special characters or leading/trailing spaces.
    • Go to the Security tab. Verify that the NDES server’s computer account (or a security group it belongs to) has Read and Enroll permissions on this template. The service account running the NDES application pool (usually DefaultAppPool running as ApplicationPoolIdentity by default, but often configured to run as a service account or Network Service for NDES) must also have these permissions. If the NDES application pool is running as ApplicationPoolIdentity or Network Service, ensure that the NDES server’s computer account has Enroll permission. If it runs as a dedicated service account, that account needs Enroll permission.

  2. Verify the Template Name in the NDES Registry:

    • On the NDES server, open the Registry Editor (regedit).
    • Navigate to HKLM\SOFTWARE\Microsoft\Cryptography\MSCEP.
    • Examine the values for the SCEP template names configured here. Typically, there are keys like EncryptionTemplate, GeneralPurposeTemplate, and SignatureTemplate. For standard SCEP configurations via Intune, the display name of your SCEP certificate template configured on the CA must match the value in the GeneralPurposeTemplate key exactly.
    • Compare the template display name noted in step 1 with the value in GeneralPurposeTemplate. They must be identical, including spacing and casing. If they don’t match, do not edit the registry directly. The correct process is to modify which templates are supported by NDES through the Server Manager console under IIS > Internet Information Services (IIS) Manager > Default Web Site > SCEP. Click on the SCEP application, open Feature View, double-click Certificate Authority. Here you can see the list of supported templates. Ensure your SCEP template is listed, and its display name matches your template on the CA. NDES reads this configuration and writes it to the registry.
    • If the template name is incorrect in the IIS configuration for the SCEP application, correct it there and then restart the NDES server and the IIS Admin service.

  3. Verify the Template Name in the Intune SCEP Profile:

    • Log in to the Microsoft Endpoint Manager admin center (endpoint.microsoft.com).
    • Navigate to Devices > Configuration profiles.
    • Find and select the SCEP profile assigned to your devices.
    • Go to Properties > Settings.
    • Locate the setting for the certificate template name. The name entered here must exactly match the Template name (for Active Directory) from the CA template properties (General tab, not the display name unless they are the same). This is a critical distinction: the NDES registry often uses the display name, while the Intune profile uses the Active Directory template name.
    • Correct the template name in the Intune profile if it does not match the Active Directory template name from your CA. Save the profile.

  4. Clear and Reset (Retest): The process of “clearing and resetting” implies ensuring these template names are consistent everywhere. After verifying and correcting any mismatches in steps 1-3:

    • Restart the Microsoft Intune Connector service on the NDES server (as in Solution 1).
    • Restart the NDES service.
    • Restart the IIS Admin Service (iisreset from an elevated command prompt).
    • Consider restarting the Certificate Authority service on the CA server (use caution during production hours).
    • Retest the SCEP enrollment from a device.

By ensuring the certificate template name is correctly configured and consistent across the CA, NDES registry, and Intune profile, and by verifying the necessary permissions are granted to the NDES server and application pool identity, you eliminate common sources of failure related to template loading and access. The “invalid handle” error can stem from the CRP’s inability to load the required template definition or associated keys needed for processing, which these steps address.

Checking Other Relevant Logs

If the above solutions do not resolve the issue, examining other logs on the NDES server and Certificate Authority can provide additional clues.

  • NDES Server Event Viewer: Check the Application and System logs for errors or warnings related to SCEP, NDES, or IIS. Look for events from sources like Microsoft-Windows-NetworkDeviceEnrollmentService or IIS-IISCERTSRV.
  • IIS Logs: The NDES server runs within IIS. Check the IIS logs (usually located in C:\inetpub\logs\LogFiles\W3SVC\) for requests to the /certsrv/mscep endpoint. Look for HTTP status codes other than 200. 500-series errors indicate server-side issues.
  • Certificate Authority Event Viewer: On the CA server, check the Application logs for events from source Microsoft-Windows-CertificateServices. Look for failed certificate requests or errors related to template processing or permissions.

These logs can help identify issues beyond the initial CRP verification failure, such as problems with NDES communicating with the CA or issues with the request format itself.

SCEP Process Flow Overview

Understanding the basic SCEP process flow helps in troubleshooting:

  1. Device Request: A device targeted with an Intune SCEP profile generates a public/private key pair locally. It creates a Certificate Signing Request (CSR) containing the public key and device information, and includes a unique challenge password provided by Intune.
  2. Intune Communication: The device sends the CSR and challenge password to the NDES server’s SCEP endpoint (/certsrv/mscep).
  3. NDES Processing: The NDES server receives the request. It forwards the challenge password to the Certificate Registration Point (CRP) component (which is part of the Intune Connector).
  4. CRP Verification: The CRP receives the challenge password from NDES. Using certificates and configuration information (often from the NDES Connector registry keys), it decrypts and verifies the challenge password against what Intune expects. This is where the “invalid handle” error occurs if configuration is missing or incorrect.
  5. Request Submission (if verified): If the challenge verification succeeds, the NDES server submits the CSR to the Certificate Authority (CA) on behalf of the device, using the configured certificate template.
  6. CA Issuance: The CA receives the request, validates it against the template policies and permissions, and if valid, issues the certificate.
  7. NDES Retrieval: NDES retrieves the issued certificate from the CA.
  8. Device Retrieval: The device contacts the NDES server again (or NDES pushes the certificate depending on configuration) to retrieve the issued certificate.

The errors discussed in this article specifically target Step 4, the CRP Verification phase.

SCEP Process Flow Diagram

Conclusion

Troubleshooting SCEP certificate request failures during the verification phase requires a systematic approach, focusing initially on the components responsible for processing the challenge password: the Microsoft Intune Connector and its associated Certificate Registration Point (CRP). The Cryptography Exception indicating an “invalid handle” often points to configuration issues preventing the CRP from properly loading or referencing the necessary certificates. Restarting the Intune Connector service can often resolve this by re-initializing and writing correct configuration keys to the registry. If the issue persists, verifying and correcting the certificate template configuration – ensuring consistency across the Certificate Authority, NDES registry, and Intune profile, along with correct permissions – is the next critical step. Always remember to check relevant logs on the NDES server and CA for more specific error details.

Have you encountered this specific error before? What steps did you find most effective in resolving it within your environment? Share your experiences and insights in the comments below!

Post a Comment