I was recently deploying a SCEP (Simple Certificate Enrollment Protocol) server for a client to be used by the Intune Certificate Connector so that they could allow Intune to enroll for certificates on behalf of managed endpoints. This is a fairly-well documented process by Microsoft, but when configuring the Network Device Enrollment Service (sub-role of the Active Directory Certificate Services server role in Windows Server), I encountered a strange error.
On the surface, the error implies that my issuing certification authority server was unavailable, but in testing, I could easily see that the server was up and available on the network. So why this error implies the server "cannot be contacted" required a little more digging.
What I discovered on the issuing certification authority was that the Windows Server was up and running, but the Active Directory Certificate Services service was not running, and would not start. Looking at the Event Viewer, I could see several errors with a little more detail in identifying the root cause.
The Event Viewer error indicated that the revocation server was offline, which didn't necessarily tell me a whole lot, but at least pointed towards the issue being related to certificate revocation.
In my case, my issuing certification authority was publishing CRLs to both Active Directory as well as to a web distribution point, but to determine what could be wrong with revocation services, a tool called CERTUTIL can be used to check revocation lists for published locations for a certificate.
On the issuing certification authority, I ran the following command to launch the CRL URL retrieval tool:
certutil -URL "http://crl.<mydomain.com>/crl/<my_certificate_name>.crt"This was relevant to my environment as I had a web distribution where my certificate and CRLs are being published. The exact path may vary based on where your certificate revocation lists are published.
This command launches the URL Retrieval Tool. Using the Select button, I selected my issuing certification authority's certificate (C:\Windows\System32\CertSrv\CertEnroll\my_certificate_name.crt) and the Retrieve button to retrieve all CRLs from my certificate's CDP settings.
As you can see above, the tool detected a published CRL that was expired. In this case, the CRL was for my offline root certification authority. Because the root is offline, it does not automatically publish new CRLs, nor would it be publishing directly to by web distribution point for the PKI environment.
Therefore, to fix this issue, I needed to boot up my offline root, republish the CRL and then copy it back over to the web distribution to be seen by my issuing certification authority.
After booting up my offline root, the first this was to republish a current CRL. This was done from the Certification Authority management console (expand CA > right-click Revoked Certificates > All Tasks > Publish). This created a new CRL on the offline root, stored in the C:\Windows\System32\CertSrv\CertEnroll directory.
Browsing to the new CRL file on the offline root, I then copied the CRL file to the web server directory that hosts my CRL web distribution. Overwritting the old CRL file, my web distribution now contained the most current (and not expired) version of my root certification authority's CRL.
Going back to my issuing certification authority, I reran the URL Retrieval Tool by clicking Retrieve again, and this time, the base CRL for the offline root certificate now showed up as Verified.
Also looking at the Windows Services running on the server, the Active Directory Certificate Services service was now running. And finally, retrying my configuration of the Network Device Enrollment Service on my SCEP server was able to continue.
Comments