Hi! I have problem configuring Online responders. In the Enterprise PKI under my issuing CA I have a "OCSP Location #1" and status says error. It points to "http://servername/ocsp" A brief description of my environment: I have 5 servers in a Hyper-V Lab, all on the same Virtual Lan and subnet. All 2008 R2 2 DCs configured as primary DNS servers. 3 ADCS servers in a 2 tier configuration. 1 server as standalone Root and 2 Enterprise subordinate CA's. Installing the Root and the subordinates and issuing working certifiactes for those went well. I also tried implementing templates for EFS encryption, and that also went well. Then came the Online responders... :) I have done this by following the numbered list instructions in Microsoft Press Self-Paces Traing kit for 70-640, Configuring Windows Server 2008 Active Directory. When that didnt work I used a similar instruction on MS technet. Here comes a brief description on what I have done: I went in under properties/security of the OCSP response Signing template and added a group (with the 2 CA's as members) and gave the group Read, Enroll and AutoEnroll permissions. I duplicated the template and chose to "Publish certificate in Active Directory". I also checked that the group mentioned above was listed in the security tab with the correct permissons. I then specified a location for the AIA (http://servername/ocsp) and checked "Include in the Online Certificate Status Protocol..." I then issued the template and restarted the CA. I then opened the Certificate snap-in for computer accounts and local computer and located the issued certificate for OCSP under peronal and choosed to Manage Private keys. I then added NETWORK SERVICE and gave it Full control. Restarted the CA. After this I have the location error under Enterprise PKI. Anyone got any ideas? Cheers /Leyan

do not put there the NETWORK SERVICE permission entry. it does not work with R2 any more. put there the account of the OCSP server directly - I mean that if you are running the OCSP on a server with name CA1, then you should set the premissions to CA1$ account and not to the Network Service. ondrej.

Hi! Thanks for you answer. I will try this when I get there. I started over from the beginneing... again. :) I think I should mention that I now see that I get the error directly after adding the url to the AIA. In other words, I get the error long before the step where before set the Network Service permissions. /Leyan

Hi again! I have now checked this and it didnt change anything unfortunately. /Leyan

I have now done it all over again and I get the same error when I add the url to the AIA under the extensions for the issuing CA. I also tried not to create an own entry but to use the default http entry and check the "Include in the online certificate...." Am I having IIS problems maybe? /Leyan

try to revoke the most recent CA Exchange certificate and re-run pkiview.msc.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com

Hi! If you only knew how many times that certificate have been revoked on my poor little CA. :) I should of course have mentioned that I have tried this (as it is one of few suggestions found if you search the internet on the subject), I'm sorry that I failed to mention that. /Leyan

ok. Export the most recent CA Exchange certificate to a file and run the following command: certutil -verify -urlfetch xchg.cer copy and paste OCSP-related information. Also make sure if OCSP configuration is correct. You may also check event logs on OCSP server. My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com

Hi! Thanks alot for the help. I have this in a isolated Lan in Hyper-V and cannot just copy paste information as the servers have no internet access, I'll fix this and post the information as soon as possible, in the meantime I could mention that I checked the event viewer again as you mentioned it. I then found this: DistributedCOM, event 10016: The application specific permissions setting do not grant Local Launch permission for the COM Server application with CLSID {D99E6E73-FC88-11D0-B498-00A0C90312F3} I seem to get this everytime I restart the ADCS service....! /Leyan

Hi again! Here is the dump., by the way I solved the DCOM issue by changing permissions in component services and that didnt change anything with my location problem: Issuer: CN=supportcenter-Issuing-CA01 DC=supportcenter DC=local Subject: CN=supportcenter-Issuing-CA01-Xchg DC=supportcenter DC=local Cert Serial Number: 610675cf00000000000f dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000) dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000) ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000) HCCE_LOCAL_MACHINE CERT_CHAIN_POLICY_BASE -------- CERT_CHAIN_CONTEXT -------- ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) ChainContext.dwRevocationFreshnessTime: 1 Days, 2 Hours, 5 Minutes, 35 Seconds SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) SimpleChain.dwRevocationFreshnessTime: 1 Days, 2 Hours, 5 Minutes, 35 Seconds CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0 Issuer: CN=supportcenter-Issuing-CA01, DC=supportcenter, DC=local NotBefore: 2011-04-08 12:58 NotAfter: 2011-04-15 13:08 Subject: CN=supportcenter-Issuing-CA01-Xchg, DC=supportcenter, DC=local Serial: 610675cf00000000000f Template: CAExchange Template: CA Exchange 30 6c 1d 11 06 25 eb e1 a7 d0 18 87 d3 7f e3 e9 fb d4 4a 67 Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2) Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) ---------------- Certificate AIA ---------------- Verified "Certificate (0)" Time: 0 [0.0] ldap:///CN=supportcenter-Issuing-CA01,CN=AIA,CN=Public%20Key%20Service s,CN=Services,CN=Configuration,DC=supportcenter,DC=local?cACertificate?base?obje ctClass=certificationAuthority ---------------- Certificate CDP ---------------- Verified "Base CRL (03)" Time: 0 [0.0] ldap:///CN=supportcenter-Issuing-CA01,CN=SCECA01,CN=CDP,CN=Public%20Ke y%20Services,CN=Services,CN=Configuration,DC=supportcenter,DC=local?certificateR evocationList?base?objectClass=cRLDistributionPoint Verified "Delta CRL (03)" Time: 0 [0.0.0] ldap:///CN=supportcenter-Issuing-CA01,CN=SCECA01,CN=CDP,CN=Public%20 Key%20Services,CN=Services,CN=Configuration,DC=supportcenter,DC=local?deltaRevoc ationList?base?objectClass=cRLDistributionPoint ---------------- Base CRL CDP ---------------- OK "Delta CRL (03)" Time: 0 [0.0] ldap:///CN=supportcenter-Issuing-CA01,CN=SCECA01,CN=CDP,CN=Public%20Ke y%20Services,CN=Services,CN=Configuration,DC=supportcenter,DC=local?deltaRevocat ionList?base?objectClass=cRLDistributionPoint ---------------- Certificate OCSP ---------------- Unsuccessful "OCSP" Time: 0 [0.0] http://sceca01.supportcenter.local/ocsp -------------------------------- CRL 03: Issuer: CN=supportcenter-Issuing-CA01, DC=supportcenter, DC=local c1 19 cb c6 fd 04 61 bb ae 6d c4 18 51 0f 68 c6 c2 a9 b5 6e Delta CRL 02: Issuer: CN=supportcenter-Issuing-CA01, DC=supportcenter, DC=local b9 20 ea 8a ee d9 b7 b0 9c ab df 6e f3 1e 30 03 14 34 e0 37 Application[0] = 1.3.6.1.4.1.311.21.5 Private Key Archival CertContext[0][1]: dwInfoStatus=102 dwErrorStatus=0 Issuer: CN=supportcenter-Root-CA, DC=supportcenter, DC=local NotBefore: 2011-04-07 11:15 NotAfter: 2012-04-07 11:25 Subject: CN=supportcenter-Issuing-CA01, DC=supportcenter, DC=local Serial: 614ffcbe000000000002 Template: SubCA 2f 42 c2 37 2b 88 6a 1b bc fb 0e 2f 30 29 91 ce 1f de 35 d9 Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2) Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) ---------------- Certificate AIA ---------------- Verified "Certificate (0)" Time: 0 [0.0] ldap:///CN=supportcenter-Root-CA,CN=AIA,CN=Public%20Key%20Services,CN= Services,CN=Configuration,DC=supportcenter,DC=local?cACertificate?base?objectCla ss=certificationAuthority ---------------- Certificate CDP ---------------- Verified "Base CRL (01)" Time: 0 [0.0] ldap:///CN=supportcenter-Root-CA,CN=SCRCA,CN=CDP,CN=Public%20Key%20Ser vices,CN=Services,CN=Configuration,DC=supportcenter,DC=local?certificateRevocati onList?base?objectClass=cRLDistributionPoint ---------------- Base CRL CDP ---------------- No URLs "None" Time: 0 ---------------- Certificate OCSP ---------------- No URLs "None" Time: 0 -------------------------------- CRL 01: Issuer: CN=supportcenter-Root-CA, DC=supportcenter, DC=local b3 dd a5 7d fe 1a 7c f9 11 f8 95 c8 cc 99 48 84 c5 b6 b8 1f CertContext[0][2]: dwInfoStatus=10c dwErrorStatus=0 Issuer: CN=supportcenter-Root-CA, DC=supportcenter, DC=local NotBefore: 2011-04-07 11:06 NotAfter: 2031-04-07 11:16 Subject: CN=supportcenter-Root-CA, DC=supportcenter, DC=local Serial: 2e46fb6522bc4bad496f12d11f3430fa 8d 73 54 1f 21 3f 20 5e 0d a0 af e1 24 8e 42 b3 d7 8a af ae Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4) Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8) Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) ---------------- Certificate AIA ---------------- No URLs "None" Time: 0 ---------------- Certificate CDP ---------------- No URLs "None" Time: 0 ---------------- Certificate OCSP ---------------- No URLs "None" Time: 0 -------------------------------- Exclude leaf cert: ae 84 96 ed 7e d9 1b ac 0b c7 d9 e4 cd ed 8b 66 27 5a 3a 0c Full chain: 60 ea 7c 77 06 a3 07 5f eb d2 c1 83 5e 50 45 29 ea 73 b0 54 ------------------------------------ Verified Issuance Policies: None Verified Application Policies: 1.3.6.1.4.1.311.21.5 Private Key Archival Leaf certificate revocation check passed CertUtil: -verify command completed successfully. /Leyan

even if they are not connected to internet you can copy/paste console trace (produced by certutil).My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com

yes, but I cannot post it here. ;) I had to transfer the text to a machine connected to the internet to be able to post here, wich I did a few minutes ago.

what about Online Responder configurations? Are they correct? Is sceca01.supportcenter.local a host with installed OCSP role?My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com

From my initial post: I went in under properties/security of the OCSP response Signing template and added a group (with the 2 CA's as members) and gave the group Read, Enroll and AutoEnroll permissions. I duplicated the template and chose to "Publish certificate in Active Directory". I also checked that the group mentioned above was listed in the security tab with the correct permissons. I then specified a location for the AIA (http://servername/ocsp) and checked "Include in the Online Certificate Status Protocol..." I then issued the template and restarted the CA. I then opened the Certificate snap-in for computer accounts and local computer and located the issued certificate for OCSP under peronal and choosed to Manage Private keys. I then added NETWORK SERVICE and gave it Full control. Restarted the CA. Prior to this I of course added the OR role

can you open this URL in a web browser? You should receive HTTP 500 error (this is normal behavior)/My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com

From my initial post: I went in under properties/security of the OCSP response Signing template and added a group (with the 2 CA's as members) and gave the group Read, Enroll and AutoEnroll permissions. I duplicated the template and chose to "Publish certificate in Active Directory". I also checked that the group mentioned above was listed in the security tab with the correct permissons. I then specified a location for the AIA (http://servername/ocsp) and checked "Include in the Online Certificate Status Protocol..." I then issued the template and restarted the CA. I then opened the Certificate snap-in for computer accounts and local computer and located the issued certificate for OCSP under peronal and choosed to Manage Private keys. I then added NETWORK SERVICE and gave it Full control. Restarted the CA. Prior to this I of course added the OR role mm..just to be clear: have you configured OCSP responder revocation configurations and providers? My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex

Hi! Yes, If I browse the site I get error 500. And yes I have configured revocation and providers, by selecting the default values and setting a provider URL as http://localhost/ca.rl /Leyan

Hi! I now have done it all over again and will take you through every step to be sure. So I made a clean start with new servers and a new AD and everything. I will try to leave nothing out. I installed 3 virtual machines on my Hyper-V host, wich has one NIC connected to an isolated LAN, wich has a Virtual LAN created to wich I added all 3 machines. So here are these 3 machines: CPCD: Microsoft Server 2008 R2 (Standard, Full), IP 10.14.1.2 CPRCA: Microsoft Server 2008 R2 (Standard, Full), IP 10.14.1.3 CPECA: Microsoft Server 2008 R2 (Enterprise, Full), IP 10.14.1.4 Ok, so lets take you through the first steps of the server configurations: I installed AD DS on CPDC and promoted it creating a new domain and forest cp.nu, everything as default. I added CPRCA to the domain. I installed AD CS on CPRCA with the role serice Certification Authority. I configured CPRCA as a Stand Alone Root CA with all defaults. I added CPECA to the domain I installed AD CS on CPECA with the role services Certification Authority and Online Responder. I configured CPECA as an Enterprise Subordinate CA with all the defaults and saved a certificate request to a file at the end of the wizard (Root.req). I transfered the Root.req file to CPRCA and choose to submit new request and pointed to the file. I went in under pending request and issued it. I then from Issued Certificates opened the certificate and exported it to a file root.p7b with the option to Include all the certificates in the certificate path if possible. I then imported that certificate on CPECA. I created a GPO on CPDC and linked it to the domain and went in under Public Key Public Key Policies and enabled Certificate Services Client Auto-Enrollment. I ran gpupdate /force on CPDC, CPRCA and CPECA. Ok, thats that. Let's move on to the OCSP and OR configuaration: I duplicated the OCSP Respons Signing template as 2008 Enterprise and choose to Publish Certificate to Active Directory. I also added the CPECA machine account on the security tab and gave it Read, Enroll and Auto-Enroll permissions. I now choose properties for the CPECA node and went to the extensions tab and added an URL of http://cpeca.cp.nu/ocsp to the Authority Information Access and choose to Include in the online certificate status protocol (OCSP) extension. Allready here if I open the pkiview.msc I get the error. I have 5 entries under the last node: CA Certificate, OK AIA Location #1, OK CDP Location #1, OK DeltaCRL Location #1, OK OCSP Location #1, Error. But doing the finishing touches changes nothing, I'll still go through them: I go to the CPECA node an rightclick Certificate Templates and issue the duplicated OCSP template I created before. I restart CPECA. I went to Revocation Configuration node and created a revocation configuration with all the defaults, choosing the root CA on Choose a CA certificate tab and choose the Enterprise CA with Auto-Enroll for an OCSP signing certificate on the Select Signing Certificate tab. For providers I added an URL of http://localhost/ca.rl This Online responder configuration immidiatly went green and working. I opened mmc and added the Certificate snap-in and created it for Computer Account and Local Computer. I went in under Personal/Certificates and my OCSP Signing certificate and Managed Private Keys, adding the CPECA machine account with Full Control (this due to what is mentioned above in this thread, the first time I choose Network Service). I now restarted the CA. Still the same error..... so I did a last thing to really make sure and to comply with the proposed things in this thread. So I revoked the CA Exchange certificate and restarted the AD CS service. I now started pkiview.msc and a new CA Exchange certificate was issued Problem still remains though... :( /Leyan

Try to add Delta CRL location to revocation provider (in OCSP configuration). BTW, > I duplicated the OCSP Respons Signing template as 2008 Enterprise and choose to Publish Certificate to Active Directory this is not necessary. You should use default OCSP Signing template for Windows Server 2008 (ang higher) CAs. > I also added the CPECA machine account on the security tab and gave it Read, Enroll and Auto-Enroll permissions. Since autoenrollment is not used by OCSP responders Autoenroll is not necessary. Read and Enroll is enough.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com

> Try to add Delta CRL location to revocation provider (in OCSP configuration). What can I set it to? No matter what address I choose I seem to get an error on the provider. "The object identifier does not represent a valid obejct. 0x800710d8" /Leyan

typically the same as BaseCRL with '+' sign at the end of file name.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com

Still "The object identifier does not represent a valid obejct. 0x800710d8".... :(

you must specify valid URL. As a Base CRL specify ldap:///CN=supportcenter-Issuing-CA01,CN=SCECA01,CN=CDP,CN=Public%20Ke y%20Services,CN=Services,CN=Configuration,DC=supportcenter,DC=local?certificateR evocationList?base?objectClass=cRLDistributionPoint and as a Delta CRL specify ldap:///CN=supportcenter-Issuing-CA01,CN=SCECA01,CN=CDP,CN=Public%20 Key%20Services,CN=Services,CN=Configuration,DC=supportcenter,DC=local?deltaRevoc ationList?base?objectClass=cRLDistributionPoint My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com

Didnt work, unfortunately.

Did you get this solved? I've been following your post and am having the same problem. Went through everything you've done, at least three times, still to no avail. It seems to me to be an IIS issue, but I'm fairly new to this. I also followed instructions from here: http://technet.microsoft.com/en-us/library/cc772393(WS.10).aspx and still have the same problem. Later on in this article it says to remove the CRL extensions from the CDP side, now I have a second AIA location that says: Unable to download. In my case I am trying to do it all on one server, AD DS, AD CS, DNS, DHCP. Dont have the budget to go bigger at this time. Could this be causing my issue? I have follwed your steps exactly and followed instructions from the before mentioned article(not that they are much different), both with the same result. Any further insight would be greatly appreciated. Edit: I know someone mentioned it earlier but I revoked the CA Exchange certificate and restarted and now the OCSP shows as OK. I've tried a ton of other stuff so cant say for sure thats what did it but its working now. I still have the other issue. Leyan maybe give it a try and see if it helps. (I guess maybe you already did, but I was having the same issue as you and this helped me.) Edit 2: I recreated the issue and revoking/renewing the CA Exchange certificate fixed the issue for me, Also I rebuilt the AIA extension which resolved my other issue as well. horray, finally in buisness. I am curious whether this fixes it for you Leyan, you should post back and let us know. I know you prolly tried it, but try it again, maybe there were a few steps we both did out of order or something, but I can confirm that it worked for me.

Thank you. I will give it another try in a couple of days. I had to shelve OR's for the time being to get going with other stuff. /Leyan

Dont bother, my errors are back, anyone have a real solution to this problem, seems to be an ongoing issue. Hello microsoft, are you listening?

I was just going to pipe-up and say I have this same issue. http://caserver/ocsp gives a 500 error. OCSP Location #1, Error. Have all of the roles on the same server (CDP ,AIA, OSCP). Nothing in the dir of IIS – OCSP virtual directory other than a web.config file I’d just like to know of a what the PKIView is trying to check?Weeeee messaging

Hey Leyan you still having issues with this? I have totally solved it. If you still need the info let me know and I will write it, but its alot of stuff so I dont want to unless you still need it. Well I guess others are having this problem so I will write it out, but not right now. I will try to get to it tommorrow. And hey jbrown a 500 error is normal behavior if you are trying to navigate to OCSP in IE or browser.

Well here goes nothing: I have a two tier setup. One Enterprise root CA ( I know, not best practice but it is easier to assign permissions to share etc this way.) and one Enterprise issuing CA. I also decided to offload my Web enrollment and online responder to my web server in order to eventually enable certificates on the internet for customers etc... I found my problem to be that some of my certs issued by both CA's contained AIA and CDP refrences to locations that were not setup correctly. When you setup an HTTP location your certs and CRL are NOT posted there unless you set another file location to drop the CRL's in there. The AIA locations will never drop certs there, you have to manually move them there, or script this action. Once i figured this out things started looking up. Get your locations setup like so: I left the default C:\ location on both CA's and both the CDP and AIA sides. (This is were you will copy your Certs from in later steps.) I Left the default LDAP locations but set them to only drop CRL's and certs in there. This means only check "post CRLs and DeltaCRL's to this location", and dont check anything on the AIA side. Next I setup the HTTP locations to be on my Web servers "CertEnroll" folder, when you setup the web server for Web enrollment and Online responer you will get this folder setup and shared automagicly. Also you do not have to install Certification authority in this case, just web enrollment and OCSP. This will not allow the certs and CRL's to be dropped in there, in order to do that you need to preform the next step. I set this one to be shown in certificates (Include in CRL's and include in CDP extension), and to post this AIA location in certificates. This is what you want to point your clients to. But dont check Include in OCSP on the AIA side. Next setup file locations (file:\\Server\CertEnroll) on both sides. (Actually now that I think about it you probably dont need the file location on the AIA side since you have to manually move the certs there anyway, but you do want the HTTP location on the AIA side because you want it to be shown in the certs to point your clients there.) With the file location set the CRL's WILL be posted there, this must match your HTTP location. On this one you just want to check "Post CRLs and Delta to this location". You dont want clients seeing this location either so dont show it in Certs. And dont check anything on the AIA side. Finally I set the OCSP location to http://Server/OCSP and check it to be included in ocsp but not to be included in certs. Your clients will knwo this location so no need to check the include in AIA extensions. This location will be shown in certs because of the OCSP box being checked. Now here is were the actual problem comes in, once you have all these setup correctly you need to make sure that NO certs are pointing to wrong locations, I solved this by Revoking every certificate On both CA's Except the Root CA's Certificate. Next you want to post CRLs from both CA's and verify that they were posted to your File/http location (This is the trick I found, the http location and the file location are really two entries to make the one location actually work.) If they are posted there correctly then copy your Root CA's certificate to this location as well. Next issue a new Cert to your Issuig CA. Copy this to your http/file location. Enable your Issuing CA to autoenroll OCSP Certs, and make sure your online responder machine has permission to autoenroll for the cert. Next you want to setup your online responders on the Web server (in my case but werever your online responder is.) When you do this setup one for the root CA and one for the Issuing CA and point them to there respective CA. Next Auto enroll for new OCSP certs. Also when you get to the last page of this setup click the providers button and make sure there are entries for both the CRL and the delta CRL. The delta will be the same except with a plus on the end. On your Issuing CA you should have more then one cert and therefore one will have a (2) at the end, the one with the highest number will be your newest cert. Make sure you put the + at the end of this for your delta crl (ca1_domain1(2)+.crl). Also make sure these are pointing to your HTTP location, this is were all your clients and your online responder will look when they are checking certs and crl's. Once there are two CA certs and four CRL's in this location you should be able to refresh your top Enterprise PKI view and everything shold be fine. If not then check to see if any certs were issued by either CA other then the one SubCA cert. if they were then revoke them and try again. Once all certs and all locations are correct you should show OK's all the way down the board. I dont know if this is the best way to do this but it is working totally correctly, and the only thing shown in Certs is http locations. The key here is that PKIView looks at all issued certs and verifies those locations. It doesn't look at your actual setup, so you have to make sure your setup is totally right, and your CRLs and CA certs are in the locations those certs say they should be, before you ever issue any certs. For me it took a couple of trys of revoking and issuing certs to get everything totally functional. Just make sure you really think through your extensions setup and were you want the certs to point clients to. For me this was were the light bulb apeared over my head, and it finally all made sense. Any questions let me know, i would be glad to help out.

Thanks Medik, not sure why none of the MS support guys don't understand or answer these questions correctly! I guess they were never trained! Anyone who has worked any of the exercises in the MS Press books would be familiar with these issues! I will try your instructions to see if I get the same results.