Certificate Error

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

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.

This EE will help with its detailed sharing

https://www.experts-exchange.com/questions/27719920/CA-OCSP-Configuration-Install-Help.html

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.

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

Mahesh