A Complete Guide on Active Directory Certificate Services in Windows Server 2008 R2

Windows Server 2008 R2 includes a built-in Certificate Authority (CA) technology that is known as Active Directory Certificate Services (AD CS). The first iteration of AD CS emerged with Windows Server 2008, though previous versions of the technology were simply known as Certificate Services. AD CS can be used to create certificates and subsequently manage them; it is responsible for ensuring their validity. AD CS is often used in Windows Server 2008 R2 if there is no particular need to have a third-party verify an organization’s certificates. It is common practice to set up a standalone CA for network encryption that requires certificates only for internal parties. Third-party certificate authorities such as VeriSign are also extensively used but require an investment in individual certificates.

Although the term Active Directory has been incorporated into the name of the Windows Certificate Services function, it should be understood that AD CS does not necessarily require integration with an existing Active Directory Domain Services (AD DS) forest environment. Although this is commonly the case, it is important to understand that AD CS has independence over AD DS forest design.
Windows Server 2008 R2 introduced a few additions to AD CS features, including the following:

Certificate Enrollment Web Service and Certificate Enrollment Policy Web Service— This is the most significant improvement, essentially allowing certificates to be enrolled directly over HTTP, enabling non-domain or Internet-connected clients to connect and request certificates from a CA server.

Improved support for high-volume CAs used for NAP— AD CS in Windows Server 2008 R2 improves the database performance when high-volume scenarios such as NAP are utilized.

Support for cross-forest certificate enrollment— AD CS in Windows Server 2008 R2 allows for CA consolidation across multiple forests.

Reviewing the Certificate Authority Roles in AD CS

AD CS for Windows Server 2008 R2 can be installed as one of the following CA types:

Enterprise root certification authority— The enterprise root CA is the most trusted CA in an organization and should be installed before any other CA. All other CAs are subordinate to an enterprise root CA. This CA should be highly physically secured, as a compromise of the enterprise CA effectively makes the entire chain compromised.

Enterprise subordinate certification authority— An enterprise subordinate CA must get a CA certificate from an enterprise root CA but can then issue certificates to all users and computers in the enterprise. These types of CAs are often used for load balancing of an enterprise root CA.

Standalone root certification authority— A standalone root CA is the root of a hierarchy that is not related to the enterprise domain information. Multiple standalone CAs can be established for particular purposes. A standalone root CA is often used as the root for other enterprise subordinate CAs to improve security in an environment. In other words, the root is configured as standalone, and subordinate enterprise domain integrated CAs are set up within the domains in a forest to provide for autoenrollment across the enterprise.

Standalone subordinate certification authority— A standalone subordinate CA receives its certificate from a standalone root CA and can then be used to distribute certificates to users and computers associated with that standalone CA.


Making decisions about the structure of AD CS architecture is no small task, and should not be taken lightly. Simply throwing AD CS on a server as an enterprise CA and letting it run is not the best approach from a security perspective, as compromise of that server can have a disastrous effect. Subsequently, it is wise to carefully consider AD CS design before deployment. For example, one common best practice is to deploy a standalone root CA, then several enterprise subordinate CAs, and then to take the standalone root CA physically offline and secure it in a very safe location, only turning it on again when the subordinate CAs need to have their certificates renewed.
Detailing the Role Services in AD CS

AD CS is composed of several role services that perform different tasks for clients. One or more of these role services can be installed on a server as required. These role services are as follows:

Certification Authority— This role service installs the core CA component, which allows a server to issue, revoke, and manage certificates for clients. This role can be installed on multiple servers within the same root CA chain.

Certification Authority Web Enrollment— This role service handles the web-based distribution of certificates to clients. It requires Internet Information Services (IIS) to be installed on the server.

Online Responder— The role service responds to individual client requests regarding information about the validity of specific certificates. It is used for complex or large networks, when the network needs to handle large peaks of revocation activity, or when large certificate revocation lists (CRLs) need to be downloaded.

Certificate Enrollment Web Service— This new service enables users and computers to enroll for certificates remotely or from nondomain systems via HTTP.

Certificate Enrollment Web Policy Service— This service works with the related Certificate Enrollment Web Service but simply provides policy information rather than certificates.

Network Device Enrollment Service— This role service streamlines the way that network devices such as routers receive certificates.

Installing AD CS

To install AD CS on Windows Server 2008 R2, determine which server will serve as the root CA, keeping in mind that it is highly recommended that this be a dedicated server and also recommended that it be physically secured and shut off for most of the time to ensure integrity of the certificate chain. It is important to note that an enterprise CA cannot be shut down; however, a standalone root with a subordinate enterprise CA can be shut down. If the strategy of having a standalone root with a subordinate enterprise CA is taken, the root CA must first be created and configured, and then an enterprise subordinate CA must then be created.

In smaller scenarios, an enterprise root CA can be provisioned, though in many cases, those smaller organizations might still want to consider a standalone root and a subordinate enterprise CA. For the single enterprise root CA scenario, however, the following steps can be taken to provision the CA server:


After AD CS is installed onto a server, the name of that server and the domain status of that server cannot change. For example, you cannot demote it from being a domain controller, or you cannot promote it to one if it is not. Also, the server name must not change while it is a CA.
1. Open Server Manager (Start, All Programs, Administrative Tools, Server Manager).

2. In the Nodes pane, select Roles, and then click the Add Roles link in the tasks pane.

3. Click Next at the welcome page.

4. On the Select Server Roles page, check the box for Active Directory Certificate Services, and then click Next.

5. Review the information about AD CS on the Introduction page, and click Next to continue.

6. On the Select Role Services page, shown below, choose which role services will be required. A base install will need only the Certificate Authority role. Click Next to continue.

7. Select whether to install an Enterprise (integrated with AD DS) CA or a Stand-alone CA on the subsequent page. In this example, we are installing a domain-based enterprise root CA. Click Next to continue.

8. On the Specify CA Type page, specify the CA type, as shown below. In this case, we are installing a root CA on the server. Click Next to continue.

9. On the following Set Up Private Key page, you can choose whether to create a new private key from scratch or reuse an existing private key from a previous CA implementation. In this example, we create a new key. Click Next to continue.

10. On the Configure Cryptography for CA page, enter the private key encryption settings, as shown below. Normally, the defaults are fine, but there might be specific needs to change the CSP, key length, or other settings. Click Next to continue.

11. Choose a common name that will be used to identify the CA. Bear in mind that this name will appear on all certificates issued by the CA. In this example, we enter the common name CompanyABC-CorpCA. Click Next to continue.

12. Set the validity period for the certificate that will be installed on this CA server. If this is a root CA, the server will have to reissue the certificate chain after the expiration period has expired. In this example, we choose a 5-year validity period, though many production scenarios will have a 20-year CA created for the root. Click Next to continue.

13. Specify a location for the certificate database and log locations, and click Next to continue.

14. Review the installation selections on the confirmation page, as shown below, and click Install.

15. Click Close when the wizard is complete.

After you install AD CS, additional CAs can be installed as subordinate CAs and administration of the PKI can be performed from the Certification Authority console (Start, All Programs, Administrative Tools, Certification Authority).

Using Smart Cards in a Public Key Infrastructure

A robust solution for a Public Key Infrastructure network can be found in the introduction of smart card authentication for users. Smart cards can be microchip enabled plastic cards, USB keys, or other devices.

User logon information, as well as certificates installed from a CA server, can be placed on a smart card. When a user needs to log on to a system, she places the smart card in a smart card reader or simply swipes it across the reader itself. The certificate is read, and the user is prompted only for a PIN, which is uniquely assigned to each user. After the PIN and the certificate are verified, the user is logged on to the domain.

Smart cards are a form of two-factor authentication and have obvious advantages over standard forms of authentication. It is no longer possible to simply steal or guess someone’s username and password in this scenario because the username can be entered only via the unique smart card. If stolen or lost, the smart card can be immediately deactivated and the certificate revoked. Even if a functioning smart card were to fall into the wrong hands, the PIN would still need to be used to properly access the system. Smart cards are fast becoming a more accepted way to integrate the security of certificates and PKI into organizations.

Using the Encrypting File System (EFS)

Just as transport information can be encrypted via certificates and PKI, so too can the NT File System (NTFS) on Windows Server 2008 R2 be encrypted to prevent unauthorized access. The Encrypting File System (EFS) option in Windows Server 2008 R2 allows for this type of functionality and improves on the previous EFS model by allowing offline folders to maintain encryption sets on the server. EFS is advantageous, particularly for laptop users who tote around sensitive information. If the laptop or hard drive is stolen, the file information is worthless because it is scrambled and can be unscrambled only with the proper key. EFS is proving to be an important part of PKI implementations.

Windows 7 and/or Windows Vista BitLocker go one step further than EFS, allowing for the entire hard drive, aside from a few boot files, to be encrypted. This also requires PKI certificates to be set up.

Integrating PKI with Non-Microsoft Kerberos Realms

Windows Server 2008 R2’s Active Directory component can use the Public Key Infrastructure, which utilizes trusts between foreign non-Microsoft Kerberos realms and Active Directory. The PKI serves as the authentication mechanism for security requests across the cross-realm trusts that can be created in Active Directory.

You want to learn more? Check out my new book below and have access to great and practical tutorials and step-by-step guides all in one book:

To get more information about the book click on the book below:


21 thoughts on “A Complete Guide on Active Directory Certificate Services in Windows Server 2008 R2

  1. Hi Nice article, Can I go back and change the key character length to a larger size such as 5400. I need to test larger size certificates with dot1x authentication and don’t want to create a new certificate.

    • I am sorry for the late reply Scott… Yes you can increase that but you have to really consider the effect it might have on the performance. I have tried 4096 but I am not sure about 5400… I assume the max should be 4096… But like I said, it rally impacts the performance… You should be working for CIA if you want to do it really 🙂 (Kidding)

  2. Thanks, good article. What if you want to replace your CA server for whatever reason? (Hardware faulty and ancient, or Windows old and crufty, etc). Is it possible? If so, what is the procedure?

  3. hi i was reading your article and was wondering to myself about a step by step process to initiating the ad ca now i also need a 5400 is there a way to set that up from the very beginning or do i need to wait till after it’s installed

  4. good info…although, I’m not understanding why you can stand up a standalone AD CS, but can not use the two services to manage Certificate activity unless its an enterprise CA with requires AD forrest integration, or am I confusing the requirments of these two services…?

    • Chanda, what two services are you referring to? You can use a standalone root CA and place an enterprise subordinate CA below that in the hierarchy… That’s only to bring more security to CS infrastructure…

  5. I believe everything said made a lot of sense. However,
    think on this, what if you were to create a killer post title?
    I ain’t saying your content is not solid, but suppose you added a post title that grabbed a person’s attention?

    I mean A Complete Guide on Active Directory Certificate Services in Windows Server 2008 R2 | Security Dreams May
    Come True… is a little vanilla. You should glance at Yahoo’s front page and watch how they create post headlines to grab people to open the links. You might add a related video or a picture or two to get people excited about everything’ve written.
    In my opinion, it could make your posts a little livelier.

    • Hi there…

      You made a nice point actually… I agree with the point that choosing a really good title is very important but we also need to make sure that the title fits the type of content you are putting here… “Security Dreams may Come True” is also the name of my blog… And another thing is that more than 80% of my blog traffic is generated from search engines and that is why the users are only looking for content on my blog and they usually do not care much about the other stuff… Nevertheless, I still do not disagree with the fact that good titles and attractive posts will get more viewers… They do, but maybe things are a bit different about this blog or maybe more specifically this blog post…

      Thanks for your comment… I really appreciate your feedback…


  6. Everyone loves what you guys tend to be up too. Such clever work and coverage!

    Keep up the good works guys I’ve included you guys to my blogroll.

  7. Could you recommend any best practices when migrating to 2012 DCs? The CA server is a separate server in the environment but am finding it difficult to find information when doing a DC migration and the impact it will have on the CA server. Thanks

  8. Pingback: Sccm 2012 R2 MAC Enrollment & HTTPS connections setup | Sevens IT

  9. I have a small environment composed of about 250 users. I like to keep the infrastructure not-over engineered for the size of this company and their needs. The only reason we currently need a CA is for WiFi authentication and ultimately for the NPS server. I will not be installing certificates on company’s computers as most of them are not even bound to our domain (dont ask me why). I just want for the users to be able to connect to the employee secure WiFi network with their AD credentials. I really don’t want to build a stand-alone CA and then keep it shut off for whatever number of years while utilizing Subordinate Enterprise CAs (rele installed our DCs most likely). I want to keep things simple. My plan was to: 1. install the Enterprise root CA on the 1st domain controller. 2. install the subordinate CA role on the two remaining domain controllers. Would this be really insecure from the certificate infrastructure perspective? BTW, very nice article.

  10. Hi Ralph

    I got a very similar environment and i would like to setup exactly the same as you explain; now we are using W2003R2 domain controller with IAS for wifi authentication without having a CA but, as we are upgrading to w2008R2, seems that for NPS having a CA is a must.

    have you done the plan? did you see some side effects?
    My fear is about enabling a CA on a 500+ host domain could generate some side effect.
    Please let me know

  11. After I initially left a comment I appear to have clicked the -Notify me
    when new comments are added- checkbox and now each time
    a comment is added I get four emails with the same comment.
    Is there a way you can remove me from that service?

Leave a Reply

Your email address will not be published. Required fields are marked *