[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:
- Your Internet-based site systems are in the DMZ but the issuing CA for the client computers is in a separate forest in the intranet. These Internet-based site systems will not be able to access the CRL for clients connecting over the Internet.
- Your Internet-based site systems are in the DMZ but the issuing CA for these servers is in a separate forest in the intranet. When clients connect from the Internet and they are configured for CRL checking, they will not be able to access the CRL for the server certificates on the Internet-based site systems.
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:
- On your separate server, configure IIS for a new virtual directory (or new Web site) that specifies the local folder that will contain the files for the CRL. See the procedure To configure a separate Web server to publish the CRL.
- Publish the CRL onto the server either manually or automatically:
- If you need to manually copy the files for the CRL rather than use a file share to do this automatically from the CA, see the procedure To manually publish the CRL on a separate server.
- If you can automatically publish the CRL using a file share, see the procedure To automatically publish the CRL on a separate server.
To configure a separate Web server to publish the CRL
- On the Web server, load Internet Information Services (IIS) Manager
- Create a new virtual directory (or new Web site) with the following information:
- Give it a name (alias) such as crl.
- Select the local folder that will contain the CRL files – for example, C:CRL.
- Specify the directory access permissions of Read.
To manually publish the CRL on a separate server
- On the CA server, load Certification Authority, expand your CA, right-click Revoked Certificates, click All Tasks, and then click Publish.
- On the Publish CRL popup dialog box, ensure that New CRL is selected, and then click OK.
- Using Explorer, locate the folder that contains the CRL files. By default, these files are in %windir%system32certsrvenroll but this location can be changed on the Extensions tab of the CA properties.
- Copy all the files with a .crl extension to removable media.
- On the Web server computer, create a new local folder to contain the CRL (for example, C:CRL).
- Paste the files with the .crl extensions into this folder.
To automatically publish the CRL on a separate server
- Ensure that a trust relationship exists such that the Web Server trusts the CA Server.
- On the Web server computer, create a new local folder to contain the CRL files (for example, C:CRL).
- Configure the folder with the following:
- Share the folder, for example, with the share name of CRL.
- Specify the share permissions of Read and Change to the CA server computer account.
- Specify NTFS permissions of Read and Write to the CA server computer account.
- Publish CRLs to this location
- Publish Delta CRLs to this location
To specify the separate Web server as a CDP
- On the CA server, load Certification Authority, right-click your CA, select Properties, and then click the Extensions tab.
- Ensure that CRL Distribution Point (CDP) is selected, and then click Add.
- In the Add Location dialog box, type the following and then click OK: http://<FQDN_of_Web_Server/<CRL_directory_name>/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl For example, if your Web server was called server2.contoso.com and the virtual directory you created in IIS was called CRL, you would type http:// server2.contoso.com/crl/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
- Ensure that the following options are selected for this new entry:
- Include in CRLs. Clients use this to find Delta CRL locations.
- Include in the CDP extension of issued certificates
To confirm CRL access
- From a computer on the same network as the separate Web server, load a browser and type in the same CRL path that you specified in step 3 for the procedure “To specify the CRL on a separate Web server”. For example, if your Web server was called server2.contoso.com and the virtual directory you created in IIS was called crl, and your CA name was Contoso Root CA, you would type http:// server2.contoso.com/crl/contoso root ca.crl for the base CRL, and type http:// server2.contoso.com/crl/contoso root ca+.crl for the delta CRL.
- You should see a File Download dialog box, asking you whether you want to open or save this file. Click Open.
- You should now see the Certificate Revocation List with a General tab and Revocation List tab. On the General tab, the value for Issuer will be your CA server. On the Revocation List you will see any certificates that have been revoked by the CA.
- Click OK.
To confirm new certificates contain new CDP
Request and issue a new certificate after you have completed the procedure “To specify the CRL on a separate Web server”.
- On the requesting computer, load the Certificates MMC and locate the newly installed certificate.
- Double-click the certificate to view its properties.
- Click the Details tab and click the field CRL Distribution Points.
- View the values in this field. There will be multiple CRL distribution points listed so scroll down until you see the HTTP CRL distribution point that you added (for example: URL=http://server2.contoso.com/crl/Contoso%20Root%20CA.crl )
This posting is provided “AS IS” with no warranties, and confers no rights.