Abstract
This chapter describes the Microsoft Certificate Server (MCS) and its provision of certificates for enabling secure communications for your Web sites. The author also explains how to install and implement a Certificate Authority to support server and client certificates.
In this chapter I describe the Microsoft Certificate Server (MCS) and its provision of certificates for enabling secure communications for your Web sites. I begin by defining the various types of certificates and certificate authorities, and explain how certificates are used to enable secure communications. The steps needed to install and implement a Certificate Authority are described, as well as how to use the Certificate Authority to support server and client certificates. I then discuss how to use Key Manager to generate the key pair and server certificate needed to enable secure communications. The use of the Certificate Server Administration Web site is explained, and I wrap up the chapter with a discussion of the issuance and management of client authentication certificates.
AN OVERVIEW OF CERTIFICATE SERVER
To provide improved flexibility and robustness of security for Web-based applications, Microsoft has implemented the Microsoft Certificate Server (MCS ) to manage X.509-compatible certificates.
X.509 is an ITU recommendation for digital certificates designed to be used to establish identity and enable secure communications. While not officially adopted as a standard, it has been used as the starting point for many digital certificate implementations, including Microsoft and Netscape’s certificate server products. Many sources of detailed information about X.509 are available on the World Wide Web, including the following Web sites:
The MCS is rooted in the industry-supported X.509 standards, and it generates, issues, renews, and revokes X.509 certificates used in secured communications. MCS is used in the support of SSL authentication processes for both servers and clients, securing e-mail via S/MIME (the Secure/Multipurpose Internet Mail Extensions), and securing electronic payment processing via SET (Secure Electronic Transaction).
The MCS consists of a system of interlocking subcomponents including a Certificate Server engine with support modules, Certificate Server database, and Web-based certificate enrollment, as well as administration tools and development tools and samples. MCS runs as a Windows NT service that is configured to automatically start up when the operating system loads.
Three types of certificates are provided and used by MCS:
Certificate Authority certificates provide the authority for MCS-based server and client certificates to work.
Server certificates are used to enable secured Web communications via SSL.
Client certificates can be used to validate clients and allow them to access secured Web sites that require client certificates.
UNDERSTANDING CERTIFICATES AND PUBLIC KEYS
Microsoft Certificate Server creates and manages X.509 v.3 certificates, which can be used by Web servers such as IIS or (Netscape) Enterprise Server, and clients like Microsoft Internet Explorer and Netscape Navigator. X.509 certificates are based on public key technology, also referred to as asymmetric cryptography.
Public key cryptography uses a key pair to encrypt and decrypt data. The key pair consists of a public key, which is published and can be widely distributed, and a private key, which is kept secret by the person or service owning the key pair. Messages that are encrypted with either key can only be decrypted by the other key. This means that encryption can be guaranteed in either direction with this technology. For example, if you publish your public key, anyone can encrypt a message with that key; however, only the holder of the private key will be able to decrypt the message.
IIS uses X.509 certificates and SSL to provide the following:
Authentication—X.509 certificates are used to establish the identity of the certificate holder. This can work in two directions: a client can be assured that a Web server represents the entity it purports to, and a server can verify that the client is who he says he is.
Encryption—Certificates provide a mechanism for secure communication. SSL uses public key technology to transmit session keys, guaranteeing a secure communication channel between the client and the server for a single session, after which the session key is discarded.
End to End Message Integrity—SSL provides a means of verifying the integrity of messages by creating a digest of each message. This digest is encrypted by the originating server and can be verified by the client upon receipt, in a two-step process. First, the client decrypts the digest it receives using the public key of the server, and then a new digest is created by the client. If these two digests match, the message is authenticated as unaltered in transmission.
In the next section, I define what certificate authorities are, and the types of certificates they provide.
Certificate Authorities
An agency that issues certificates is known as a certificate authority (CA). A certificate authority is essentially vouching for the validity of each entity to which it issues a certificate, whether it is another CA or an individual. Because each certificate is validated by the issuing CA, the authenticity of each certificate can be verified. Any certificates can be validated by walking a hierarchical chain of CAs ending in a known Root CA. X.509 certificates rely on this hierarchy of CAs as a means of identifying and authenticating certificates.
The Root CA, however, is a special type of Certificate Authority that is implicitly trusted. Because it’s at the top of the certificate hierarchy, there is no higher-level CA that can issue its certificate. This Root CA issues a CA certificate to itself that is used to validate all certificates issued by that CA. This CA certificate is sometimes called a self-signed certificate, because it is digitally signed (or verified) by the agency to which it is issued. For this reason, it is imperative that any Root CA certificate actually come from a known and trusted Certificate Authority.
There are two basic types of certificate authorities: public (or commercial) CAs and enterprise CAs. While the process of certificate management with the Microsoft Certificate Server is largely the same whether you use a public or enterprise CA, how they are used is very different. You should carefully consider how you intend to use certificates before installing MCS, as you will need to designate the type of Certificate Authority you want during server installation:
If you plan on using public certificates to verify your organization’s identity and provide security across the Internet, you will want to install as a non-Root CA. If you select this option, you will need to obtain a certificate from a commercial CA such as VeriSign.
If you plan on using enterprise certificates internally to enable SSL connections or to use client certificates as a sort of electronic employee ID, then you will want to install as a Root CA.
Now let’s take a closer look at the differences between these two types. Instructions on both of these installation types are provided later in this chapter in the “Using MCS as a Root (or Non-Root) CA” sections.
Public CA
The most common use of the certificates granted by a public (that is, external) CA on the Internet is probably by sites doing e-commerce. The certificate authority that is familiar to most people is probably VeriSign. The certificates issued by VeriSign are most commonly used by a site to identify itself to the public and provide secure communications during financial and other sensitive transactions. VeriSign calls the certificates they issue digital IDs.
Certificates (or digital IDs) are used to verify the identity of a Web site and provide a secure communications channel for transactions that may contain credit card or other sensitive information. Digital certificates can also be used by the news media or other sources of information to validate their identity, and therefore the integrity of the provided data.
Because VeriSign is vouching for the authenticity of an entity when it issues a digital ID, it requires that the company requesting the digital ID submit some sort of information validating its identity. If you have a Dun & Bradstreet number (DUNS), you can complete the online application and have your certificate returned to you without further documentation. If your business does not have a DUNS, you can submit one of the following types of documentation to verify your identity to VeriSign:
Business license
Federal tax ID confirmation
Articles of incorporation
Partnership agreement
Enterprise CA
On the other hand, you may not need to use certificates in the external world, and therefore will not need to incur the expense of obtaining a certificate from a public CA such as VeriSign. In this case, the enterprise is its own Root CA and issues not only the server and client certificates, but the CA certificate as well. Because this provides no external validation that the entity issuing these certificates is who they say they are, as is the case with certificates issued by a public CA, use of such certificates is generally limited to within a specific organization. However, it would not be uncommon for companies having business relationships, such as a vendor or joint venture relationships, to trust each other’s certificates. The process of recognizing the certificates issued by other enterprises is known as cross-certification.
Many organizations are using certificates as a means of creating secure communications between Web servers and clients, or issuing client certificates to verify the identity of people who are accessing their resources. Once the people who will be using the certificates issued by your enterprise CA have obtained a copy of your CA certificate, your certificates can also be used to verify that the resource being accessed is actually a valid corporate resource—which can be useful when employees access corporate data via the Internet.
Types of Certificates
The purpose of a certificate is to verify the identity (of the CA, server, or client) and to encapsulate the public key. There are three types of certificates: the CA certificates, server certificates, and client certificates. All certificates contain:
Information about the entity using the certificate
Information about the CA
Public key of the entity using the certificate
Certificate expiration date
A digest (summary) of the certificate contents signed by the CA
Now let’s look at each certificate type.
CA Certificates
CA certificates are the certificates authenticating the certificate authority (the trusted certificate source that is used to validate server and client certificates). The most common CA certificates are called Root CA certificates, which are self-signed certificates, meaning that they are not vouched for by a third party. It is very important that you be able trust the issuer of the Root CA—thus the existence of companies like VeriSign whose business is verifying the certificate requestors and issuing validated certificates.
A CA certificate is used to validate certificates issued by that CA. For other certificates to be validated, the client software (such as a Web browser) must have the CA certificate loaded. Most Web browsers come with a number of CA certificates already installed. Although additional CA certificates can be installed, this should only be done if the person adding the CA certificates is certain of the source of the certificates and is willing to trust all certificates issued by that CA.
Server Certificates
A server certificate is issued by a CA to a specific server, generally identified by the server’s DNS name. This certificate authenticates the Web server to clients and provides a means of establishing secure communications between that server and clients accessing it, via SSL.
Server certificates require that a key pair be generated in the process of creating the server certificate. This is generally done in one of two ways, depending on the software being used and the procedures of the CA. The most secure method works like this: The server keys are generated by the server, the private key is stored on the server, and the public key is submitted as part of the certificate request to the CA. If this is not possible, the issuing CA can generate the key pair and return both public and private keys to the server (separately) once the certificate is created. In this case, the issuing CA would then destroy its copy of the private key to guarantee that only the server held the private key.
Client Certificates
Client certificates are used to verify the identity of a specific person. This method can be used in many ways, ranging from internal validation at a business to digitally signed and encrypted e-mail. An individual may have multiple client certificates issued by several different CAs. For example, you could have a certificate from your employer to identify you on the corporate network, one from a Web site them uses certificates in a cookie-like fashion, and one from a public CA that you use for secure e-mail.
Client certificates are generated essentially in the same way as server certificates: a key pair is created, the private key is held by the client, and the public key is incorporated into the certificate. Many applications that support the use of certificates have mechanisms built into them, allowing generation of key pairs and management of certificates. This is typically done behind the scenes, with the password for the private key tied to an existing password used for system, network, or application logon.
It is possible to move client certificates between applications and computers, and applications such as browsers provide Import/Export options for this purpose. However, this depends on whether the application to which you are importing the certificate accepts the same form of certificate—and this is not always the case. Before you count on this functionality, it is recommended that you verify cross-application functionality of certificates issued by a specific CA. You should always password-protect certificates when exporting them from one computer or application to another.
Order Your SQL Fundamentals CD Today! Learn how to use SQL Server, understand Office integration techniques and dive into the essentials of SQL Express and Visual Basic with this free SQL Fundamentals CD.
You've Deployed SharePoint...Now What? This one-day free online conference delivers the technical knowledge needed to kick MOSS up a notch. In one information-packed day, independent SharePoint experts will present practical, real-world information and provide take-away, ready-to-use solutions
What Would You Do If You Ran Microsoft? ITTV's 2008 inaugural video contest, "If I Ran Microsoft..." is your chance to tell it like it is. Be goofy or be serious, but don"t miss this chance to have fun, win prizes, and go viral in a major way.
Maximize Your SharePoint Investment This web seminar discusses how true bi-directional replication of SharePoint content from one server to another enables branch offices to maintain access to current SharePoint content.
Windows IT Pro
Register
