NDES and the dreaded 2 & 10 Event ids stating “The parameter is incorrect"

Hey Guys Rob here again, today I am going to go over a set of typical Network Device Enrollment Service Event ID’s that you will inevitably encounter if you are maintaining an environment with NDES installed.

These two events always seem to run together and can be seen in the Application Event log.

As you can see, although it is nice to see errors about a service or application, it does you no good if there is not enough information available to make something actionable about the event. Hopefully, this is where this blog will be helpful to all of you.

The above errors happen for one of three common reasons.

1. Access to the Private Keys for one or both Registration Authority (RA) certificates is not possible by the application pool identity account running the SCEP (Simple Certificate Enrolment Protocol) application pool.
   
2. One or both RA certificates were NOT issued by the Certification Authority for which NDES is configured to forward Certificate Service Requests (CSR).
   
3. The RA certificates are failing revocation checks. This means that either its certificates or one of the CA (certification authorities) certificates in the chain are failing revocation checks for some reason. If you try and access either the /CertSrv/MSCEP/MSCEP.dll or /CertSrv/MSCEP_Admin endpoints on the NDES Server you will also see an HTTP 500 error as well.
   

Missing Private Key permissions

Below are the steps for the first scenario to validate / add the application pool identity account.

Private key Permissions:

1. Run: CertLM.msc
   
2. Expand: Certificates - Local Computer\Personal\Certificates
   
3. Click on the new certificate, and then right click on it, and select "All Tasks"
   
4. Click on "Manage Private Keys"
   
5. You should see the Permissions dialog box. Click the Add button, and type in the account running the SCEP Application Pool.
   
6. Click the OK button.
   
7. This account only requires "Allow" "Read" permissions.
   
8. Once the permissions have been configured, click the OK button.
   
9. Do this for all certificates that were recently renewed / issued.
   
10. Open an elevated command prompt and type: IISReset
    
11. Then, test accessing the website.
    

If you are unsure what account is being used for the SCEP application pool, you can find this out by doing the following:

1. Run: InetMgr.exe
   
2. Navigate to: SERVERNAME\Application Pools
   
3. Find the application pool named SCEP, and then look at the Identity column.
   

NOTE: If the NDES role was configured with a non-domain service account and it is leveraging the Application PoolIdentity, please understand the ApplicatonPoolIdentity, and NetworkService are not the computer account. You will need to add NetworkService to the private key permissions for these two accounts. These accounts have very restricted rights on the system itself.

Registration Authority certificates issued by wrong CA.

The second scenario can only happen in a situation where you have more than one Certification Authority in the environment, where you have renewed the Registration Authority certificates, and one or both certificates were NOT issued by the Certification Authority that NDES is sending the certificate service requests to.

The first thing we need to determine is what CA issued the two NDES certificates.

1. Run: CertLM.msc
   
2. Expand: Certificates - Local Computer\Personal\Certificates
   
3. Look at the Issued By column for the current RA certificate. This will tell us the CA that issued the certificates.
   
4. To find out the CA NDES is configured to use run: Regedit.exe
   
5. Navigate to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MSCEP\CAInfo
   
6. The registry value named Configuration shows you the CA computer \ CA Name that NDES is using.
   
7. Validate that this is the CA that issued both RA certificates. If not, delete the certificates not issued by this CA and enroll again.
   

After procuring the NDES certificates from the correct CA, you must perform an IISESET from an elevated command prompt.

One or both RA certificates are failing chaining or revocation checks.

The third scenario is a bit trickier as most customers are not familiar with CAPI2 operational logging and how to interpret the data being provided. I am going to concentrate on looking at the NDES RA certificates to determine if they are failing a revocation check. By no means is this meant to be an exhaustive guide on how to use CAPI2 to troubleshoot chaining or revocation checking failures.

The first two problems usually show themselves once the NDES has been in place for one or more years, and it failed just after replacing the existing NDES certificates. So, if everything was working before replacing the RA certificates, please review the two previous scenarios before jumping to an issue with certificate chaining or revocation checking.

What is certificate chaining?

Certificate chaining refers to the computer being able to take an end entity certificate and follow the chain all the way up to a Root CA certificate that is in the Trusted Root store of the computer. If the certificate cannot be chained to a Root CA certificate, then the certificate would not be considered a ‘Trusted’ certificate since the computer does not trust the root CA that issued the entire certificate chain.

What is revocation checking?

All certificates except Root CA certificates have a field on them called CRL Distribution Points (CDP). This lists different URLs that host a file known as a Certificate Revocation List (CRL). This file lists all issued certificates that, for several reasons, the CA Manager decided should no longer be trusted, and they wanted the world to know about this fact.

Just like certificates, these CRL files have a finite lifetime restricting how long they can be used. Once the CRL’s Next update value has been reached it is no longer trusted, and the computer MUST download the newest CRL at that time. If it fails to download the CRL because the URL is not reachable, or the CRL has not been updated at the URL, then it will generate a revocation check failure. When the revocation check fails, the computer can no longer trust the certificate it was trying to use. In this case, it would mean that NDES would not trust the RA certificate and thus NDES would fail to start / run.

Keep in mind that in a two-tier PKI hierarchy where you have an Offline Root CA and an Online Enterprise Issuing CA that issued the RA certificates, the following checks will happen:

• The RA certificate is going to be looked at to find the download locations of the Online Enterprise Issuing CA’s CRL. Then, we will validate that the RA certificate has NOT been revoked by the Online Enterprise Issuing CA Manager.
  
• The Online Enterprise Issuing CA’s CRL certificate is going to be looked at to find the download locations of the Offline Root CA’s CRL. Then, we will validate that the Online Enterprise Issuing CA certificate has NOT been revoked by the Offline Root CA Manager.
  

As you can see, this can get complicated quickly depending on how many tiers the PKI hierarchy has within the environment.

Enabling logging and data collection.

First, we must enable CAPI2 Operational Event logging on the NDES server in question.

1. Run: Eventvwr.msc
   
2. Navigate to: Event Viewer\Applications and Services Logs\Microsoft\Windows\CAPI2\Operational
   
3. Right click on Operational log, and we are going to do two things:
   
   1. 
      
   2. Increase the log file size to at least 10000. A 1 MB log file is not going to be enough, and if the server is busy 10 MBs might not be enough, but it is a start.
      
   3. Enable the log.
      

[*]Click the OK button.

[*] A few commands need to be run in an elevated command prompt.

1. IISReset
   

b. CertUtil -SetReg Chain\ChainCacheResyncFileTime @Now

c. CertUtil -URLCache * Delete

6. Lastly, try and access the /CertSrv/MSCEP_Admin page. You should see a HTTP 500 error, which is fine at this time, and you should also see the NetworkDeviceEnrollment events of 2 and 10 in the application event logs.

7. Once the issue is reproduced, I suggest you return to the CAPI2 Operational Event log properties and disable it. We do not want other CryptoAPI calls happening on the server to push or overwrite the data in the event log.

The CAPI2 event logs could have quite a few events in them. A good event ID based filter to start with is to only show the following events: 11,30,41-42,51-53,90

To find out what events are of interest for the Registration Authority (RA) certificates, you will want to do a Find in the event logs for either the thumbprint value of the certificate or the subject name of the certificate.

Example of a common RA certificate subject name is: ADATAM-WEB01-MSCEP-RA

The subject name is usually defined as the NDES servers name-MSCEP-RA. Once the certificate has been renewed at least you will want to validate the current subject name is of the Exchange Enrollment Agent (Offline request), and CEP Encryption based templates that are in use.

CAPI2 Events of Interest

It is well to understand a little bit about the different CAPI2 events that you are going to see in the event log that are related to chaining and revocation checking:

Event ID 90 X509 Objects (X509Objects) - Shows all the certificates, CRL’s and OCSP (Online Certificate Status Protocol) Responses it was able to collect either via the certificate stores, or via CryptoAPI cache. This is a good event to review to see if the OS (operating systems) found all certificates in the chain or not. If you do not see a required certificate, then the chaining function will not succeed. This event also shows more detail about each certificate than the other events in the log.

Event ID 11 Build Chain (CertGetCertificateChain) - Shows if the certificate chains to a valid root certification authority. In addition, it does revocation checks to see if all certificates in the chain succeed or fail their revocation check.

Event ID 30 Verify Chain Policy (CertVerifyChainPolicy) - First thing with this event is to determine what Policy is getting verified. There are several types of policy checks that this event will check against (See CertVerifyChainPolicy link above for the list of policy checks). Given the policy it will either show success or failure. The policy check could pass and still show as a failure if Event ID 11 fails because of a revocation check failure you will see this same failure here.

Event ID 41 Verify Revocation (CertVerifyRevocation) - Shows what CAPI2 knows about the status of the CryptoAPI cache in reference to revocation information.

Event ID 42 Reject Revocation Information (CertRejectedRevocationInfo) - Shows that CryptoAPI cached data is being rejected as it is either stale or needs to go off system to get the latest CRL / OCSP response from the network.

Event ID 53 Retrieve Object from Network (CryptRetrieveObjectByUrlWire) - Shows the status of attempting to access a specific AIA or CDP URI (Uniform Resource Identifier). It will give you the call status too.

Example of troubleshooting with CAPI2 logging enabled

1. First filter the collected CAPI2 event log with the following: 11,30,41-42,51-53,90
   
2. Click on Find and type something unique about the certificate. Either Subject Name or thumbprint value.
    
    
    
   
3. We can see the first instance where the subject name is found, and it is shown as an error.
   

5. We can see in event 11 that this is failing a revocation check. You will want to pay attention to the TrustStatus field in the Details section. The first TrustStatus is the overall TrustStatus. This tells you about the entire chain and specifically that one of the certificates in the trust path failed revocation.

Continue reading...