Sunday, March 29, 2015

PKI (Public Key Infrastructure) with ADCS, Part 8: web enrollment and certificate templates

Now that we have configured our subordinate CA, and have validated the configuration with PKI View (and the ADCS BPA - please see my previous blog posts), we must provide clients with a means to request certificates.

We have multiple options. We can request certificates at the command line with the certutil tool. However, this is not the most user friendly option. Group Policy can be used to distribute certificates as well. In other cases, we may simply want to request a certificate for a single user or single computer. If we install the Certificate Authority web enrollment role service...



we can request certficates using a rather user friendly web interface.

Note:

But before we can provide this option to our clients, we have to know the limitations of we benrollment. Some of these limitations have not always existed so that is something administrators familiar with Windows 2003 PKI will want to note.

This is perhaps the most important:

Certificate web enrollment cannot be used with version 3 certificate templates.

This caused a great deal of frustration for me because I had duplicated a template using the version 3 (Windows 2008) option.

This is another limitation of web enrollment:

Internet Explorer cannot run in the local computer's security context; therefore, users can no longer request computer certificates by using Web enrollment.

We can, however, paste a Base64-encoded certificate request into a text box and submit it to the CA.



***


What else do we have to know?

We cannot request a certificate using the web interface unless SSL is enabled on the IIS virtual directory certsrv, for example:

http://localhost/certsrv

(with SSL not yet enabled)

If I am at the CA, I can access the website by entering "localhost" as shown above, rather than entering the name of the server (PKI-Sub-CA-1 in my network). This can be used to troubleshoot.

But we cannot enable SSL unless we bind a certificate to the certsrv website.

At this point, we may observe the certificates available for binding and discover that we already have a certificate on the subordinate CA: the certificate issued to it by the root CA.

Stop!

Do not bind this certificate to the certsrv website.

IIS will let you do this but it is the incorrect type of certificate.

Yes, there are different types of certificates for different purposes.

The certificate issued by the root CA to the subordinate CA is designed for certificate signing (the CA signs the certificates it issues to clients).

This type of certificate cannot be used to authenticate the identity of a web server - not even the web interface for certificate requests of the CA itself.

We need to request a separate and distinct certificate for this role.

So, essentially, we will have the CA request a "web server" type certificate for itself (from itself).

At this point, you may realize that we are going in circles:

  • The CA must request a certificate for itself so we can enable SSL.
  • We cannot request a certificate because SSL is not enabled (and the existing CA certificate cannot be used for a website).

I'll present the solution in the following lines.


***


First, we have to duplicate a certificate template that can be used to issue certificates to specific clients. In our initial configuration (see the capolicy.inf files earlier), we opted not to load the default templates:

LoadDefaultTemplates=0

Note: you may have the default templates loaded so what follows immediately below may not apply to you.

We open the Certificate Authority console, highlight "Certificate Templates", right-click and select "Manage" in the menu:





There are multiple templates available. We select a template designed for a specific role. In this case, we want a certificate for a IIS web server (the web interface of our CA in fact) and there is a perfect template for that: the "Web Server" template. Right-click on the template and select "Duplicate Template":



This is where we must pay attention!

If we do not want to use web enrollment, we can use a Windows 2008 template as shown below:


If we want to use web enrollement, we must select Windows Server 2003 Enterprise. So we would check the first option instead.

Next, we are presented with nine tabs of template properties. Not all of them require additional configuration. However, we do need to provide a name for the new template. I named mine "PKI Web Server":


The validity period is 2 years by default but we can increase this to 5 years which was the maximum validity period that we configured for the subordinate CA (with the post installation script).

Optionally, we can publish the certificate in Active Directory.

There are two other changes I would like to make.

First, I want to require certificate manager approval before the certificate is issued to future requestors:




Second, clients need both read and enroll permissions to request the certificate:



Note: "Authenticated Users" includes all user accounts and computer accounts that have been authenticated by a domain controller. So these permissions apply to computers as well. If we want clients to be able to autoenroll for certificates (using Group Policy for example), we must also check the "Autoenroll" permission. It is not necessary in this case.

I mentioned earlier that certificates are designed to fulfill a particular role. We cannot use a Code Signing certificate to authenticate a web server and vice versa (a Web Server certificate to sign code). The Extensions tab of the certificate template show the purpose of the certificate. Here, we can see that this certificate can be used for "Server Authentication":


Note: it is possible for certain certificates to have multiple roles.

When we finish, we have an additional template configured for our specific needs:



We can now exit the template management window and return to the Certificate Authority console. With the Certificate Templates folder highlighted, we right-click and select "Certificate Template to Issue"



We select the PKI Web Server certificate template we just duplicated:



The certificate template is now ready for use:




Note: we could have used the default Web Server certificate template but if we want to customize our settings and permissions it is preferable to leave the default template with its default settings. If we change these, they may not be suitable for some other purpose in the future.


Now we are ready to request a "Web Server" certificate for our subordinate CA (valid for "Server Authentication"). That will be the subject of my next blog post.

To be continued...

Saturday, March 28, 2015

PKI (Public Key Infrastructure) with ADCS, Part 7: configuration of the subordinate CA (end)

We have almost finished the configuration of the subordinate CA. In this post, I will present the post intsallation script used to set certain parameters, the PKI View tool that validates certain aspects of the configuration and also the ADCS Best Practices Analyzer.

Please note that there is still much to accomplish. We still have to configure the methods of certificate enrollment. How will clients request and obtain certificates? The web interface and Group Policy are two common methods, the latter interacting with the "autoenrollment" feature. We also have to address matters like high availability, backups and restores, as well as key archiving and recovery. I aim to examine at least some of these aspects in future blog posts.


***


Post-installation script for the subordinate CA

Here is the content of the script I used:

----
::Post-install script for Sub CA

 ::Declare Configuration NC
certutil -setreg CA\DSConfigDN CN=Configuration,DC=machlinkit,DC=biz

 ::Define CRL Publication Intervals
certutil -setreg CA\CRLPeriodUnits 3
certutil -setreg CA\CRLPeriod "Days"
certutil -setreg CA\CRLDeltaPeriodUnits 0
certutil -setreg CA\CRLDeltaPeriod "Days"
certutil -setreg CA\CRLOverlapUnits 2
certutil -setreg CA\CRLOverlapPeriod "Days"

 ::Set Validity Period for Issued Certificates
certutil -setreg CA\ValidityPeriodUnits 5
certutil -setreg CA\ValidityPeriod "Years"

 ::Apply the required AIA Extension URLs
certutil –setreg CA\CACertPublicationURLs "1:%WINDIR%\System32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n
2:http://pki.machlinkit.biz/PKI/%%1_%%3%%4.crt\n
3:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11"

 ::Apply the required CDP Extension URLs
certutil –setreg CA\CRLPublicationURLs "1:%WINDIR%\System32\CertSrv\CertEnroll\%%3%%8%%9.crl\n
2:http://pki.machlinkit.biz/PKI/%%3%%8%%9.crl\n
11:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10\n
1:file://\\pki.machlinkit.biz\PKI\%%3%%8%%9.crl"

 :: Enable discrete signatures in subordinate CA certificates
certutil -setreg CA\csp\AlternateSignatureAlgorithm 1

 ::Enable all auditing events for the Sub CA
certutil -setreg CA\AuditFilter 127

 ::Restart Certificate Services

net stop certsvc & net start certsvc
----

This script, similar to the script for the root CA, sets parameters such as the validity period of the base and delta CRLs, the overlap period, the validity period of issued certificates (certificates that the subordinate CA issues) and defines the AIA and CDP Urls, in other words the locations where certificates and CRLs can be found, respectively for certificate chaining and for verification of revocation lists.

I may not have yet explained the concept of "overlap". After the validity of a CRL expires, this is the period during which the CRL can still be used. Overlap is a sort of grace period that allows the PKI administrators extra time to resolve problems before the PKI stops functioning. The overlap period cannot exceed the validity period of the CRL. So if I have a CRL with a validity period of 3 days, I could not configure the overlap period for 4 days. On the other hand, 2 days would be an acceptable setting.

The Url parameters are similar to those for the root CA with one addition: the file Url for the CDP. This addition is necessary so the CRL is published automatically to the file share indicated. Otherwise, an administrator would have to copy the CRL file manually from the location on the C: drive to the file share.

Note: we cannot publish the CRL directly to a web server using the http Url.

Note: the character combination \n separates the different Urls. For readability, I clicked "Enter" after each \n. If you copy the text above as a model, you may have to backspace as needed to remove my "Enters". Of course, you will obviously adjust the domain name as appropriate, not to mention the Urls. For example, if you use delta CRLs, you will replace the 1 in the file Url with 65. Please see the references in Part 2 of this blog post series for more information:




PKI View

PKI View is a tool that validates the configuration of the AIA and CRL locations. In particular, it tells us if the certificates and revocation lists are accessible at the Urls indicated in the script shown above for the subordinate CA and the script used previously for the root CA.

PKI View can be found in Server Manager, under the Active Directory Certificate Services role icon:




This is PKI View (even though the name is not specfically stated). At the summit of the hierarchy, we have "Enterprise PKI". In the right pane, we see the next level down which is the root CA. We also see a yellow exclamation mark icon with the status "Warning".

What is wrong?

We can move down one level to see:



At the root CA level (in my network, that is "PKI-ROOT-CA"), we can see the status of the root CA certificate, the AIA locations for both HTTP and LDAP and also the CDP locations for HTTP and LDAP. The status of all of these elements is "OK". This simply means that the certificate is valid and that certificates and (certificate) revocation lists are accessible for consultation. Any application that wants to construct a certificate chain to the summit of our PKI, or consult the CRL, will be able to do this.

In fact, it looks like, at this level, the only warning icon concerns the subordinate issuing CA which in my network is called "Machlinkit Issuing CA". We have to move down one more level to see what is the matter:


At this level, we can see that the subordinate CA certificate is OK and that it is accessible both via HTTP and LDAP. The yellow warning icon indicates that the CRL status (at both the HTTP and LDAP locations) is "Expiring". In fact, this is normal. We had configured a 3 day validity period for the CRL (with a 2 day overlap) and PKI View simply warns us that the current CRL is about to expire. As long as the CA is able to publish a new CRL to the locations in question (which we would see once the CRL does expire - look at the time stamps), the PKI will still function.

Otherwise, all is well. PKI View can access the certificates and CRLs published to Active Directory (LDAP) and to our web server (HTTP). If we open the file share to which we are publishing the CRL, we should see something like this:


Both the subordinate CA certificate and the CRL published by the subordinate CA are present (as well as the corresponding files of the root CA).

What would the PKI View show if, for example, the CRL could not be located at one of the locations indicated in the certificate extensions?

I'll illustrate this by temporarily moving the subordinate CA's CRL to another location (that would be the Machlinkit Issuing CA(1).crl file in the screenshot above). We would see the red error icon with status "Unable to download":



Note: if you tested this, following my example, you can eliminate the error above by simply moving the .crl file back to its original location.

***



Active Directory Certificate Services - Best Practices Analyzer

The ADCS Best Practices Analyzer (BPA) is another tool that can validate the configuration of our PKI. Like PKI View, we access the tool in Server Manager (see below). We select the ADCS icon and then, in the right pane, scroll down until we reach the "Best Practices Analyzer" section. In the Action pane (far right), we click on "Scan This Role". The ADCS role is scanned and results are displayed as shown in the screenshot below (click to enlarge): 





In my case, there are 3 warning entries. I have not configured autoenrollment in Group Policy and I have placed the CA database and log files on the system drive. Autoenrollment is not a necessity (we can request certificates manually and wait for administrative approval) but it does facilitate the delivery of certificates to large numbers of users and computers. In this case, we regulate access to certificates based on membership in specific security groups.

As for the location of the database and log files, I indicated, when I installed the ADCS role, that in production, we would not place these files on the system drive. In a test network, this does not matter and will not have any adverse effects.

***

So far, we have accomplished much (and validated our configuration with PKI View and the ADCS BPA)  but much more remains before our PKI will be useful to our clients.


Monday, March 23, 2015

PKI (Public Key Infrastructure) with ADCS, Part 6: configuration of the subordinate CA (continued)

Installing the ADCS role on the subordinate CA

Now we must install the ADCS role on our subordinate CA, PKI-Sub-CA-1. As for the root CA, we will add the role using Server Manager. However, many of our choices will be different. I'll open Server Manager and go to the screen where we check the ADCS role:


Note: you can click on the screenshots to enlarge them.


We can read the Introduction to ADCS that follows (no screenshot) and then proceed to the Role Services page. I will select the "Certification Web Authority Enrollment" option:


This is not absolutely necessary: we could distribute certificates solely via Group Policy and not provide a web interface for requesting certificates. However, this allows for certificate requests for non-Active Directory clients.

Note: if we want to automate certificate management for non-Active Directory clients on a large scale, we would have to examine 3rd party products such as MobileIron or VMware Airwatch.

 So, in my example, we'll select these two options:



Since PKI-Sub-CA-1 is a domain member, and since we want to be able to use Group Policy to issue certificates (perhaps among other methods), we will select the "Entreprise" option here:



Each CA must have a certificate for itself, either self-signed or issued by another CA. Since PKI-Sub-CA-1 will receive a certificate from the root CA, it will be "subordinate" (to PKI-Root-CA):



We need a new key:



I will accept the default selections in the Cryptography section:



Here, I select a name for the issuing CA:


Note: it is best practice to use a name that is different from the computer name, in this case: PKI-Sub-CA-1. This is for security reasons:



The subordinate CA must request a certificate from the root CA. This is part of the ADCS installation. However, the submission of the request to PKI-Root-CA and the issuance of the certificate will take place in a following section. Since our root CA is offline, we have to save the request as a file that we will copy to the root CA using media appropriate to our circumstances:




We then select the location for the certificate database and log files:


Note: in a real ADCS deployment, we would place the database and log files on separate redundant storage (RAID 1, 5 or 10) and at very least on a different volume than the operating system. Of course, we would want the OS on redundant storage as well. We need to keep in mind the importance of high availability for ADCS. If the CA is unavailable, sooner or later (within hours or days based on your settings), the entire PKI will stop working.



Because I selected the "Certification Web Authority Enrollment" earlier, the Role Services page will display. We can leave the default role services checked and click "Next":




We can review a summary of our choices and if all is well, click on "Install":



The installation finishes but is incomplete. We are reminded that we need to submit the certificate request to the root CA:






Submitting the certificate request to the root CA


So we need to submit the certificate request to the root CA.

First, while still at the subordinate CA, we copy the certificate request file (the location is indicated in the previous screenshot and of course may vary in each environment) to a form of media we can use to transfer it to the root CA.

Once we have copied the request file to the root CA, we open the Certification Authority console, high-light the root CA (PKI-ROOT-CA below), right-click on the icon and select "Submit new request": 


Note: we could leave the request file on the media and browse to it directly in the step below.


We then browse to the location of the request file and open it:




This places the request in the "Pending Requests" folder:




We right-click on the pending request, select "All Tasks" and then "Issue":




The issued certificate then appears in the "Issued Certificates" folder:




But now, how do we transport the issued certificate to the subordinate CA that requested it?

We need to open the certificate (double-click for example), go to the "Details" tab and click "Copy to File":




The Certificate Export wizard opens:




We select the .P7B format and check the option to include all certificates in the path:



We select a file location and name:




We click "Next" as needed and then Finish:



We then copy the exported certificate to the removable media and transfer it back to the subordinate CA that made the request.

On the subordinate CA, we open the Certification Authority, designate the CA, right-click, select "Tasks" and then "Install CA Certificate":




We then browse to the exported file and install the certificate:



The certificate should now appear in the certificate store of the subordinate CA, in the Personal folder, subfolder "Certificates":




***


We have almost finished the configuration of the subordinate CA. In the next posts, I will execute a post-installation script and demonstrate the use of "PKI View", a tool that validates certain elements of the PKI environment.

Saturday, March 14, 2015

PKI (Public Key Infrastructure), special post: training course with Mark Cooper

I'm going to interrupt the sequence of my blog posts on PKI to share an excellent experience I had learning more about the subject and that may help me avoid some signficant mistakes in future projects.

I attended a training session by Mark Cooper called "In-Depth Training for Windows Server 2012 R2 ADCS". If you've been following this blog, you know (or may have already known) that ADCS means "Active Directory Certificate Services".

And who is Mark Cooper?

Mark Cooper is a "former Microsoft Senior Engineer and subject matter expert" for ADCS. You can read more about him on the website of his company "PKI Solutions":


Otherwise, if you have heard of Brian Komar and read his "PKI and Certificate Security" (Windows Server 2008), you might be interested in knowing that Mark Cooper is working on the latest version of this book, updated for Windows 2012 R2.

The PKI training course costs $5000 for five days of both presentations and "hands-on" labs. Questions are welcome so prepare a list. In fact, and although anyone can take the course, my opinion is that you will benefit from it most if you already have some knowledge of PKI and come with questions about your future projects. If you prepare yourself well, the training may replace the need to hire a consultant, at least for less complex PKI implementations, and the cost may be compensated in that way.

Class size may vary. I was in a group of six so each participant was able to ask any questions they had and also receive personal one-on-one attention for the labs.

I learned much from the class and notably about high availability which is somewhat particular with ADCS.

With Active Directory, for example, we can achieve high availability by adding more domain controllers.

Not so with ADCS.

Before taking the class, I thought that my practice network (see previous posts) would have a root CA and then two subordinate issuing CAs (CA1 and CA2). If CA1 was unavailable, clients could simply interact with CA2. Well, this would function if it was simply a matter of requesting new certificates. But the validity of a certificate must be verifiable at any time after it is issued and that is achieved by consulting the CRL (certification revocation list).

Here is the problem: only the CRL published (and signed) by the specific issuing CA can be used to validate the certificate. Unlike the Active Directory database (for example), CRLs are not replicated among CAs. Therefore, if CA1 is not available, and the current CRL expires, clients will be unable to use their certificates because no updated CRL can be consulted. Clients cannot simply query another CA as they might query another domain controller.

As for the course, one (possible) challenge to keep in mind is that participants were expected to have a laptop powerful enough to run three to four virtual machines at a time (and thus have either VMware workstation or Windows 8 Hyper-V or a similar product). This may change in the future if participants are be able to access virtual machines in the Cloud. Such a transition was being examined when I took the course.

In general, ADCS is one of the more complex Microsoft technologies to implement and while the initial setup can be challenging enough, the real test is how well it continues to function for the duration of its existence. With that in mind, I would definitely recommend the course to anyone intending to use PKI in their environment or to offer services in PKI consulting.  









Wednesday, March 11, 2015

PKI (Public Key Infrastructure) with ADCS, Part 5: configuration of the subordinate (issuing) CA

For the subordinate (issuing) CA, that I have named PKI-Sub-CA-1, we have 5 primary tasks to complete:
  1. Create the capolicy.inf file and place it in %windir% or the C:\Windows folder.
  2. Install or "publish" the root CA's certificate and CRL in: a) the computer certificate store of the subordinate CA, b) Active Directory and c) on a web server.
  3. Install the ADCS role.
  4. Request a certificate from the root CA for the subordinate CA.
  5. Execute a post-install script.

I will now present these steps in greater detail (the first two in this blog post and the last three in the following post).

***

CAPOLICY.INF

First, this is the content of the capolicy.inf file that I have created for the subordinate (issuing) CA:

---
[Version]
Signature= "$Windows NT$"

[certsrv_server]
renewalkeylength=2048
RenewalValidityPeriodUnits=5
RenewalValidityPeriod=years
CRLPeriod = days
CRLPeriodUnits = 3
CRLDeltaPeriod = weeks
CRLDeltaPeriodUnits = 0
LoadDefaultTemplates=0
---

In summary, the key length is 2048 (the current minimum length recommended), the maximum validity period for certificates issued by this subordinate CA is 5 years (not to be confused with the length of the CA's certificate which is 10 years), the base CRL will be published every 3 days, there will be no Delta CRL and the default certificate templates will not be loaded (more about these templates later).


***



Publication of the root certificate and CRL

Second, the subordinate CA must trust the root CA. Since the root CA is offline, we have navigated to the following location...

C:\Windows\System32\Certsrv\Certenroll

And copied the root cert and root CRL to removable media (this can be a floppy disk if you still have any, a USB drive or a virtual floppy disk in a virtual environment).

We then connect the media to the subordinate CA.

At that point, we must install or publish the root CA and CRL to the following locations:
  • The subordinate CA's local computer certificate store (in particular, the "Trusted Root Certification Authorities" and "Intermediate Certification Authorities" folders).
  • Active Directory
  • At the HTTP URL designated in the AIA and CDP "Extensions" tab

Note: I will install the root certificate and root CRL to the subordinate CA manually. We could simply publish them to Active Directory instead and (if auto-enrollment is enabled in Group Policy), force the installation with the command gpupdate /force.

However, I will perform the manual install to demonstrate the process.

And once again, all these certificates and revocation lists must be available for:
  • the building of a "chain of trust" reaching from the certificate issued to the end-user (or computer), to the issuing CA and, ultimately, to the root CA.
  • revocation list verification (the revocation list must be available and consultable so revoked certificates are rejected).

I want to analyze the process and show the "before and after" status of the certificate store and Active Directory (with HTTP, it is simply a matter a copying the files in question to a folder).


First, the certificate store for the local computer. Since there is also a store for the user (each user of the computer in fact) we have to make sure we are targeting the certificate store for the server itself.

We can do this by creating a custom MMC for the "Certificates" snap-in or by adding the Certificates snap-in to an existing MMC. If you are not sure how to do this, I would suggest that you consult other sources, for example:

Creating a Console File (first part)

Note: with Windows 8, Windows 2012 Server (including R2), we can enter the following command in the "Run" box to open the certificate store for the local computer (server):

certlm.msc








--- Certificate Store (local computer) ---

Once we open the Certificates snap-in, we can see the folders described here (only the described folders play a role in our PKI).

This is the "personal" folder of the certificate store:


It is where certificates issued to the computer are stored. In the case of a root CA, it will issue itself a certificate. In the case of the issuing CA, we will have a certificate delivered by the root CA to the issuing CA with the name of the issuing CA on the certificate (illustrated in the next blog post).

In the "Trusted Root Certification Authorities" folder and the "Intermediate Certification Authorities" folder (Certificates subfolder), we have the certificates of various root authorities such as Thawte and Verisign that are shipped with the Windows operating system and trusted by default:






We also have a Certification Revocation List folder that currently holds a single revocation list:


We add the root CA's certificate to the locations above with the following command:

C:\> certutil -addstore -f Root C:\RootCertCRL\PKI-ROOT-CA_PKI-ROOT-CA.crt

Note: "C:\RootCertCRL\PKI-ROOT-CA_PKI-ROOT-CA.crt" is the path to the location where I copied the root CA's certificate on the subordinate CA.

Here is a screenshot of the command:





We add the root CA's CRL to the appropriate location above with this command:

C:\> certutil -addstore -f Root C:\RootCertCRL\PKI-ROOT-CA.crl

Now we can see the results in the following screenshots...

Our root CA's certificate is added to the Trusted Root Certification Authorities folder:



 And also to the Intermediate Certification Authorities folder (no screenshot).

Furthermore, the root CA's CRL is added to the subordinate CA's Certificate Revocation List folder:






--- Active Directory ---

There are a number of locations in Active Directory where certificate information will be published. We can see them using the AdsiEdit.msc tool (target the configuration partition).

The AIA information will be published in the CN=AIA folder. This is the "before" view:






The CRL will be published in the CN=CDP folder:





As a note, certificate templates will be created in this location (we'll see more about these templates later).



Lastly, CA certificates will be published here:




This is the command that we use to publish the root CA certificate into Active Directory:

C:\> certutil -dspublish -f C:\RootCertCRL\PKI-ROOT-CA_PKI-ROOT-CA.crt RootCA

When the RootCA option is used, the certificate is published to both the CN=AIA and the CN=Certification Authorities locations (click on images to enlarge):







As for the CRL, this command publishes the root CA CRL to Active Directory:

C:\> certutil -dspublish -f C:\RootCertCRL\PKI-ROOT-CA.crl


Note: you may have an error message here, something about an "UnavailableConfigDN". Like others, I thought that perhaps it is necessary to add the "RootCA" suffix at the end - as for the certificate command earlier. When I added "RootCA", the command completed successfully and published the CRL to this location:



However, this is not what we want. The subfolder should have the name of the CA, and we do not have a CA named "RootCA".

You will probably need to run this command:

certutil -setreg ca\DSDomainDN "DNpath"

Based on my example above, this would be:

certutil -setreg ca\DSDomainDN DC=machlinkit,DC=biz

If the command executes successfully, we would then attempt to publish the root CRL to Active Directory again.


Here's another discussion about this error:

UnavailableConfigDN


***

Now that the root CA certficate and CRL are available in Active Directory, they will be propagated via Group Policy to client computers without manual intervention. We can force this to happen immediately with the command gpupdate /force on a particular machine - or wait for around 90 minutes and let Group Policy update automatically.





--- HTTP Url on IIS web server ---

If we have clients that are not Active Directory domain members, we can make the certificates and CRLs available to these clients using a virtual directory on a web server. In this example, I will use IIS on a server named PKI-File-Svr1. In fact, we could opt to use IIS only, and not publish certificates to Active Directory at all. Indeed, nothing prevents Active Directory domain members from accessing a web share. However, I will use both methods, if only to demonstrate the implementation of each.

First, we need to create a shared folder on a server running IIS. Installing and configuring IIS in general is beyond the scope of this post but it is essentially a matter of using Server Manager to add the IIS role.

I'll create a folder called "PKI" on the IIS server:


I'll share the folder and configure share and NTFS permissions (if you do not know how to do this, please consult sources online). We will grant the "Cert Publishers" group "Change" share permissions and NTFS "Modify" permissions, respectively:







Note: we can leave the other permissions as they are.

When we install the ADCS role on PKI-Sub-CA-1, our subordinate issuing CA (next post), this process will add that server to the "Cert Publishers" group. By providing the appropriate access to the PKI share, as we have done above, we allow PKI-Sub-CA-1 to publish certificates and CRLs to this location as needed, without need for repeated manual intervention.

In the IIS Management Console, we then create a virtual directory and associate it with the shared folder we created earlier:








Lastly, we copy the CA root certificate and CRL into the shared folder:





The top of the screenshot shows the virtual directory in IIS and the lower part shows the two files that I have copied into the "PKI" shared folder.



***

We'll finish the configuration of the subordinate issuing CA in my next blog post.