The revocation function was unable to check revocation because the revocation server was offline.
I recently migrated our CA root to a server with a different name. After bringing this online I am only now publishing AIA and CRL locations via LDAP (Not http). My Enterprise PKI has no problems and the AIA, CDP, and DeltaCRL location seem to all be fine. I'm able to issue certs without any problems. I'm only running into an issue on our Network Policy Access server where this error is preseted: The revocation function was unable to check revocation because the revocation server was offline. I tried to renew the RAS IAS cert on the server, but the problem persists. Any ideas? Not sure how or where it's looking for the revocation server. I would have assumed it'd be through AD.
April 27th, 2012 11:21am

1) You did not update the paths correctly after renaming the servers. I would not necessarily trust PKIview. Try using certutil -verify -urlfetch cert.cer against the latest certificate issued by the CA. If there is not one, revoke the last CA Exchange certificate and issue a new one by running certutil -cainfo xchg. 2) What you have done is a worst practice. If you are going with one protocol, HTTP is the protocol to use. If you are using both HTTP and LDAP, HTTP should be searched first before LDAP (to allow revocation checking by non-windows clients or non-domain joined machines or external machines that cannot contact DCs) Bottom line, you cannot contact a DC with the provided paths to perform revocation checking Brian
Free Windows Admin Tool Kit Click here and download it now
April 27th, 2012 12:35pm

when you mention cert.cer which path should I be looking in for that? You need to export the CAExchange certificate yourself and name it cert.cer. The path is where ever you save it. Your chocice to go with only LDAP is a poor decision. Hope you do not plan to ever do VPN, etc. The old certificates will have to be all replaced since you renamed everything. If you had used HTTP, you may have gotten away with CNAMEs. (or a batch file to copy the files from the new name to the old name) It looks like you did not test your migration plan before moving to production :-( Brian
April 27th, 2012 1:18pm

I'll publish a new delta CRL. The http of SERVER1 is the old server. As mentioned prior, I don't want to use http at the moment. HOWEVER, I do believe this is why I'm seeing this error in the first place. From reading the NPS documentation it requires a Primary and a Secondary CRL, it also verify's the root CRL points from the cert. I only have a single LDAP CRL at the moment. Premigration there were http CRL's as per the output. Post migration there are no http CRL's (Reason for failed CDP in the output). I guess my questions are: When I publish a new CRL does this update the root certificate?Will the clients be updated with the new CRL for each of their certs, or will I need to reissue/renew certs?How do I get rid of the failed http CRL's that have the old server name? As I believe everything else is funcitoning correctly, I'm going to move forward with placing this CA on a Stand-Alone root CA with the same migration steps performed. Only this time I will issue a SubCA cert, and setup IIS/Web Enrollment on it to eliminate these CRL check errors. Thanks for all your assistance!
Free Windows Admin Tool Kit Click here and download it now
April 30th, 2012 2:50pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics