Hi, I am setting up a 3 tier PKI, with offline standalone root, offline subordinate policy, and enterprise issuing CA's. (2008R2) It was going well with the root, and offline sub, until I noticed that the CDP and AIA locations in the offline sub certificate are incorrect. It seems that the variable names that I inserted in the MMC gui did not get inserted into the certificate correctly. Maybe this is because I used the CA (common) name which has spaces in? I am probably going to blow it all away and start again rather than reissue and reconfigure the sub CA. I just need to fully understand the requirements for CDP and AIA locations if you can help at all? I want to now specifiy these explicitly rather than rely on variables. I want to just use http locations (as well as local file), of the format http://cert.contoso.com/data My questions are: Do I specify just a path, and clients will check for all CRL / crt files in that path, or do I have to explicitly specify file names as in http://cert.contoso.com/data/rootcrl.crl and http://cert.contoso.com/data/rootcert.crt I am planning on setting these http locations to be the same in the GUI on root, intermediate, and enterprise CA's. So, do I need different file or path names for each? I need to understand what the client is checking for - but can't seem to find the documentation on this. Every resource I find just seems to use variables! Any help greatly appreciated! Fred

Hi, The certificate validation process looks like: CryptoAPI determines whether the certificate is included in the Untrusted certificate store. All certificates in the Untrusted certificate store are explicitly designated as disallowed certificates. If the certificate included a stapled OCSP response and the stapled response is time valid, use the stapled OCSP response to valid the revocation status of the certificate. If a CRL with the matching issuer name and optionally the same IDP is already in the CA store, use that version of the CRL. If a stapled response or previously downloaded CRL is not available, then CryptoAPI must attempt URL retrieval to determine the revocation status of the certificate. The URLs for OCSP and CDP are built in the following order: OCSP URLs from Group Policy OCSP URLs from the authority information access extension CRL URLs from the CDP extension I think you may need to explicitly specify file names for CRL file and root certificate file. Validating the Certificate Chain http://msdn.microsoft.com/en-us/library/dd407310(VS.85).aspx How Certificate Revocation Works http://technet.microsoft.com/en-us/library/ee619754(WS.10).aspx#BKMK_BC

Hi Miles, Many thanks for your excellent response - that's exactly what I was looking for! I have hardcoded the names, and all seems to be better. I do have one other query related to this that you may be able to help with...? Running certutil -crl on my offline policy ca, generates the crl, but also appears to generate a delta crl file (+.crl). Now, I have disabled delta CRL's for this server, so am a little confused as to why this is being generated. The +crl indicates that the next update is due tomorrow. As I only very rarely plan to bring this CA online, I don't want delta CRL's! Can I simply ignore this, and just publish the normal CRL periodically, or do I need to find out why I appear to be generating deltas? When I ran the certutil -crl on my offline root, I only got the crl file with no delta - so I really don't know what is going on here! Hope this makes sense, Many thanks. Fered

Hi, Have you disabled publishing delta CRLs by deselect Publish Delta CRLs option in the CRL publishing parameters on the CA?

I had, but it did not "take" for some reason. Possible I hadn't restarted ADCS. I disabled using certutil -setreg, and restarted and it was all OK. Thanks for your help. Fred