• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 398
  • Last Modified:

Certificate Error

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?
1 Solution
btanExec ConsultantCommented:
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
dawsoraAuthor Commented:
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.
btanExec ConsultantCommented:
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.
Cloud Class® Course: CompTIA Healthcare IT Tech

This course will help prep you to earn the CompTIA Healthcare IT Technician certification showing that you have the knowledge and skills needed to succeed in installing, managing, and troubleshooting IT systems in medical and clinical settings.

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.
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

btanExec ConsultantCommented:
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.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Microsoft Azure 2017

Azure has a changed a lot since it was originally introduce by adding new services and features. Do you know everything you need to about Azure? This course will teach you about the Azure App Service, monitoring and application insights, DevOps, and Team Services.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now