[Today's post is provided by Carol Bailey ]
By default, an issuing enterprise CA publishes its certificate revocation list (CRL) to locations within the forest. When you are using Internet-based client management with Configuration Manager, there are scenarios where you might need to publish the CRL on a separate server, outside the forest. These scenarios include the following:
In these Internet scenarios, it makes sense to publish a CRL that can be accessed over HTTP with an Internet FQDN. If you already have a Web server in the DMZ that is configured for HTTP, it makes an ideal candidate because you just need to add an additional virtual directory - there's no need to add a host entry into your public DNS, or install and harden a new server to run IIS. However, think twice about using a server running Internet-based site system roles because (with the exception of the fallback status point), these use HTTPS to help secure the server from unauthenticated access. Certificate revocation lists cannot be accessed over HTTPS so to add HTTP access to one of your Internet-based site system servers would greatly increase the risk of an attacker connecting to this server.
Disclaimer: The procedures in this blog post are external to Configuration Manager, so you will not find this information in the Configuration Manager product documentation. However, we realize that PKI is often new to Configuration Manager admins, and aim to share our knowledge and experience to help you be more successful with the product. We would also like to pay tribute to the help and information provided by Amer Kamal and Mark Cooper, senior Premier Field Engineers who have designed and implemented CDPs for our customers.
CRLs (base and deltas) are published to CRL distribution points (CDPs). So in our scenarios, the separate Web server in the DMZ will become a new CDP. You can manually publish the CRL onto this new CDP, or you can automatically publish it. Automatic publishing is a whole lot easier but requires a one-way trust from the Web server (CDP) in the DMZ to the CA server in the intranet, and uses SMB traffic for this connection (which you can secure with IPsec). You would need to discuss the pros and cons of this design with your security guys. On the plus side, the connection is initiated by the trusted network only and the automation helps to reduce the possibility of the CRL not being accessible (which in turn, results in a rejected PKI connection). Manually publishing the CRL is the only option when there is no connectivity allowed between the intranet and the DMZ, and obviously carries a higher administrative overhead with a higher possibility of error.
If you are asking yourself how often the CRL gets published, you can view and configure the publication intervals for the base and delta CRLs, in the Certification Authority console. Right-click Revoked Certificates , click Properties , and the publication intervals are on the CRL Publishing Parameters tab. The default value for the base CRL publication is one week, and the default value for the delta CRL is one day. For more information about these schedules and managing certification revocation, see the Certificate Services documentation, for example: Configuring Certificate Revocation .
If you are allowed some restricted access from the intranet to the DMZ, but this excludes connections directly from the CA server, you can adapt the procedures below such that you publish the CRL onto a new server in the intranet and then copy the files to the server in the DMZ - in other words, you automatically publish the CRL to a staging server in the intranet but computers access the CRL from another server in the DMZ. Similarly, the manually publishing procedure below steps through copying the files using Explorer, but you can script this to help streamline the process for each CRL update. Additionally, the command-line utility, Certutil.exe, can be used to publish the CRL.
When multiple CDPs are listed in a certificate, a connecting computer will try each in turn, until it finds an accessible CRL. Generally, you should list the CDPs in the order in which they are most frequently used. For example, if the majority of the connecting clients were on the Internet, specifying the external HTTP CDP first would mean that these clients would not have to first try (and fail) to locate the CRL from intranet CDPs. However, if the majority of your clients were on the intranet and only a minority of them on the Internet at a given time, specifying the internal CDPs before the external CDPs would make sense. Unfortunately, there isn't a reorder option when configuring the CAs for the list of CDPs, so if you wanted to change the order in which clients tried each listed CDP, you would need to delete the existing entries and re-enter them for the required order.
In overview, the steps you will need to perform to publish the CRL onto a separate Web server include the following:
-- Carol Bailey
This posting is provided "AS IS" with no warranties, and confers no rights.