Hi all. ok firstly went through 2 links as it seemed terribly similar, but no didnt work for me: http://social.technet.microsoft.com/Forums/en-US/winserversecurity/thread/0c8649eb-eda9-4cf5-942a-ff6308dd9ce2/ http://social.technet.microsoft.com/Forums/en-US/winserversecurity/thread/014338d4-5a1b-4432-8fee-5261f563cf3b/ Root CA AIA Points: http://pki.ca.local/pki/RootCA.crt CDP Points: http://pki.ca.local/pki/RootCA.crl IssuingCA AIA Points: http://pki.ca.local/pki/IssuingCA.crt CDP Points: http://pki.ca.local/pki/IssuingCA.crl The one that cannot verify / unable to download is for the IssuingCA.crl - everything else goes green and is no problem Only have the C:\ & http points specified following a note Brian K put up in an earlier post to follow the Microsoft best practice link The IIS server is set to anonymous access + you can already validate the other three items ok and the Issuing CRL is in the same directory as the other three object that pass with flying colours. Did a certutil -verify urlfetch IssuingCA.crt Root cert Base CRL displayed the root CRL - but interestingly (and not sure its relivent) didn't show any URL for the issuing Authority. Changed the HTTP point to go to a vanilla web server with no access controls to try to rule out IIS issues, and the Issuing CA is still unable to download when shown in PKI View. on other computers you can go the the http manually via ie and it pops up both the CRT & CRL files as you would expect. Even though the PKI view is showing the error is this actually a problem as via a browser you can download the crl?? Save me Obi-Wan... you're my only hope - also cannot rebuild the issuing CA to be resigned from the root as this would be a major problem

Hi, Update to this... Blew away the CDP points Old Point: C:\Windows\System32\CertSrv\CertEnroll\IssuingCA.CRL Http://pki.ca.local/pki/issuingCA.CRL Errors New Points C:\Windows\System32\CertSrv\CertEnroll\<CaName><CRLNameSuffix> <DeltaCRLAllowed>.crl Http://pki.ca.local/pki/<CaName><CRLNameSuffix> <DeltaCRLAllowed>.crl Sucsess The only issue left - is Now when it publishes CRLs it Publishes them twice aka: CAName.CRL & CAName(1).crl ... CAName+.CRL CAName(1)+.crl Clearly the bug was down to name issues, but why is it now publishing the CRL twice??? I dont want to fiddle too much without some brain telling me the reason as I dont want to make things worse :) Anything I can check ???

It is doing everything correctly. You have renewed your CA certificate with a new key pair at some point, so CAName.crl is for the first instance and CAName(1).crl is the second instance. You have just recovered from one of the biggest common mistakes in PKI configuration, using static names, rather than the variables. You are now using %3%8%9.crl which allows for: %3 = <CAName> = Logical name of CA %8 = <CRLNameSuffix> = Version number of the CRL. Matches the CA version of the CA certificate that uses the same private key. %9 = <DeltaCRLAllowed> = delta CRL indicator Your previous configuration only had issuingCA.crl, so there was no version information, and no delta CRLs being published HTH, Brian