Server 2008: Active Directory Certificate Services

Posted on August 14th, 2008 by Dave Lawlor

Active Directory Certificate Services are an installed role that can be used on either a domain joined or standalone 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:

Tags: , , , , , , ,

Leave A Comment: