Category: PKI and Certificate Services

A Certificate Authority (CA) is an entity which is trusted to validate and certify the identities of others. In reality a CA is a company which maintains a software package that can manage the requests, issuance and revocation of certificate files. A CA is created by installing a certificate management software package such as Microsoft Certificate Services and implementing policies to identify and issue certificates to requestors. Certificate issuance policies fall into two general categories.

Software Issuance Policies – These policies use some form of existing credential to issue a certificate. In some cases this may be as simple as validating that your email address is in fact your email address as in the case of Thwarte (www.thwarte.com). In other cases you must have a trusted network credential. This is the method used by Active Directory integrated CAs. These CAs are referred to as enterprise CAs. Enterprise CAs will be discussed in more detail in a future article.

Manual Issuance Policies – These policies involve non-technical verification of identity and may include methods such as notarized letters, photo IDs or in some cases fingerprinting. These are generally only found in highly secure environments such as those found in large companies or the government.

This article is the first in a series that will cover the design, implementation and management of a PKI. PKI systems have become more and more common in modern IT environments as more technologies are built to take advantage of the strong authentication provided by certificates.

What is a PKI?

A PKI is defined as “the set of policies, practices and components that make up a certificate hierarchy”. There are several key components that must be understood to implement a PKI.

Certificate: A file that follows the X.509 syntax. A certificate contains information identifying the holder, where the certificate came from, when the certificate is valid, what the certificate can be used for, how the certificate can be verified and a thumbprint.

CA: A Certificate Authority (CA) is a software package that accepts and processes certificate requests, issues certificates, and manages issued certificates.

Technologies that Drive PKI

Simply put, it is the role of a PKI to issue and manage certificates. It is fundamental to understanding the operation of a PKI, and that a good understanding of the operation of certificates exist.

Certificates provide the basis for authenticating an entity. This authentication is based on several key principals, some of which are managed by technology, others that are managed by law and organizational policy. At its core, a certificate implements two key technologies; asymmetric encryption (often called public/private key encryption) and hashing.

Installing Certificate Services on Windows 2000 is quite simple, though the choices available to you will again depend on your environment. For the purpose of this illustration I will walk through the process of creating a Standalone Root CA – mainly because my computer is not configured as a domain member at the moment. Since it is not installed by default, you will need to add Certificate Services using the Add/Remove Programs – Windows Components option in Control Panel.

Note that when you attempt to choose Certificate Services, you will be presented with the dialog box shown below. Note the fact that you will not be able to rename the system or join or be removed from a domain without first uninstalling Certificate Services.

After choosing Next, you will be asked to decide what type of CA you wish to create. My system has only the Standalone CA options available, since it is not a member of an Active Directory domain.

Note that the Advanced options checkbox on the screenshot above will allow you to choose advanced cryptographic options in the key generation process. I would suggest allowing the default values to be used unless you are certain of the need to make other choices.

Clicking Next again will bring you into the CA Identification screen, where you should enter the appropriate information. Note that while not all fields are mandatory, they should be completed in full.

The final screen in the process asks for where you wish to place configuration and logging data.

Once Certificate Services is installed, the Server is ready to accept certificate requests from clients. For a Standalone CA these requests must be made a web browser by accessing the certificate server using the URL http://computername/certsrv. A wizard that walks you through the process step-by-step handles the actual request process.

The certificate request process also includes providing information about the user, the use of the certificate, and so forth. I am requesting a certificate to secure email.

After the request is completed, the user is presented with the following message. Note that the request has been made, but the certificate will not be issued until approved by the Administrator.

The approval process for a requested certificate is pretty straightforward. Using the Certificate Authority tool in Administrative Tools, open the Pending Requests option, and choose to Issue the certificate or deny the request.

Note that once completed, the user can again access the Certificate Services web site and download and install their new certificate. The certificate just issued will now be found in the Issued Certificates section from the screen above, and can be revoked from this interface as well. In an Active Directory environment, note that users can also request certificates using the Certificates MMC snap-in, or can be configured for auto-enrollment of certificates (on both a user and computer basis) via Group Policy. In large environments running an Enterprise CA, this is often the most practical idea.

Before covering the installation of Certificate Services in Windows 2000, it is important to understand the different types of Certificate Authorities that can be installed. A root CA is the top link in a chain of CAs, while a subordinate CA is a downlevel server that has one or more CAs above it (and eventually reaching a Root CA). Windows 2000 supports 4 types of CAs, as described below.

Enterprise Root CA – An Enterprise Root CA is used in corporate environments for issuing certificates to users and computers. An Enterprise CA requires that Active Directory exist, DNS be configured correctly, and that the user configuring the server have Enterprise Administrator privileges. In an Active Directory environment, an Enterprise Root CA is automatically registered in Active Directory and trusted by domain computers. In a large PKI setup, the Enterprise Root CA is usually used to issue certificates only Enterprise subordinate CAs, who then issue certificates to users and computers. Though this is often the case, it does not have to be, as an Enterprise Root CA can issue user and computer certificates as well.

Enterprise Subordinate CA – An Enterprise Subordinate CA is a certificate server that exists hierarchically under an Enterprise Root CA. Often Subordinates are used to for a specific purpose, such as granting certificates for users, or computers, or for a specific portion of an organization. A Subordinate CA requires all of the same services and privileges as an Enterprise Root CA, and cannot be created unless an Enterprise Root CA exists. Note that although the Enterprise Root CA might be another internal Windows 2000 certificate server, it might also be an external CA such as Verisign. In fact, if you want the outside world to trust the authenticity of your certificates, it is pretty much imperative that you trust an External Root CA such as Verisign. Otherwise, external users will need a copy of your Root CA’s certificate, which they are certain not to have, unless as part of some partner relationship.

Standalone Root CA – For environments without Active Directory, a Standalone Root CA can meet certificate requirements. These servers require only Administrator privileges on the server. If Active Directory does not exist in the environment, this is the only type of Root CA that can be installed.

Standalone Subordinate CA – Much like the Enterprise Subordinate CA, this certificate server might be used to issue certificates to certain departments or users or computers, but does not require Active Directory. However, it does require a Root CA, which can again be internal or external.

An important consideration when choosing the type of CA is the environment and the way in which you intend to use the certificates. If it is strictly for internal use, then your options are wide open according to your environment (for example is you have AD, then use you can use either Enterprise or Standalone CAs). If however you need certificates to secure a public website, then an external certificate authority will need to be involved, either providing the certificates for that site directly, or via a chain of trust.

Of all the many services that Windows 2000 offers, one of the least understood is probably Certificate Services. While it may seem that anything that has to do with cryptography is unnecessarily complex, understanding the main elements is certainly not difficult. Certificate Services exist for one primary purpose – to help in the creation of something referred to as a Public Key Infrastructure (PKI). The purpose of a PKI is simple – to allow data to be encrypted, to have users (or computers or services) authenticated and verified, and to have some system of trust that allows this all to work efficiently. You should also have an awareness of what certificates can be used for in Windows 2000 – in other words, why you should even care. Examples include authentication by Smart Cards, encrypting files and email messages, authenticating to web sites, authenticating computers for L2TP connections, and so forth – each of which relate to or rely on PKI in some respect. The key to understanding how a PKI works first involves understanding the two main elements that it is made up of – certificates and Certificate Authorities.

To make things easier, from now on I would suggest thinking of a certificate as being like a drivers license. For all intents and purposes, it is a piece of identification that tells something about you and can be used as proof of your identity. The most important detail about your driver’s license is that fact that it was issued by a trusted third party, more than likely a department of local government. The license bares the department logo or signature, and as such they vouch for your identity. The only reason that a drivers license works as identification is because we have established trust in the system – I believe that your license is real because it was issued by government, and also because I too carry a license which is proof of my identity. I trust the government and so do you, so the system works (whether you really think the government is trustworthy is another story). In this case, the government is acting as the trusted third party – the Certificate Authority (CA). So first and foremost, think of the certificate as something that can prove your identity, with the CA acting as the one who has actually verified that you are who you say you are.