For a short recap, AD CS is the backbone of Microsoft’s Public Key Infrastructure (PKI) implementation. It will allow you to issue certificates for SSL/TTL user on websites or digitally sign your email.

Now let’s take a look at installing Active Directory Certificate Services.

Certain versions of Server 2008 only allow certain AD CS components to be installed; please take a look at this table for reference:

• CA – issues certificates to users, computers and services while also managing their validity; comes in root and subordinate
• Network Device Enrollment Service – allows network devices (i.e. routers) to request and receive certificates based on Simple Certificate Enrollment Protocol (SCEP)
• Online Responder Service – implements Online Certificate Status Protocol (OCSP) by evaluating certificate status, decoding revocation status requests, and sending back signed responses containing certificate status information

Install Enterprise Certificate Authority on a Windows 2008 Server

As I outlined in my earlier article, there are two varieties of root CA’s: the Enterprise and Stand-Alone. Each has their advantages and configuration, but in this case we are going to install an Enterprise CA.

I am going to be installing this root CA server in my test Active directory domain named ADExample.com on a Windows Server 2008 Enterprise version.

The server is a member of the domain, and is a domain controller. Let’s get started.

1. Open Server Manager.

2. Select Roles, then click Add Roles in the center pane.

3. The Before You Begin page may show up if you haven’t turned it off already. If you see it just click Next.

4. In the Select Server Roles window go ahead and select Active Directory Certificate Services by placing a checkmark next to it, then go ahead and click Next.

5. Now you will see an Introduction to Active Directory Certificate Services, where you can read about the good things you can do with AD CS.

The biggest thing to note here is the following:

Name & Domain settings of this computer cannot be changed after a CA has been installed. If you want to change the computer name, join a domain, or promote this server to a domain controller do so BEFORE install thing the CA.

Now with that warning out of the way, go ahead and click on Next.

6. Next you get to Select Role Services, which can include any of the following depending on what version of Windows Server 2008 you are installing this on — refer to the table above for specifics.

For this install I am going to choose the Certification Authority only.

7. Now comes the Specify Setup Type, and for this I am going to select the Enterprise radio button.

8. For the Specify CA Type, I am going to choose the Root CA radio button and then click Next.

9. In Set Up Private Key, I am going to choose Create a new private key radio button and then select Next.

10. Now you have to Configure Cryptography for CA in this window and there are quite a few to choose from.

Now I am no expert on cryptography, but some basic rules do apply … the longer the key the harder it is to crack. For our purposes I am going to use the following settings:

RSA#Microsoft Software Key Storage Provider
4096 Key Character length
md5 Hash algorithm

Now I am going to click Next.

11. In Configure CA Name you can choose to overwrite the default common name for this CA and also the Distinguished name suffix if you so choose.

I am going to overwrite the default common name with Test-Enterprise-CA, but I will leave the rest alone.

12. Next we will Set Validity Period for this CAs certificate.

Remember a root CA issues itself a certificate. The default is 5 Years so I will just leave it at that. You can change this based on any need you might have in your environment. Click Next.

13. Configure Certificate Database will let you specify where you want to put the database and log files for the CA.

I am going to leave the default in place. Click Next.

14. On the Confirm Installation Selections you can see the answers you have chosen and you will again see a warning that you cannot change the computer name or domain settings for this server after installing the CA.

Go ahead and click Install… you know you want to!

15. After a few minutes you will see the Installation Results, and with any luck you will have the message: Installation succeeded.

After your glow of certificate happiness fades go ahead and click Close.

16. Now let’s go in and take a look by clicking on Certification Authority in Administrative Tools (if you get a UAC pop up just click Ok).

17. Now you can see the snap-in is showing the CA named Test-Enterprise-CA in the left pane with a bunch of folders for certificates.

18. You can also see that if you click the Certificate Templates folder, there are quite a few default templates that are already setup and ready to go.

Summary

Now that we have installed the Active Directory Certificate Services the next step would be to request some certificates and configure them.

The installation for a stand-alone CA is very similar to this. In fact if you are not in a domain and if you are not installing as a domain admin you will not even get the option for an Enterprise CA setup, so if you see that grayed out you now know why.

In my next article we will take a look at some of the uses for certificates and how to request and install them on servers and clients.

Related posts:

• Server 2008: Active Directory Certificate Services
• Windows Server 2008: Install Active Directory Domain Services
• Active Directory Improvements in Windows Server 2008

Certificate Services are the backbone for using Public Key Infrastructures (PKI) on a Windows Server.

In case you don’t know what PKI is — it is a security system of digital certificates, certification authorities (CAs), and registration authorities. PKI verifies the identity of each side that is involved in the digital transaction by verifying the certificates they are using.

Microsoft’s implementation of PKI is in a hierarchical CA model. A very simple example will have just a single Certification Authority, but it is very scalable to contain multiple CAs with defined parent and child roles.

At the top of the hierarchy is the Root CA, with every CA that is a child under that root being called a Subordinate CA.

The root CA in this implementation is key, if you trust the root CA then you trust every subordinate CA in that hierarchy that has a valid certificate. Because of this the root CA should be highly secured as it is the pinnacle of trust in an organization.

Root Certification Authority

As we discussed, the Root CA is the highest level of trust in the organization’s Public Key Infrastructure. If it gets compromised all your subordinate CAs are vulnerable to exploitation. Because of this, not only should the root CA be secured at the system level at all times, but in the physical as well.

Best practice is to only issue certificates for other subordinate CAs from the root CA even though you could issue certificates to end users.

Subordinate Certification Authority

Really the workhorses of the PKI organization, the subordinate CAs will be the servers that should be issuing certificates for most end user needs.

Some of these needs are secure e-mail, Web-based authentication, or smart card authentication. The subordinate CA will derive its authority from either the root CA or a subordinate CA that has issued it a certificate building, another layer in the hierarchy.

Some of the reasons for setting up multiple subordinate CAs are:

• Load Balancing — If you issue a large number of certificates and they are in use constantly you will want several subordinates to issue the same kind of certificate to balance the load among multiple servers.
• Redundancy — If you only have one CA and it fails, there will be nothing to respond to user requests and that is going to be a problem. By having multiple CAs you can guarantee to have something to respond to those requests.
• Logical and Geographic Division — Whether your network is divided by logical organizations or even physical sites, it might make sense to have different CA’s available in those different divisions to service those specific users and ease administrative strain.
• Usage — You may find it advantageous to divide your CAs by their usage, such as one set only does secure e-mail and another set does network authorization. This can make delegation and administration of those functions easier to deal with.

There are also many 3rd party CA suppliers such as Verisign or GeoTrust which use various methods to verify users’ credentials before issuing a certificate to them.

It is important to stress that ANYONE can create a CA so you must decide if you are going to trust those 3rd party CAs based on their stated policies and administration.

While these 3rd party issuers are useful for certain applications like e-commerce websites, most internal company uses will not require such measures and an internal CA structure should be setup.

Enterprise Certification Authorities

These CAs are tied into the Active Directory Domain Services (AD DS) role in the domain and that gives them additional functionality. You can use an Enterprise CA to issue certificates for the following:

• Digital Signatures
• Secure E-mail Using S/MIME (Secure MultiPurpose Internet Mail Extensions)
• Authenticate to a Secure Web Server Using Secure Socket Layer (SSL) or Transport Layer Security (TLS)
• Logon to the Domain Using a Smart Card

To install an Enterprise CA you will need access to Active Directory Domain Services which requires a user that is a member of the Domain Admins group or an administrator with write access to AD DS.

One of the benefits of being tied into the AD DS is that it can use Group Policy to propagate its certificate to the Trusted Root Certification Authorities certificate store for all users and computers in the domain. It will also publish user certificates and certificate revocation lists (CRLs) to AD DS.

Enterprise CAs can issue certificates based on templates which will do the following:

• Enforce credential checks on users during enrollment. Every certificate will have permissions set in AD DS that will determine if the requester has authorization to receive the type of certificate they are trying to request.
• Subject name can be generated in the template from information in AD DS or it can be supplied by the user requesting the certificate.
• Predefined list of extensions to be used by the certificate which will reduce the information the user has to supply to receive the requested certificate.
• Users can be issued certificates through Autoenrollment

Stand-Alone Certification Authorities

These CAs share many similarities with their Enterprise cousins but not all of the functions. They also require more administration then an Enterprise CA because there is no verification of the users credentials from the AD DS.

You can use the Stand-Alone CAs for the following:

• Digital Signatures
• Secure E-mail Using S/MIME (Secure MultiPurpose Internet Mail Extensions)
• Authenticate to a Secure Web Server Using Secure Socket Layer (SSL) or Transport Layer Security (TLS)

Some of the characteristics of a Stand-Alone CA are as follows:

• All certificate requests are set to pending for the administrator to manually review. This is the default action and it is recommended that you use this mode especially if you are installing a stand-alone CA in a domain.
• Templates are not used
• Administrator has to specifically distribute the stand-alone CA’s certificate to the users’ trusted root store or users will have to do it themselves

As mentioned above, a stand-alone CA can be installed in a domain and will gain these additional functions:

• If a Domain Admin or an administrator with write access installs the stand-alone root CA, it will publish its certificate to the Trusted Root Certification Authorities certificate store for all domain users and computers.
  
  Because of this reason it is well advised that you leave all requests to pending to verify identity otherwise any requested certificate will be trusted by the entire domain.
• A stand-alone CA will also publish its certificate and certification revocation list (CRL) to AD DS if it is installed by a Domain Admin or account with write access to AD DS.

Summary

This article has given you a broad overview of Active Directory Certificate Services and hopefully gotten you ready to take the next step and start to look at how to implement.

In my next article I will show you how to install the services on a Windows 2008 Server and create a certificate.

Related posts:

• Server 2008: Install Active Directory Certificate Services
• Active Directory Improvements in Windows Server 2008
• Active Directory Rights Management Services: System Requirements & Other Considerations