Welcome to article number 28 in my 70-240 in 15 minutes a week series. This article covers Certificate Services in Windows 2000, and includes a look at why certificates are used, the different ways in which Certificate Services can be set up, the installation of Certificate Services, and finally integration with Group Policy. This is the last article in my 70-240 series, and again falls into the networking services portion of the exam.
The material to be covered in this article includes:
- Overview of Certificates and PKI
- Types of Certificate Authorities
- Installation of Certificate Services
- Integration with Group Policy
Overview of Certificates and PKI
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.
The manner in which certificates are used and issues is a tad more complex. Before actually obtaining a certificate, a user must first generate a pair of keys - these are what are commonly referred to as the private and public key. People always seem to be confused about how these keys are used, so I'll spend a little time on that now. Basically, if you want to be part of a PKI, you will need a private and public key pair, and a valid certificate. The way in which this happens differs slightly between systems, but the gist of things is usually the same - I'll follow the Windows 2000 way. The first step is creating the key pair, which is done by something called the Cryptographic Service Provided (CSP), basically a program running on your system, which is accessed by a programming interface called the CryptoAPI. This will result in a key pair being created, made up of both a public and private key. The private key is not meant to be shared (as I'll soon explain) and is secured by the operating system. The public key is free to go to anyone, and will need to be accessed by those looking to securely communicate with you. After the key pair has been generated, the next step is requesting a certificate, from some predefined Certificate Authority. This might be a server in your internal organization, or it might be a public CA such as Verisign. Whatever the case, you must submit a request, and that request includes information such as your name, email address, contact information, and so forth (what you need to provide depends on the CA and type of certificate). The request also includes a copy of your public key. Based on rules that have been set up by the CA, a certificate may or may not be issued to you. If it is, the file that is created contains the information that you have submitted, as well as the digital signature of the CA - proof that they choose to verify your identity. Of course, this proof is only as good as your (and other people's) trust in the CA. This is another important fact that we'll look at shortly.
The manner is which these keys and certificate are used vary by the services you wish them to provide, but the easiest example is always email. Imagine that two users, Sally and Bob, wish to send each other email. A standard email message is not encrypted and can potentially be read by others as is moves across the network or Internet. Not only that, but another user could send email to Sally pretending to be Bob, and so things get even more complex. Certificates help with this, but we need to understand a little more about private and public keys. Lets begin by taking a look at sending an encrypted message. Imagine that Bob wants to send an encrypted email to Sally. In order to do so, Bob needs a copy of Sally's public key. How he can obtain this is via email from Sally, via a download from a directory service or website, and so forth. This shouldn't be a problem, because Sally's public key has a rather limited use - the messages that it encrypts can only be decrypted by Sally's private key. In other words, Sally's public key is used by others to send encrypted messages to Sally only. Unless Sally's private key is stolen somehow, people will be unable to read encrypted messages sent to her. Getting back to our example, lets say that Sally sends Bob her public key, the next question becomes how can Bob be sure that this message is really from Sally and not someone pretended to be Sally? This too can be handled via the user certificate. When Bob receives a message digitally signed by Sally, he can verify her identity according to the CA signature on her certificate. Bob can only read this signature by the CA if he has a copy of the CA's public key. Just to know, your web browser and email client software automatically include public keys for many certificate authorities. If the CA signature checks out, and the certificate contains all of Sally's information, then you can be reasonably sure that the request did, in fact, some from Sally.
Once Bob has a copy of Sally's public key, he can then send her encrypted messages, but the reverse is not true. Until Sally also has Bob's public key, she cannot send encrypted messages to him. The only way that the system works at all is if Bob and Sally both trust the CA to prove their identities.
An important consideration when looking at public key cryptography is that the whole deal has a great deal of overhead (computationally) associated with it. For this reason, public key cryptography is often used not to encrypt all data, but instead to encrypt something referred to as a session key. In non-email applications (such as visiting a secure website), instead of encrypting all data back and forth using public and private keys, the client machine creates a session key that is used for the purpose of encrypting data by both the client and the server. This session key is passed from the client to the server using public key encryption, but from that point all data is encrypted with the session key - this is both faster and more efficient that encrypting everything using the associated public keys. Once the session is over, the session key is destroyed, and a new one will be used when another session is created.
Now that you have an overview of what the keys do, it is important to understand that certificates also expire. When they are created by a CA, certificates are also given an expiry date, again similar to a license. If the license is expired, it may still be in your pocket, but is not considered valid. The same holds true for a certificate - including the fact that the issuer may revoke the certificate. In certificate-speak, revoked certificates are published to something called the Certificate Revocation List (CRL), a list available to client systems that choose to check it. Reasons for revoking a certificate include the associated private key having been compromised, misuse, and so forth. The situations under which certificates are revoked are at the discretion of the CA.
Types of Certificate Servers
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.