We have an issuing CA with the following CDPs: #1 LDAP of the issuing CA, #2 alias to internall HTTP location, #3 alias to external HTTP location. As well as the following DeltaCRLs: #1 LDAP of the issuing CA, #2 alias to internall HTTP location, #3 alias to external HTTP location. So the CDP and CRL locations are the same and in the same order. Bot the internal and external aliases currently point to the same locationm, which is our CRL server. We have edge networks that use RODCs and we want to put a new issuing CA into these sites. (I had a similar question on this, shown here: http://social.technet.microsoft.com/Forums/en-US/winserversecurity/thread/42578b2f-3fc4-4370-a893-4a579833fc0c but this question is more specific, so I started a new thread) This edge network does not have access into the internal corporate network, unless we open firewall ports. Basically, I'm trying to determine if we need an additional CRL in each of the edge network sites, or if we can get away without using one. If we only put the issuing CA out in the edge networks, the CDP/CRL locations would still be #1 LDAP of issuing CA in the edge network, #2 alias to internal HTTP CRL location, #3 alias to internal HTTP CRL location. This would still work correct? But just wouldn't have any CRL redundancy, as it would completely depend upon the LDAP CDP/CRL. Additionally, this reliance upon LDAP would mean that non-domain joined systems (and non-windows systems) would not be able to use it? Is that all correct? Assuming the above is correct. Could we then open up port 443 from the edge networks to the internal CRL location (CRL #2 and #3) to create this redundancy once more, and allow non-domani/windows systems to check the CDP/CRL?

You have too many URLs to start with. The best practice is to use a single HTTP URL that points to a highly available Web cluster that is both internally and externally accessible using the same DNS name. What you have set up will result in long wait times for anyone who is not connected locally to the corporate network (with access to AD). The computer will have to time out on the LDAP URL before it moves to the next URL. If they are external to the internal network (say a *nix or non-domain joined Windows machine), they will again time out since you have the alias to an internal HTTP location next. They will finally get the CRL or CA certificate when they access the externally accessible URL. If you have a delta CRL, they then repeat the process! Another point, you never use SSL to protect CRL locations. This has not been supported since 2003 days. You have to open up Port TCP 80 (HTTP) to access the CRLs and CA certificates published on Web servers. See http://www.microsoft.com/en-us/download/details.aspx?id=5493 for details on revocation checking best practices. Brian

You have too many URLs to start with. The best practice is to use a single HTTP URL that points to a highly available Web cluster that is both internally and externally accessible using the same DNS name. What you have set up will result in long wait times for anyone who is not connected locally to the corporate network (with access to AD). The computer will have to time out on the LDAP URL before it moves to the next URL. If they are external to the internal network (say a *nix or non-domain joined Windows machine), they will again time out since you have the alias to an internal HTTP location next. They will finally get the CRL or CA certificate when they access the externally accessible URL. If you have a delta CRL, they then repeat the process! Another point, you never use SSL to protect CRL locations. This has not been supported since 2003 days. You have to open up Port TCP 80 (HTTP) to access the CRLs and CA certificates published on Web servers. See http://www.microsoft.com/en-us/download/details.aspx?id=5493 for details on revocation checking best practices. Brian Okay, so they time out and then try the next one. Thanks for the information. It sounds like we could make our solution a lot better by putting the CRL (HTTP location) in one of our edge networks. However, if we keep the CRL internal (and there are a couple reasons we might do that, which I won't get into on here), we would only open port 80 back in, and not port 443? I said 443 because the following website indicates that you need 443 open to the CRL: http://blogs.technet.com/b/pki/archive/2010/06/25/firewall-roles-for-active-directory-certificate-services.aspx

Yes, you would only require port 80. The page you are refering too references port 443 for the certificate web enrollment page, this is not the CRL distribution point. You can use SSL for the web enrollment page, so the information there is accurate. Armand"The beginning of knowledge is the discovery of something we do not understand."