Certificate Error

Posted on 2014-03-10
Medium Priority
Last Modified: 2016-01-14
I believe I have an error in a root CA on a LAN enclave, but I'm not sure how to fix it. Or rather, I think I know how to fix it, but I'm scared.

I followed this setup (changing names) to create a Root CA and an Issuing CA: http://social.technet.microsoft.com/wiki/contents/articles/15037.ad-cs-step-by-step-guide-two-tier-pki-hierarchy-deployment.aspx

Everything seemed to go fine until I tried to set up the OCSP. As soon as I had installed the Issuing CA, I got an error in the Enterprise PKI on CA02. After some mucking about, I >believe< that the error is in this line:
"ldap://CN=Intranet Root CA,CN=AIA,CN=Public Key Services,CN=Services,..."
I >think< that ldap: requires three /// ...
My question is this: Can I revoke the certificate and reissue it from CA01, or will that cause a cascade of failures? If so, should I revoke the certificates from the client backward and re-issue them, or can I just re-issue the Root CA and install it on CA02?
Question by:dawsora
LVL 65

Expert Comment

ID: 39920284
actually the ocsp just serve one mean to check the cert revocation status, it should not be a roadblock to your client as the list of AIA or CRL service to check upon is inside that certificate - it points them to the service to do the checks...

The complication is when there is need to renew ocsp response signing certificate (if enabled such req) and at the same period, the CA cert is also to be renewed...there is need to ensure the ocsp responsesigning certificate used for validation of existing certificates must still be signed by the same (also going to be renewed) CA certificate that was used to issue the existing certificates. But this is already handled by Win2K8 CA (slight step to enable to handle this using certutil..) but not Win2K3 CA (there are means but need more steps)

But specific to troubleshooting to ascertain root cause, better to look at the error, see the link to ascertain approach for the common issues faced.

What problem are you having?
-The Online Responder service did not start
-The Online Responder's signing certificate could not be located
-An attempt to create a revocation configuration failed
-The signing certificate for the Online Responder configuration will expire soon
-The signing certificate for the revocation configuration has expired
-An Online Responder revocation configuration cannot be loaded
-The Online Responder service could not retrieve a CRL for the specified revocation configuration

To test OCSP, you cannot use a browser or IIS manager. You should validate a certificate issued with the OCSP URL in the AIA extension, and run certutil -url certfilename  This command will allow you to test download of all AIA, CDP extensions and to send a properly formatted OCSP request with the certificate's serial number included to the OCSP and validate the response.

But do note as part of testing, you can clear OCSP server cache with Online Responder MMC snap-in. Right-click on Array Configuration and select Refresh Revocation Data. To set shorter cache validity for specific revocation configuration. Select required revocation configuration, click Edit Properties, switch to Revocation Provider tab and edit cache validity. However, remember, that clients also maintains their own cache and this cache is not configurable.

For troubleshooting scenarios in which there are no event log errors or warnings and the Online Responder snap-in reports no problems, check the Online Responder service log for further diagnostic information. The service log is located at: SystemDrive\Windows\ServiceProfiles\networkservice\ocspsvc.log

There is another more specific to Error codes, see under "Troubleshooting the Online Responder" and MS suggest "resolve" approach which you can consider to minimise impact and more assure on the appropriate remediation approach

Author Comment

ID: 39924953
Thanks for all the information. I've cleared up the first part of my problem by re-issuing the Root CA. Now all my LDAP connections (AIA, CDP) are working correctly. I"m beginning to think that the problem with my http:// connections (AIA, CDP, OCSP) are related to the IIS server and not to the certificate server.

After some troubleshooting, I'm getting 403 errors, so it appears that IIS is not handling authentication properly.
LVL 65

Expert Comment

ID: 39925349
This EE will help with its detailed sharing


Went into the AIA extensions drop down and selected the http://servername/ocsp option.
Only checked "Include in the online certificate status protocol (OCSP) extention". Then okayed it. It restarts the services. After that I then revoke the  CA Excahnge certs on the CASUB server.
Then recreate a new CA excahnge cert by going to an admin command prompt and running certutil -cainfo xchg after that runs I go back into ADCS - Enterprise PKI - CAROOT - CASUB and look at the location lists. The OCSP location#1 is now reporting as OK. I verified OCSP with the options for the verify links in my resources links above and the tests work.
Microsoft Certification Exam 74-409

Veeam® is happy to provide the Microsoft community with a study guide prepared by MVP and MCT, Orin Thomas. This guide will take you through each of the exam objectives, helping you to prepare for and pass the examination.

LVL 35

Expert Comment

ID: 39927643
If you have a look into a certificate issued by your CA, you can see the revocation information in the certificate. Sure, all the information there should be valid and rechable, if you reflect to the links in there, you should be able to download the revocation file using the url. You can easily check this also by using the Enterprise-PKI snap in in a mmc.

Usually it is enough, if the first target works, the revocation list is checkted in the order, which you can see in the certificate. If the first doesn't work, the second is used, takes just more time.

If your certificates are template based, you can also cahnge the settings (i.e. via Enterprise PKI snap in and rebublish the templates with a new version and force the clients to reissue the certificates.
If the root CA certificate is wrong, you have to create a new one.
LVL 38

Expert Comment

ID: 39930034
Even if you renewed root CA certificate, your issuing CA server certificate still pointing to old root certificate and all client certificates as well pointing to old root certificate
How you renewed root certificate ?
I mean what you did with previous root certificate ? It should list in CA server properties
I hope you have not deleted \ revoked that cert

To answer your actual question:
If you revoke issuing CA certificate now, then you need to reissue issuing certificate from root CA and also you need to reenrol all client certificate as well because this will break there certificate chain
Because certificate appears to be valid only when all associated certificates in its chain are valid

I don't know what problem you had with OCSP, but if you have got wrong url of ocsp in issued certificates, then only option left is to 1st resolve ocsp problem, ensure that it is appearing correctly in new certificates and then reissue issuing CA cert and all client cert from issuing CA server

Also personally I do not recommend tired PKI unless you have tight security policies \ huge organization
In that case, I'd remove issuing CA and just use one Ad integrated enterprise CA server

LVL 65

Accepted Solution

btan earned 2000 total points
ID: 39930670
Just to share for stand-alone CAs, they do not support the version 2 or version 3 certificate template required to create an OCSP Response Signing certificate, you must manually create and submit an OCSP Response Signing certificate request. Response signing is recommended and that is the "complexity" going for any full fledged PKI. Also Microsoft OCSP client does not support the nonce extension, if you have proxy appliance that does this check on behalf, do remember to disable it on the appliance.

Event 0xC25D0010 - For configuration %1, Online Responder revocation provider failed to update the CRL Information: %2. (Error Message).
Event ID 16
Event Source OnlineResponderRevocationProvider or OCSPRevInfoProvider
Description The Online Responder service could not retrieve a CRL required for the specified revocation configuration.
Diagnostics Follow these steps to diagnose the problem:

1. Use the Online Responder snap-in to verify that the URLs configured for base and delta CRL distribution points are valid.

Open the Online Responder snap-in. In the console tree, select the revocation configuration node. In the details pane, right-click the revocation configuration specified in the event description, and then click Edit Properties. Click the Revocation Provider tab, and then click Provider.

Note the URLs configured in the Base CRL URLs and Delta CRL URLs lists. Using network tools, verify that these URLs are accessible by the computer running the Online Responder and that they contain CRL files.

2. Use the Certification Authority snap-in to verify the URLs to which the CA will publish base and delta CRLs.

Open the Certification Authority snap-in, right-click the relevant CA, and then click Properties. Click the Extensions tab, and note the URLs entered for the CRL Distribution Point (CDP) extension.

Note the URLs for which the Publish CRLs to this location or Publish Delta CRLs to this location check boxes are selected. Verify that these map to the same network locations configured as base and delta CRLs in the Online Responder snap-in.

3. On the computer to which the base CRL is published, examine the Freshest CRL extension for the base CRL. Verify that this identifies a location where the delta CRL can be found.

Republish the current CRL, if necessary, by typing the following command at a command prompt: certutil -crl

Then, verify that Online Responder service can access the CRL. From the Online Responder snap-in, right-click Array Configuration, and click Refresh Revocation Data.

4. If the error persists, enable CryptoAPI 2.0 Diagnostics for more information.

Featured Post

2017 Webroot Threat Report

MSPs: Get the facts you need to protect your clients.
The 2017 Webroot Threat Report provides a uniquely insightful global view into the analysis and discoveries made by the Webroot® Threat Intelligence Platform to provide insights on key trends and risks as seen by our users.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

The conference as a whole was very interesting, although if one has to make a choice between this one and some others, you may want to check out the others.  This conference is aimed mainly at government agencies.  So it addresses the various compli…
The well known Cerber ransomware continues to spread this summer through spear phishing email campaigns targeting enterprises. Learn how it easily bypasses traditional defenses - and what you can do to protect your data.
With Secure Portal Encryption, the recipient is sent a link to their email address directing them to the email laundry delivery page. From there, the recipient will be required to enter a user name and password to enter the page. Once the recipient …
The Email Laundry PDF encryption service allows companies to send confidential encrypted  emails to anybody. The PDF document can also contain attachments that are embedded in the encrypted PDF. The password is randomly generated by The Email Laundr…
Suggested Courses
Course of the Month16 days, 7 hours left to enroll

862 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question