Untrusted Certificate Error
Hello, I am facing a weird problem and would be thankful for any help. I have a 2 tier PKI with a standalone root and an issuing CA. I have installed a web server cert for IIS6 and one for IIS7 using the issuing CA. The problem that I am facing is if I add the root the trusted list on my computer, the IIS6 website gives me a warning while the IIS7 one does not. If I add the issuing CA to my trusted list then both the sites work. Not sure why is this happening. Shouldn't I just need to trust the root in order for my browser to recognize the certificate as being trusted? Thanks, -p
September 16th, 2009 9:40pm
Hi,No, in order for a Client Machine to Trust the Certificate (The one which is on the Website) it should trustall the CA's in the Hierarchy, till the top. If you go to the 'Certification Path' TAB on the Certificate then you will see the Cert Chain including all the Authorities. Client needs to Trust all of them.This is because of the Revocation Function running in the background which checks - CertName - If it's matching to what you have entered in the IECRL List - Revocation ListAIA Path - Authority Information Access i.e. validity of the ParentEKU - Enhanced Key UsageIn order to fix this issue, all you need to do is open the Certificate of the Issuing CA and Export it in .p7b extension. This will Export all the Certificates till the top. You will get the Option in the Export Cert Wizard where you will have to select the Option 'Include all Certificates in the Certification Path if possible'. Put this Exported Certificate in the Trusted Store of the Clients and they will automatically start Trusting all the CA's in the Hirarchy. If it's in the Domain, you can push the Cert to Clients through Group Policy.Hope the information helps. Revert back if you have any queries.Thanks.
September 17th, 2009 4:43am
Hi,No, in order for a Client Machine to Trust the Certificate (The one which is on the Website) it should trustall the CA's in the Hierarchy, till the top. If you go to the 'Certification Path' TAB on the Certificate then you will see the Cert Chain including all the Authorities. Client needs to Trust all of them....Put this Exported Certificate in the Trusted Store of the Clients and they will automatically start Trusting all the CA's in the Hirarchy. If it's in the Domain, you can push the Cert to Clients through Group Policy. Unfortunately, this response is incorrect. Only root CAs should be added to the trusted root store of the computer, not intermediate CAs as proposed in this answer.I would check on the IIS6 system "why" the certificate is being reported as untrusted. First of all, go to the client where the problem is occuring (not really sure from your response).Then run certutil -verify -urlfetch IIS6.cer The output should show you what is happening.I suspect that you need to use a proxy server or the root Ca certificate install was not performed correctlyHTHBrian
September 17th, 2009 4:59am
Hi,Does that also holds true in case of 3-Tier Architecture where we have a Root CA -- > Subordinate CA --> Issuing CA ?In this case also putting only the Root Cert (Root CA)in the Trusted Store of the Client Computer will work ? Wouldn't it give problems as the Client Computer does not Trusts the Subordinate CA automatically ? Because what i believe is that Revocation Function will check the existence of all the CA's till the root.Just trying to clarify :)Thanks.
September 17th, 2009 5:18am
look, only the Root CA must be trusted by placingitscertificate in the Trusted Root CAs. The sub-CAs' certificates must only be available at the time client is trying to validate the chain.this means, that the sub-CAs' certificates must be either locally installad into Intermediate CAs store, or their certificates must be accessible online throught paths found in the LEAF and their own AIA extenstions (if present).you can also check the paths access by usingCERTUTIL -URL web-server-cert.cerondrej.
September 17th, 2009 6:55am
Hi,Ahh, that makes sense to me. I checked itat my end and it seems to be working just fine.I even checkedthe 'Trusted Store' on my Desktop Machine after visiting a Banking Website whichhas the Certificate from Entrust Authorities (4 Levels) andionly see the 'Entrust Root Cert' and not the SubCA Certs which makes sense.Thanks again for this information Ondrej and Brian.I apologize for the inconvenience caused, ishould have cross checked before posting. Neverthless, will take care in future.Thanks :)
September 17th, 2009 7:23am
No problem, Sloth <G>Brian
September 17th, 2009 11:44am
Thanks a lot for your help! Based on the info above I think I might have an idea as to what is happening but I still cannot explain the difference between IIS6 and IIS7. I would appreciate further advice on this. The websites that I was trying to access are in a different domain from my client machine. As a result my client system cannot verify the AIA and the CDP for these certificates because it does not have access the active directory for the second domain. I verified this using the certutil -verify -urlfetch command as suggested by Brian. As expected all the checks failed. Based on what Ondrej suggested, becuase I do not have the intermediate certs installed on my system and the certs are not accessible online, I am getting the browser warning. Is that correct? I also tried the same on a system on the same domain as the websites and the checks were successful. I was able to access both websites with only the root certificate installed without a problem. Now the strange part, even though the certutil -verify -urlfetch for the IIS7 website fails, I still don't get a certificate error! Any ideas as to why is this happening? What can I possible do to fix the different domain issue? Unfortunately, we have SSL enabled the web access for certificate services so the http:// links for AIA and CDP do not work. Adding an update: I set up a new sub CA with web enrollment without forcing SSL. On the same domain as the CA, the AIA and the CRL get verified using the certutil -url command but on the different domain it fails. The LDAP failing makes sense but not sure why are the URL extensions not getting verified....
September 17th, 2009 3:20pm
You need to fix your PKI. You have a very basic configuration issue1) All URLs in the AIA and CDP extensions must be available for anonymous download2) Do not use SSL to protect any of the URLs3) If you need to access between forests, then you need to use HTTP or an LDAP directory that allows anonymous access and can be resolved from the other forestFix these, and you fix your problemsDon't, and you will see more and more problems as you deploy other cert-based applicationsBrian
September 17th, 2009 8:43pm
Thanks. By "anonymous download", do you mean that the web enrollment sites need to have anonymous access enabled? I will try to get rid of the SSL issue.
September 17th, 2009 9:33pm
Yes. There must be no presentation of credentials when you down load a CRL or CA certificateAnd yes, there must be no SSL protection of the site or virtual directoryBrian
September 18th, 2009 2:50am
Thanks! I have made some progress with this. I made sure that anonymous access was enabled and I disabled SSL for the AIA and CDP extensions. I used the certutil -url command to check the accessibility from the second domain and the results are a little confusing. The CRL's work as expected (the LDAP URL fails but the HTTP url gets verified) but with the AIA there is a problem. The LDAP fails as expected but I get a status of 'Revocation Check Failed' for the HTTP path too. I tried to access the HTTP path directly using a browser (from the same machine where the revocation check is failing) and I was able to download the certificate. Any ideas as to why is the revocation check failing in this case? On the same domain as the web servers, both CDP and AIA get verified without a problem. I also had another unrelated question - what is IE's default certificate store? Is it the 'Local Computer' store or the 'Current User' store? Thanks!
September 18th, 2009 4:13pm
I also had another unrelated question - what is IE's default certificate store? Is it the 'Local Computer' store or the 'Current User' store? Internet Explorer doesn't store certificates. Depending on the user who logs into the computer IE will display their Certificate Store. So if the localsystem account were to use IE for some reason it would be the Local Computer's store. But if your user account accesses it, it would display your store.
October 20th, 2009 12:23am