Hello, This is a long post so I apologize for it at the onset. I have a few ADCS questions , not necessarily related to each other but I would appreciate any help in addressing them. To start with, can someone please let me know if the following is correct or not - a client machine does the following when it is presented with a certificate, say by a web server, a. A certificate chain is built up to a self signed certificate which usually is the root. In order for this, the certificates are first searched for locally and if not found the extensions specified in the AIA are used. In a situation where the root cert is present locally but the the issuing CA cert is not present or accessible using the AIA extensions in the server certificate, verification fails. b. If a chain terminates in a trusted root, the revocation for all certificates is checked. So if the chain is as follows - Root CA -> Issuing CA -> Server, the CDP extensions in the server certificate and the issuing CA certificate are used to determine their revocation status respectively. Again, if the CDPs are not accessible, the verification fails. By default root certs are not checked for revocation. The root cert also. does not have a CDP or AIA extension specified in it. Now, coming to my problem. I have a 2 tier hierarchy, A stand alone online root and a standalone online issuing CA, both server 2008 machines. Both of them have LDAP distribution points for CDP and AIA. The issuing CA, additionally has web enrollment enabled and publishes CRLs accessible over HTTP. We are introducing VPN into our environment which means that clients will not have access to the LDAP paths to check certificate status. In order to address this, what should I do? After some research, I came up with the following, a. Since the issuing CA has a CDP accessible over HTTP, opening it up for VPN client access, would help check the revocation of the leaf certificates. b. Since the root only publishes to LDAP, I guess, I would have to add a CDP to the root and give access to clients. If this was to be a HTTP path, can someone please point me to a resource on how can I go about accomplishing this. After I add the new CDP to the root CA, the old certificates would still only have the old CDP. Is there any way to remediate this issue? Also, how does adding a CDP affect new and old certificates? Just to make sure, if I do not do this, the sub CA certificates would not get verified? I was planning to renew my CAs anyways. Is clubbing the addition of the CDP and the renewal a good idea? I feel it is because if I add a CDP for the root, then renew the root and the issuing CAs and get the VPN clients to use to new root and issuing CA certificates, they would be able to check the revocation of the sub CA certificate since that would have the HTTP CDP . Any opinions? Thank you for your patience, I would appreciate any help with the above. Regards, -p

> In a situation where the root cert is present locally but the the issuing CA cert is not present or accessible using the AIA extensions in the server certificate, verification failsthis is not correct. If any intermediate CA certificate is presented (no matter how it was got) and CCE is able to build a chain using this certificate then chain is considered as valid (of course if root certificate exist in Trusted Root CAs in local machine store).> If a chain terminates in a trusted root, the revocation for all certificates is checkedactually in most cases root certificates are not checked for revocation.> Again, if the CDPs are not accessible, the verification fails.not always. For example, when you use IPsec with certificate-based authentication, by default each peer tries to check revocation status. But if CDP is not present or CRL cannot be downloaded, this step is skipped. In that case you need to manually enable strong certificate check for IPsec. Some programs don't check certificates for revocation. For example when you run signed Windows PowerShell script, PowerShell engine don't check signing certificates for revocation. When you add a certificate rule to Software Restriction Policies, it tries to check revocation status. If revocation status cannot be determined, certificate is considered as valid certificate. Therefore this depend from application. In SSL case, this statement is correct. If revocation status cannot be determined, certificate check will fail.regarding your issue. The easiest way is: remove LDAP urls from any certificate CDP/AIA extensions or place them behind HTTP urls and reissue necessary certificates. All urls in extensions are processed in the same order as specified in the certificate. Make your HTTP urls accessible from internet. This will be recomended for computer certificates (i you use L2TP/IPsec tunnel).or you are talking about user authenitcation certificates?http://www.sysadmins.lv

Thank you Vadims. I was referring to computer certificates so your suggestions are fine. I am not sure I understand your answer to the first question. If the intermediate cert is not present on the client machine and it is not accessible using the AIA extensions, how will the CCE build the chain? And if it is not able to , I guess verification would fail. Also, a few follow up questions to your suggestions, 1. Currently, my root CA only had LDAP URLs for both AIA and CDP. How can I ensure that they are placed behind the new AIA and CDP extensions in the issued certificates? Also, could you please direct me to a resource on how to add a new AIA and CDP extension. 2. I understand that if web enrollment is enabled, the default HTTP URL for a distribution point points to a virtual directory on the local machine where the CA publishes its certificates and CRLs. If I add these URLs to the AIA and CDP on my CA (because I had deleted them originally), then enable web enrollment, would it still work, i.e. would the virtual directories get mapped automatically or would I manually have to make some configuration changes? Thanks, -p

> And if it is not able to , I guess verification would failsure. Sorry, In my answer I've missed the point that CA cert is not accessible through AIA urls too. In that case chain will be broken.> Currently, my root CA only had LDAP URLs for both AIA and CDPactually this is not fatal error, because all trust clients (who trusts your root) will be able to find root certificate in local store. For example, VeriSign don't publish AIA extension in 2nd tier CA certificates, because all VeriSign root certificates are installed on all Windows systems. However it is still strongly recomended to publish AIA extensions in 2nd tier CA certificates. And CDP extension is required for all certificates except root certificate. While your external clients cannot access your AD (at least until they are logged to domain). I nyour case you should to not use any LDAP urls, but HTTP only.> How can I ensure that they are placed behind the new AIA and CDP extensions in the issued certificates? just open certsrv.msc snap-in, in CA properties locate Extensions tab. There you will see both CDP and AIA extensions for this CA. URLs in certificates will appear in the same order as shown in this tab (this don't apply to physical file publishing points).> Also, could you please direct me to a resource on how to add a new AIA and CDP extension.for Enterprise CAs it is strongly recommended to use your external web server to host these files. If your web server is accessible from internet and is domain member you can create following links:file://\\WebServerName\somepath\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crlhttp://WebServerDNSName/virtualdirectory/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crlfirst link would publish CRLs (files) to share on web server and will not publiched in issued certificates. Make sure if CA computer account has permissions in Share Permissions and NTFS permissions. Next url will be added to all issued by this CA certificates. In the same manner you can setup AIA extension.2. Web enrollment is just web enrollment and not affect to certificate revocation/validation.http://www.sysadmins.lv

Thanks! I tested the above and it seems to work. I have 2 questions though, 1. I read somewhere that if multiple URLs are present in the CDP or AIA extensions, they are checked in order. Does this means that all of them are checked? If yes, what is the purpose of putting the HTTP URL ahead of the LDAP? Is it just to ensure that the first check succeeds? Also, is there a 15 sec timeout associated with each check? 2. I observed that after adding AIA and CDP to my root, they were not visible on the Enterprise PKIView until some time. Where does this retrieve its information from and how often is it refreshed? Thanks! -p

> Does this means that all of them are checked?no. URLs are checked until certificate status is determined (revoked/unrevoked). If first URL is accessible and CRL is valid, then other URLs aren't checked. Only if CRL is not accessible or CRL is not valid, other URLs are processed.> If yes, what is the purpose of putting the HTTP URL ahead of the LDAP?because HTTP is universal protocol, can be used by various type of devices (such computers, routers, smartphones, etc) and can be accessed from enywhere. LDAP urls are not supported by some devices and aren't accessible outside of AD domain. I don't use LDAP urls nowhere (in AD domain environments too).> Also, is there a 15 sec timeout associated with each check?15 second timeaout is for first (default) URL in the list. By default for each extension overal (for all URLs) timeout is 20 seconds.> Where does this retrieve its information from and how often is it refreshed?pkiview.msc retrieve info about offline CAs just inspecting online CAs certificate extensions (for Windows Server 2008). This snap-in don't refresh anything over time automatically. It run all checks after you press Refresh button only.http://www.sysadmins.lv

Thank you once again :-) So, the only thing I need to decide is if I want to put HTTP URLs ahead of LDAP paths since, even if the LDAP check fails, the subsequent HTTP URL will get checked.

in your case HTTP should be first URL. Because remote clients initiating IPsec tunnel will always fail for LDAP urls.http://www.sysadmins.lv