Aracılığıyla paylaş

Deploying a Public Key Infrastructure

  • Makale

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Public key infrastructure

Computer networks are no longer closed systems in which a user's mere presence on the network can serve as proof of identity. In this age of information interconnection, an organization's network may consist of intranets, Internet sites, and extranets--all of which are potentially susceptible to access by unauthorized individuals who intend to maliciously view or alter an organization's digital information assets.

There are many potential opportunities for unauthorized access to information on networks. A person can attempt to monitor or alter information streams such as e-mail, electronic commerce transactions, and file transfers. Your organization may work with partners on projects of limited scope and duration, with employees whom you know nothing about, but who, nonetheless, must be given access to some of your information resources. If your users have a multitude of passwords to remember for accessing different secure systems, they may choose weak or common passwords to more easily remember them. This not only provides an intruder with a password that is easy to crack, but also one that will provide access to multiple secure systems and stored data.

How can a system administrator be sure of the identity of a person accessing information and, given that identity, control which information that person has access to? Additionally, how can a system administrator easily and securely distribute and manage identification credentials across an organization? These are issues that can be addressed with a well-planned public key infrastructure.

A public key infrastructure (PKI) is a system of digital certificates, certification authorities (CAs) and other registration authorities (RAs) that verify and authenticate the validity of each party that is involved in an electronic transaction through the use of public key cryptography. Standards for PKIs are still evolving, even as they are being widely implemented as a necessary element of electronic commerce. For detailed information about planning a PKI and using public key cryptography, see Certificates Resources on public key infrastructure.

There are a number of reasons why an organization may choose to deploy a PKI using Windows:

  • Strong security. You can have strong authentication with smart cards. You can also maintain confidentiality and the integrity of transmitted data on public networks by using Internet Protocol security and the confidentiality of stored data by using EFS (encrypting file system).

  • Simplified administration. Your organization can issue certificates and in conjunction with other technologies eliminate the use of passwords. You can revoke certificates as necessary and publish certificate revocation lists (CRLs). There is the ability to use certificates to scale trust relationships across an enterprise. You can also take advantage of Certificate Services integration with the Active Directory directory service and policy. The capability to map certificates to user accounts is also available.

  • Additional opportunities. You can exchange files and data securely over public networks, such as the Internet. You have the ability to implement secure e-mail using Secure Multipurpose Internet Mail Extensions (S/MIME) and secure Web connections using Secure Sockets Layer (SSL) or Transport Layer Security (TLS). You can also implement security enhancements to Wireless Networking.

The Windows Server 2003 family has features to help your organization implement a public key infrastructure include:

  • Certificates. A certificate is basically a digital statement issued by an authority that vouches for the identity of the certificate holder. A certificate binds a public key to the identity of the person, computer, or service who holds the corresponding private key. Certificates are used by a variety of public key security services and applications that provide authentication, data integrity and secure communications across networks such as the Internet.

    The standard certificate format used by Windows certificate-based processes is X.509v3. An X.509 certificate includes information about the person or entity to whom the certificate is issued, information about the certificate, plus optional information about the certification authority issuing the certificate. Subject information may include the entity's name, the public key, and the public-key algorithm.

    Users can manage certificates using the Certificates MMC console. For more information, see Certificates overview. Users can also allow certificate autoenrollment to manage their certificates automatically. For more information, see Planning for autoenrollment deployment.

  • Certificate Services. On Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition, Certificate Services is the component that is used to create and manage certification authorities (CAs). A CA is responsible for establishing and vouching for the identity of certificate holders. A CA also revokes certificates if they should no longer be considered valid and publishes certificate revocation lists (CRLs) to be used by certificate verifiers. The simplest PKI design has only one root CA. In practice, however, the majority of organizations deploying a PKI will use a number of CAs, organized into certification hierarchies.

    Administrators can manage Certificate Services using the Certification Authority MMC console. For more information, see Certificate Services overview.

  • Certificate templates. Certificates are issued by the CA based on information provided in the certificate request and settings contained in a certificate template. A certificate template is the set of rules and settings that are applied against incoming certificate requests. For each type of certificate that an enterprise CA can issue, a certificate template must be configured.

    Certificate templates are customizable in Windows Server 2003, Enterprise Edition and Windows Server 2003, Datacenter Edition enterprise CAs, and are stored in Active Directory for use by all CAs in the forest. This allows the administrator to choose one or more of the default templates installed with Certificate Services or to create templates that are customized for specific tasks or roles.

    Administrators can manage Certificate Templates using the Certificate Templates MMC console. For more information, see Certificate Templates.

  • Certificate autoenrollment. Autoenrollment allows the administrator to configure subjects to automatically enroll for certificates, retrieve issued certificates, and renew expiring certificates without requiring subject interaction. This requires no knowledge by the subject of any certificate operations, unless the certificate template is configured to interact with the subject or the CSP requires interaction (such as with a smart card CSP). This greatly simplifies the experience of the client with certificates and minimizes administrative tasks.

    Administrators can configure autoenrollment through configuration of Certificate Templates and CA settings. For more information see Planning for autoenrollment deployment.

  • Web enrollment pages. These are a separate component of Certificate Services. These Web pages are installed by default when you set up a CA and allow certificate requesters to submit certificate requests using a Web browser. Additionally, the CA Web pages can be installed on servers running Windows that do not have a certification authority installed. In this case, the Web pages are used to direct certificate requests to a CA that, for whatever reason, you do not want requesters to directly access. If you choose to create custom Web pages for your organization to access a CA, the Web pages provided in your operating system can be used as samples. Refer to the Microsoft Platform Software Development Kit for information about customizing Certificate Services and CA Web pages.

  • Smart card support. Windows supports logon via certificates on smart cards, as well as the use of smart cards to store certificates and private keys. They can be used for Web authentication, secure e-mail, wireless networking and other public key cryptography-related activities. For more information, see Smart Cards.

  • Public key policies. You can use Group Policy in Windows to distribute certificates to subjects automatically, establish common trusted certification authorities, as well as managing recovery policies for EFS (Encrypting File System). For more information, see Public Key Policies overview