Home certificate services microsoft intune ndes troubleshooting

Intune Certificate Connector: Troubleshooting NDES Policy Module Installation

Updated: • 0 • min read
Table of Contents

The Network Device Enrollment Service (NDES) policy module, integrated with the Microsoft Intune Certificate Connector, plays a crucial role in certificate deployment within your organization. This module acts as a validator, ensuring that every certificate request originating from a device is legitimate and compliant with your established policies. When a device requests a certificate through NDES, the request is first routed to this policy module for thorough validation. Upon successful validation, NDES proceeds to communicate with the Certificate Authority (CA) to procure the certificate on behalf of the requesting device.

This article is designed to guide you through the process of verifying the operational status of the NDES policy module and to provide troubleshooting steps should you encounter any issues. The information presented here is relevant to both Step 3 and Step 4 of the broader SCEP (Simple Certificate Enrollment Protocol) communication workflow, focusing specifically on the interaction between NDES and the policy module.

NDES Communication to the Policy Module

After a device initiates a certificate request, NDES begins the validation process by communicating with Intune through the policy module. This policy module, installed alongside the Microsoft Intune Certificate Connector, functions as the certificate registration point. Successful communication and validation are essential for the smooth operation of certificate enrollment.

Log entries that indicate success:

To confirm that the validation request is successfully delivered to the policy module, examine the logs on your NDES server for entries similar to the examples provided below. These entries are critical indicators of successful communication and validation initiation.

  • IIS logs: These logs track web server activity and will show the HTTP POST request to the Certificate Registration Service.

    fe80::f53d:89b8:c3e8:5fec%13 POST /CertificateRegistrationSvc/Certificate/VerifyRequest - 443 -
fe80::f53d:89b8:c3e8:5fec%13 NDES_Plugin - 201 0 0 341 875

    This log entry signifies a successful POST request to the /CertificateRegistrationSvc/Certificate/VerifyRequest endpoint, indicating that the validation process has been initiated. The 201 status code confirms successful resource creation.

  • NDESPlugin log: This log provides detailed information about the activities of the NDES plugin, including communication with the certificate registration point.

    Calling VerifyRequest ...
Sending request to certificate registration point.

    These entries clearly show that the VerifyRequest function is being called and that a request is being sent to the certificate registration point for validation.

    The following log entries in the NDESPlugin log indicate that the device’s challenge request has been successfully validated, and NDES is now ready to contact the CA to issue the certificate.

    Verify challenge returns true
Exiting VerifyRequest with 0x0

    The “Verify challenge returns true” message is a key indicator of successful validation. “Exiting VerifyRequest with 0x0” indicates a successful operation with no errors.

  • CertificateRegistrationPoint.svclog: This log provides insights into the operations performed by the certificate registration point service, including detailed validation phases.

    Validation Phase 1 finished with status True.
Validation Phase 3 finished with status True.
VerifyRequest Finished with status True

    These entries confirm the successful completion of different validation phases by the certificate registration point. “Status True” at each phase and for the overall VerifyRequest signifies successful validation.

When success indicators aren’t present:

If you are unable to locate these success indicators in your logs, it suggests that the validation request might not be reaching the policy module or is encountering issues during processing. In such scenarios, it is recommended to begin by reviewing the troubleshooting guidance specifically for device to NDES server communication. This will help you identify potential connectivity problems or initial configuration issues.

If the device to NDES server communication troubleshooting steps do not resolve the issue, further investigation into specific error entries within the logs is necessary. The following sections detail common error scenarios and their respective solutions.

NDESPlugin.log contains an error 12175

An error code 12175 in the NDESPlugin.log, often accompanied by messages similar to the example below, typically points to problems with the SSL certificate used for secure communication.

WINHTTP_CALLBACK_STATUS_FLAG_CERT_CN_INVALID
Failed to send http request /CertificateRegistrationSvc/Certificate/VerifyRequest. Error 12175

This error, WINHTTP_CALLBACK_STATUS_FLAG_CERT_CN_INVALID, indicates that the Common Name (CN) in the SSL certificate might not be valid or might not match the server name being accessed. While modern browsers and mobile device browsers are more lenient and often ignore the Common Name if Subject Alternative Names (SANs) are present, the underlying system components might still enforce stricter checks.

Solution: To rectify this SSL certificate related issue, you need to reissue the web server SSL certificate with specific attributes for both the Common Name and Subject Alternative Name. After reissuing, ensure this certificate is correctly bound to port 443 in IIS (Internet Information Services). The recommended attributes are as follows:

  • Subject name:
    • CN = external server name (This should be the externally accessible hostname of your NDES server.)
  • Subject Alternative Name:
    • Name = external server name (Repeat the external server name here.)
    • DNS Name = internal server name (Include the internal hostname or FQDN of the NDES server.)

SSL Certificate Subject Alternative Name

By including both the external and internal server names in the Subject Alternative Name, you ensure that the SSL certificate is valid and trusted regardless of how the server is accessed (internally or externally). Rebinding the certificate to port 443 in IIS ensures that the updated certificate is used for HTTPS traffic.

NDESPlugin.log contains an error 403 – Forbidden: Access is denied”

An error 403, specifically “Forbidden: Access is denied,” in the NDESPlugin.log and IIS logs, as illustrated in the examples below, usually indicates an issue with client certificate trust or validity.

NDESPlugin.log:

Sending request to certificate registration point.
Verify challenge returns <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/></head>
<title>403 - Forbidden: Access is denied.</title>

IIS log:

POST /CertificateRegistrationSvc/Certificate/VerifyRequest - 443 -<IP_address>
NDES_Plugin - 403 16 2148204809 453

This 403 error often arises when intermediate CA certificates are inadvertently present in the NDES server’s Trusted Root Certification Authorities certificate store. It is important to distinguish between root and intermediate certificates. A root certificate is self-signed, meaning the “Issued to” and “Issued by” fields are identical. In contrast, an intermediate certificate is issued by a root or another intermediate certificate, and thus the “Issued to” and “Issued by” fields will differ.

Solution: The resolution for this issue involves identifying and removing any intermediate CA certificates from the Trusted Root Certification Authorities certificate store on the NDES server. Intermediate certificates should reside in the Intermediate Certification Authorities store, not the Trusted Root store.

Windows Certificate Store

To remove the intermediate certificates from the Trusted Root store:

  1. Open the Microsoft Management Console (MMC).
  2. Add the Certificates snap-in, and choose Computer account.
  3. Navigate to Certificates (Local Computer) > Trusted Root Certification Authorities > Certificates.
  4. Carefully examine the certificates in this store. Identify any certificates that are not root certificates (i.e., “Issued to” and “Issued by” are different). These are likely intermediate certificates.
  5. Delete any identified intermediate certificates. Be extremely cautious not to delete actual root certificates.

After removing the erroneous intermediate certificates from the Trusted Root store, restart the NDES service and IIS to ensure the changes are fully applied.

NDESPlugin.log indicates the challenge returns false

When the NDESPlugin.log indicates that the challenge verification returns false, it is crucial to examine the CertificateRegistrationPoint.svclog for more detailed error information. A common error in this scenario is “Signing certificate could not be retrieved,” which might appear as follows:

Signing certificate could not be retrieved. System.Security.Cryptography.CryptographicException: m_safeCertContext is an invalid handle. at System.Security.Cryptography.X509Certificates.X509Certificate.ThrowIfContextInvalid() at System.Security.Cryptography.X509Certificates.X509Certificate.GetCertHashString() at Microsoft.ConfigurationManager.CertRegPoint.CRPCertificate.RetrieveSigningCert(String certThumbprint

This error message suggests that the NDES Connector is unable to retrieve the signing certificate required for communication with Intune. This can be due to various reasons, including registry configuration issues or network connectivity problems.

Solution: To address this “Signing certificate could not be retrieved” error, verify the SigningCertificate registry value on the server where the Intune Connector is installed.

  1. Open the Registry Editor (regedit.exe) on the NDES server.
  2. Navigate to the registry key: HKLM\SOFTWARE\Microsoft\MicrosoftIntune\NDESConnector.
  3. Check if the value named SigningCertificate exists within this key. This value should contain the thumbprint of the signing certificate used by the Intune Connector.

Registry Editor

If the SigningCertificate value is missing, try restarting the Intune Connector Service.

  1. Open Services (services.msc).
  2. Locate the service named “Intune Connector Service”.
  3. Restart the service.
  4. After restarting the service, re-examine the registry to see if the SigningCertificate value has appeared.

If the value is still missing after restarting the service, it often indicates a network connectivity problem between the NDES server and the Intune service in the cloud. Ensure that the NDES server can properly communicate with Intune endpoints over the internet, and that there are no firewall rules or proxy configurations blocking this communication. Verify internet connectivity and DNS resolution from the NDES server to Microsoft Intune services.

NDES passes the request to issue the certificate

Once the certificate registration point (policy module) successfully validates the certificate request, NDES proceeds to pass the request to the Certificate Authority (CA) to issue the certificate on behalf of the device. This step represents the final stage of certificate enrollment.

Log entries that indicate success:

To verify that NDES is successfully passing the request to the CA, look for the following log entries, which indicate successful communication and request forwarding.

  • NDESPlugin log:

    Verify challenge returns true
Exiting VerifyRequest with 0x0

    These log entries, identical to those indicating successful validation, confirm that the challenge was successfully verified before proceeding to request the certificate from the CA.

  • IIS logs:

    fe80::f53d:89b8:c3e8:5fec%13 GET /certsrv/mscep/mscep.dll/pkiclient.exe ... 80 -
fe80::f53d:89b8:c3e8:5fec%13 Mozilla/4.0+(compatible;+Win32;+NDES+client) - 200 0 0 2713 1296

    This IIS log entry shows a successful GET request to /certsrv/mscep/mscep.dll/pkiclient.exe, which is the endpoint used by NDES to request certificates from the CA. The 200 status code confirms a successful HTTP request.

  • CertificateRegistrationPoint.svclog:

    Validation Phase 1 finished with status True.
Validation Phase 3 finished with status True.
VerifyRequest Finished with status True

    These entries, again, reiterate the successful validation process completed by the certificate registration point before NDES proceeds to the CA.

When success indicators aren’t present:

If you do not observe these log entries indicating success, it suggests that the certificate request is not being successfully passed to the CA. In this case, follow these troubleshooting steps:

  1. Examine CertificateRegistrationPoint.svclog for errors during challenge verification. Focus on entries between “VerifyRequest Started” and “VerifyRequest Finished with status False”. These entries might contain specific error messages that pinpoint the problem encountered during validation.

  2. Open the Certification Authority MMC on the CA server and check the “Failed Requests” queue. This queue lists certificate requests that the CA was unable to process. Examine the failed requests for errors that can provide clues about the cause of the failure.

    Certification Authority Failed Requests

  3. Review the Application event log on the CA server for errors. The application event log often contains detailed error messages related to certificate issuance failures, which may correspond to the errors seen in the “Failed Requests” queue.

    Windows Application Event Log

By examining these logs and error queues on both the NDES server and the CA, you should be able to identify the point of failure in the certificate request process and take appropriate corrective actions.

Next steps

Successfully troubleshooting the NDES policy module is crucial for ensuring smooth certificate enrollment in your Intune environment. By carefully examining the logs and following the solutions provided for common errors, you can diagnose and resolve issues effectively. Further investigation may involve reviewing CA configurations, network configurations, and Intune policy settings to ensure end-to-end certificate deployment success.

Do you have any further questions or experiences troubleshooting NDES policy module issues? Share your thoughts and insights below!

Post a Comment