Certificate Server

Microsoft® Certificate Server provides customizable services for issuing and managing certificates used in software security systems employing public-key cryptography.

  • For help with specific tasks, see

  • For general background information, see


Certificate Server Welcome

Welcome to Certificate Server

Microsoft® Certificate Server provides customizable services for issuing and managing certificates used in software security systems employing public-key cryptography. Certificate Server performs a central role in the management of software security systems to enable secure communications across the Internet, corporate intranets, and other nonsecure networks.

Certificate Server receives requests for new certificates over transports such as RPC, HTTP, or e-mail. It checks each request against custom or site-specific policies, sets optional properties for the certificate to be issued, and issues the certificate. Certificate Server allows administrators to add elements to a certificate revocation list (CRL), and publish a signed CRL on a regular basis. Programmable interfaces are included for developers to create support for additional transports, policies, and certificate properties and formats.

Certificate Server generates certificates in standard X.509 format. Certificates in X.509 format are commonly used to authenticate servers and clients performing secure communications using the Secure Sockets Layer (SSL) protocol. This section includes information about the following topics:(ADD LINKS)

  • Overview Of Certificates and Certificates and Authentication
  • Cryptography
  • Data Encryption
  • Digital Signatures
  • Digital Envelopes
  • Authentication
  • Digital Certificates
  • Digital Certification
  • Certificate Hierarchies
To learn more about Certficate Server features and architecture see Understanding Certificate Server. (ADD LINK)

To learn more about using Certificate Server see Using Certificate Server. (ADD LINK)


Over View of Certificates

Overview of Certificates and Authentication

Certificates are a form of digital identification used in software security systems to prove the identities of users on nonsecure networks such as the Internet. Certificates also provide the information necessary to conduct private communications and prove the origin of communications.

The term nonsecure network is used here to refer to a computer network that can be routinely accessed by users without the need to obtain access permission. Communications on such a network are subject to possible monitoring by unknown users. The potential also exists for fraudulent communications in which senders of messages falsely represent themselves.

Even private local area networks are vulnerable to determined efforts by intruders to acquire physical access to the network. Consequently, the existence of perfectly secure networks is nearly hypothetical. Nevertheless, on these secure networks a deliberate breach of privacy or misrepresentation of identity is an extraordinary occurrence. Therefore, we can conduct our network communications on them without security precautions because we can trust the other users on the network.

On a publicly accessible network such as the Internet, information may fall into the hands of users whose intentions are unknown. If the information has little or no value, then security measures may be unnecessary. If the information is valuable or confidential, then appropriate precautions should be implemented to secure the information.

This means ensuring that only individuals with whom we want to share the information can understand it, and people with whom we share the information are really the individuals chosen to share it. These two concerns are expressed by the terms privacy and authentication.

Privacy in this context depends upon the ability to prevent anyone except the intended recipient from being able to read a message ¾ even though anyone on the network might be able to intercept it.

Authentication in this context is the verification that the entity with whom you are communicating is, in fact, who you think it is ¾ even though you have no direct physical means of proof.

The need for privacy and authentication over nonsecure networks requires some form of data encryption and decryption, otherwise known as cryptography, as part of a software security system. Cryptographic protocols (a protocol is an agreed upon sequence of steps) employing certificates are designed to address these needs.


Cryptography Explanation

Cryptography

Cryptography provides a set of techniques for encrypting (scrambling) so data and messages are stored and transmitted securely. Cryptography can achieve secure communications even when the transmission medium (for example, the Internet) is not trustworthy. Cryptography can also encrypt sensitive files, so an intruder cannot understand them.

Cryptography also provides techniques for decrypting (unscrambling) encrypted data and messages to reveal the original state. Assuming the techniques are implemented properly, without knowledge of the secret cryptographic key necessary to decrypt a message, reconstruction of the original message is extremely difficult. Digital Envelope (ADD LINK), an encryption method where only a particular recipient can decrypt a message, is an important cryptography technique.

Additionally, cryptography provides a set of techniques for verification of the origin of data and messages using Digital Signatures (ADD LINK).

When using cryptography, the only part that must remain secret are the cryptographic keys, with the exception of keys known as public keys. Algorithms, key sizes, and file formats can be made public without compromising security.


Data Encryption Explanation

Data Encryption

In using data encryption, a plaintext message can be scrambled to appear like random gibberish and be difficult to unscramble without a secret key. Here the term message refers to any piece of data designated for encryption. This message can be ASCII text, a database file, or any data designated for secure transmission. Plaintext refers to data that has not been encrypted, while ciphertext refers to data that is encrypted.

After a message has been encrypted, it can be stored on nonsecure media or transmitted on a nonsecure network, and still remain secret. Later, the message can be decrypted into its original form. This process is shown in the following illustration.

ADD ART WORK

When a message is encrypted, an encryption key is used. This is analogous to a key used to lock a padlock. To decrypt the message, the corresponding decryption key must be used. It is very important to properly restrict access to the decryption key, because anyone who possesses it will be able to decrypt all messages that were encrypted with the matching encryption key.

Symmetric algorithms are the most common type of encryption algorithm. Symmetric algorithms use the same key for both encryption and decryption. In order to communicate using symmetric algorithms, both parties must share a secret key.

Public-key (asymmetric) algorithms use two different keys: a public key and a private key. The private key is kept private to the owner of the key pair, and the public key can be distributed to anyone who requests it, often through a certificate. If one key is used to encrypt a message, then the other key is required to decrypt the message.

Symmetric algorithms are much faster than public-key algorithms and are essential for encryption of large amounts of data. However, because the keys must remain secret, distribution of the keys to large numbers of people is not practical. Public-key algorithms solve this problem and can be used in conjunction with symmetric algorithms to achieve optimal performance when large amounts of data are involved.


Digital Signatures Explanation

Digital Signatures

Digital signatures can be used when a message is distributed in plaintext form, and the recipients should be able to verify that the message has not been tampered with by any unauthorized individual. Signing a message does not alter the message, it simply generates a digital signature string that is bundled with the message or transmitted separately.

Digital signatures can be generated using public-key signature algorithms where the transmitting party private key, used to generate the signature, is sent in an e-mail message. Upon receipt of the message, the recipient uses the distinct public key to validate the signature. Because only the signer's public key (received by the recepient in an earlier e-mail) can be used to validate the signature, the digital signature is proof that the message sender's identity is authentic. This process is shown in the following illustration.

ADD ARTWORK


Digital Envelopes Explanation

Digital Envelopes

Digital envelopes are used to send private messages that can only be understood by a specific recipient. The method used is identical to that described in Data Encryption (ADD LINK), with the additional provision that the message is encrypted using the recipient's public key. The message can then be decrypted only by using the recipient's private key, so only the recipient will be able to understand the message.

(ADD ART WORK)


Authentication Explanation

Authentication

An assumption has been made in the preceding sections discussing digital signatures and envelopes that the identity of the owner of the public key used to encrypt or decrypt a message is established beyond doubt. But in practice, how would recipients of a message purportedly sent by a party named "Alice", accompanied by a digital signature that can be validated with a public key purported to belong to Alice, be sure that they are really using Alice's public key? And similarly, how would the sender of a message in a digital envelope encrypted with a public key purported to belong to an intended recipient named "Bob" be sure that it is really Bob's public key?

The use of physical documents to achieve authentication in the real world has been in existence for a long time. For example, when you write a check for some purchase and the merchant asks to see your driver's license, the license is being used to increase the merchant's confidence that you are who the check indicates you are. In this case the merchant trusts that the state that issued you the license did an adequate job of verifying your identity. Another example is the use of a passport when traveling. The customs official who looks at your passport and then accepts it as proof of your identity, trusts that your government did an adequate job of identifying you before issuing you a passport. Notice that in both examples there has to be a level of trust in the certifying authority.

In order to guarantee authenticity of public keys, Microsoft® Certificate Server provides digital certificates (ADD LINK)(commonly known as certificates) as a secure method of exchanging public keys over a nonsecure network.


Digital Certificates Explanation

Digital Certificates

A certificate is a set of data that completely identifies an entity, and is issued by a Certificate Authority (CA) only after that authority has verified the entity's identity. The data set includes the public cryptographic key tendered to the entity. When the sender of a message signs the message with its private key, the recipient of the message can use the sender's public key (retrieved from the certificate either sent with the message or available elsewhere in the directory service) to verify that the sender is legitimate.

Digital certificates are virtual documents which authenticate individuals and entities on a network. The use of certificates on a network is more complex than the use of a physical document because the communicating parties most likely will not physically meet. Consequently, a method or protocol is necessary to attain a high level of trust despite the lack of physical verification. Additionally, on a nonsecure network it is much easier to intercept messages and present fictitious identities. To prevent these problems, security protocols employing the cryptographic techniques described in earlier topics make it very difficult, if not impossible, for someone to falsify a certificate and present a false identity.


Digital Certification

A primary goal of a digital certificate is to confirm that the public key contained in a certificate is the public key belonging to the person or entity to whom the certificate is issued. For example, a Certificate Authority (CA) may digitally sign a special message (known as certificate information) containing the name of a user (in this case "Alice,"), as well as her public key in such a way that anyone can verify that the certificate information message was signed by no one other than the CA. Thereby, trust in the public key designated for "Alice" is confirmed.

The typical implementation of digital certification involves a signature algorithm for signing the certificate. The process follows these steps:

  1. Alice sends a certificate request containing her name and public key to a CA.

  2. The CA creates a special message m from this request, which constitutes most of the certificate data. The CA signs the message with its private key and obtains a separate signature sig. The CA then returns the message m and the signature sig to Alice. Together, the two parts form a certificate.

  3. Alice sends the certificate to Bob which conveys trust in her public key.

  4. Bob verifies the signature sig using the CA public key. If the signature is verified, the public key designated for Alice is accepted.

As with any digital signature, anyone can verify, at any time, that the certificate was signed by the Certificate Authority (CA), without access to privileged information.

This scenario assumes that Bob knows the specific CA public key. The public key could be obtained from a copy of the CA certificate, which contains the public key.

Since certificates have a valid time duration, it is possible for the certificate to expire and no longer be valid. A certificate is valid only for the period of time specified by the CA that issued the certificate. The certificate contains information about the beginning and expiration dates. If a user attempts to obtain access to a secured server by using an expired certificate, server authentication software will automatically reject the access request. Users can renew certificates before the expiration date to avoid this situation.

It is also possible for certificates to be revoked by the CA for other reasons. To handle this situation, the CA maintains a list of revoked certificates. This list is called a certificate revocation list (CRL), and is available to network users to determine validity of any given certificate.


CA Hierarchies

Certificate Authority Hierarchies

Within large organizations that are composed of small, multiple units, the need for each unit to manage their own resources on the corporate intranet is commonplace. Each unit must enforce the policies under which approval is granted to requesters to gain access to their intranet resources.

Providing these units the ability to set policies and issue certificates themselves can be accomplished by allowing them to become certifying authorities, each with their own Certificate Authority (CA) server. Proliferation of multiple CAs within an intranet should be monitored closely by the parent organization so no misuse of authority occurs.

Misuse of authority is addressed through use of a Certificate Authority (CA) hierarchy. The CA hierarchy begins with an ultimate certifying authority called root. The root authority certifies CA servers within the parent organization to enforce security and control throughout the entire system. In large organizations, there may be multiple tiers of CA servers so the hierarchy can be deployed throughout all the units in the parent organization. For example, a first-tier CA would be certified by the root CA, and would then certify a second-tier CA, as shown in the following diagram.

ADD ART WORK

The use of a CA hierarchy provides large organizations with the flexibility needed to manage policies and grant certificates throughout a certification system composed of multiple certificate authorities. A CA hierarchy enables a certification system to be managed from a single control point. For example, the root authority could employ hardware-based key management so a specific, subordinate CA is certified under the greatest possible security.

When a certificate issued by a Tier-1 or Tier-2 CA is transmitted on a network, the recipient must verify that the issuing CA has been certified by the level above it, and that the one at that level has been certified by the one above it, until a chain of authority exists between the lower-level CA and the Root CA. For example, in the preceding diagram, it could be verified that CA #4 was certified by CA #1 and that CA #1 was certified by Root CA.

If for some reason a lower-level CA mismanages the issuance of certificates, the relevant server certificate can be revoked by the root authority. This effectively invalidates certificates issued by the lower-level CA without affecting any other certificates issued within the parent organization.


Understanding Certificate Server

This section includes information about the following topics:(ADD LINKS)

  • Application Scenarios
  • Interoperability
  • Certificate Server Features
  • Certificate Server Architecture
  • Processing Certificate Requests
  • Certificate Enrollment
  • Administering Certificate Server


Certificate Server Application Scenarios

Microsoft® Certificate Server is designed for web-based applications that require authentication and secure communications based on the Secure Sockets Layer (SSL) protocol. It can also support other certificate-based applications such as secure e-mail like Secure/Multipurpose Internet Mail Extensions (S/MIME), secure payment such as Secure Electronic Extensions (SET), and digital signatures like Microsoft Authenticode™. In the case of SSL, an organization can use the certificate server to issue both server and client certificates in a standard X.509 version 3.0 format. The organization may elect to issue all certificates from a single certificate server or use multiple certificate servers that are chained together in a Certificate Authority (CA) hierarchy.

At the most basic level, the role of Certificate Server is to receive a PKCS #10 certificate request, verify the information in the request and issue a corresponding X.509 certificate (or, possibly, certificate chain) in a PKCS #7 format. In the case of a user who wants to obtain a certificate for a web browser, a certificate request is typically generated by visiting a web site and enrolling for a certificate. To enroll, the user enters identifying information (for example, name, address, e-mail) into an HTML form, a key pair is generated and the public key is sent in a PKCS #10 to the CA. If all identifying information meets the CA criteria for granting a request, the Certificate Server generates the certificate which is downloaded to the user's browser.

TBA


Scenarios - Partner Orgs

Inter-networking with Partner Organizations

Microsoft® Certificate Server can be used to grant certificates to end-users within an organization so they can conduct secure communications across the Internet and gain access to the corporate intranet. Two examples:

  1. Branch offices. The Internet supplements or serves as a corporate WAN.

  2. Supplier/vendor relationships. Intranet access is granted to groups of users from key partners.

The Certificate Authority (CA) issuing the certificates can implement policies tailored to each specific case. An example of such a policy would include the following:

  • Use authenticated RPC to receive certificate requests and transmit completed certificates.

  • Check that the Issuer Organization and Issuer Organizational Unit information specified in certificate requests correctly identifies the CA server's organization (specified in the CA server's configuration file).

  • Check that the Subject Common Name information specified in certificate requests matches the authenticated user name.


Scenario - Inter In LORGS

Inter-Networking in Large Organizations

The following examples show situations where Microsoft® Certificate Server typically grants certificates to users within an organization so they can conduct secure communications across the Internet and gain access to the corporate intranet.

  • Branch offices where the Internet supplements or serves as a corporate WAN.

  • Supplier or vendor relationship where intranet access is granted to groups of users from key partners.

The Certificate Authority (CA) issuing the certificates can implement policies tailored to each specific case. An example of such a policy would include the following:

  • Use authenticated RPC to receive certificate requests and transmit completed certificates.

  • Check that the Issuer Organization and Issuer Organizational Unit information specified in certificate requests correctly identifies the CA server organization (specified in the CA server configuration file).

  • Check that the Subject Common Name information specified in certificate requests matches the authenticated user name.


Scenario - Customer Registration

Customer Registration

Microsoft® Certificate Server can be used to grant certificates to end-users within an organization so they can conduct secure communications across the Internet and gain access to the corporate intranet. Two examples:

  1. Branch offices. The Internet supplements or serves as a corporate WAN.

  2. Supplier/vendor relationships. Intranet access is granted to groups of users from key partners.

The Certificate Authority (CA) issuing the certificates can implement policies tailored to each specific case. An example of such a policy would include the following:

  • Use authenticated RPC to receive certificate requests and transmit completed certificates.

  • Check that the Issuer Organization and Issuer Organizational Unit information specified in certificate requests correctly identifies the CA server's organization (specified in the CA server's configuration file).

  • Check that the Subject Common Name information specified in certificate requests matches the authenticated user name.


Interoperability Intro

Interoperability

By using industry-standard certificate formats and open interfaces, Microsoft® Certificate Server is interoperable with many products and technologies that support the use of digital certificates. The following are examples of products and technologies that support digital certificates.

Web Servers

On a corporate intranet or on the Internet, servers such as Microsoft® Internet Information Server (IIS) can perform client authentication for secure communications using certificates generated by Microsoft Certificate Server. Certificate Server can also generate server certificates used by IIS and other Web servers to provide server authentication to assure clients that they are communicating with the intended entity.

Web Browsers

Microsoft® Certificate Server can be used to issue certificates to browsers which support client authentication, such as Microsoft Internet Explorer version 3.0 or later, or Netscape Navigator 3.0. Internet Explorer can install server certificates for Microsoft Internet Information Server (IIS) and other Web servers used for server authentication such as Netscape Enterprise Server. Internet Explorer also uses certificates for client authentication on servers that the user wants to access. You can view and examine the details of certificates that are installed in Internet Explorer.

LDAP Directories

Microsoft® Certificate Server's programmability makes it possible to issue certificates to any directory compliant with Lightweight Directory Access Protocol (LDAP). LDAP is an easily implemented subset of the X.500 DAP standard for directory services. LDAP has strong industry support and is expected to become an industry standard for directory services. Certificate Server compliance with LDAP implies it can interoperate with policy tools and other third-party applications that support LDAP directory services.

Microsoft Internet Security Framework

Microsoft® Certificate Server is part of the Microsoft Internet Security Framework (ISF), which is an integral part of the Microsoft Windows® security model. The integration of ISF on the Microsoft Windows NT® platform allows certificates to be mapped to Windows NT users and groups. Network administrators can then use standard Windows NT administrative tools, such as access control lists, to handle Internet and intranet security matters. Windows NT users benefit from the convenience of a single logon to access organization resources on the corporate network, corporate intranet, or the Internet.

Microsoft Exchange Server

Microsoft® Exchange Server 4.0 and 5.0 include Key Management Server (KMS), a combination certificate-issuing server and key-recovery server. KMS allows Microsoft Exchange users to send digitally-signed and encrypted mail to other Microsoft Exchange users. In a future release of Microsoft Exchange Server, all certificate-issuing functions of KMS will be replaced by Microsoft Certificate Server. This will allow Microsoft Exchange to take advantage of the flexible, standards-based capabilities of Microsoft Certificate Server. The KMS will continue to provide private-key recovery services. This will enable users and administrators to recover encrypted e-mail data in the event the user's private keys are lost or the user leaves the company.


Features

Certificate Server Features

Microsoft® Certificate Server allows an organization to manage the issuing, renewal and revocation of certificates. It has a number of features which make it valuable to organizations that do not choose to rely upon external certificate authorities and who need a flexible tool that can be adapted to the needs of the organization.

Policy Independence and Flexibility

Certificates are granted according to policies that define criteria that requesters must meet in order to receive a certificate. For example, one policy may be to grant commercial certificates only if applicants present their identification in person. Another policy may grant credentials based on e-mail requests. An agency that issues credit cards may choose to consult a database and make phone inquiries before issuing a card. Policies are implemented in policy modules written in Java, Microsoft® Visual Basic®, or Microsoft C/C++. Microsoft Certificate Server functions are isolated from any changes in policy that an agency might implement. Changes in policy can be fully implemented in the server policy module code.

Transport Independence

Certificates can be requested and distributed through any transport mechanism. Microsoft® Certificate Server accepts certificate requests from an applicant through HTTP, RPC, disk file, or by custom transport. Certificate Server posts certificates to the applicant through HTTP, RPC, disk file, or custom transport. Transports are supported by intermediary applications and exit module DLLs, usually written in Microsoft C/C++. The intermediary applications and exit modules isolate the Certificate Server functions from communicating with any specific transport.

Standards Based Implementation

Microsoft® Certificate Server accepts standard PKCS #10 requests and issues X.509 version 3.0 certificates. Other certificate formats can be supported by modules called extension handlers (ADD LINK). Certificate Server works with non-Microsoft clients and browsers, and non-Microsoft Web servers. Certificate Server can write certificates to any database or directory service supported by a custom exit module.

Secure Key Mangement

The security of a certification system depends on how the private keys are protected. The design of Microsoft® Certificate Server ensures that it cannot be misused by an individual to perform unauthorized access of private key information. Because key management in Certificate Server is performed by Microsoft CryptoAPI (ADD LINK TO CRYPTO API SECTION), Certificate Server is isolated from these confidential pieces of data. Also, the CryptoAPI functions can employ the services of anything from software modules to hardware-based key engines for the generation and protection of keys. This allows organizations using Certificate Server to select the appropriate key-management system strength for the organization.

Scalability

Microsoft® Certificate Server is a cornerstone for implementing public-key cryptography-based security on corporate intranets and other forms of enterprise-wide networks, as well as on the Internet. Using Certificate Server, it is easier to support large numbers of users since there is no need to distribute password databases. Certificate Server can be deployed on multiple servers in large organizations that need the flexibility of more than one Certificate Authority.


Certificate Server Architecture Intro

Certificate Server Architecture

Microsoft® Certificate Server consists of the Server Engine (ADD LINK) that handles certificate requests, and other modules that communicate with the Server Engine to perform tasks. (ADD ART WORK LINK) The preceding diagram illustrates the flow of information between the Certificate Server and other components. These components include the Server Engine (ADD LINK), server database (ADD LINK), an external intermediary application (ADD LINK), one or more exit modules (ADD LINK), a policy module (ADD LINK), utility programs (ADD LINK?), and optional extension handlers (ADD LINK).


Server Engine Explanation

Server Engine

The Server Engine is the core component of Microsoft® Certificate Server. The engine acts as a broker for all requests it receives, driving the flow of information between components during the processing of a request and generation of a certificate. At each processing stage, the engine interacts with the various modules to ensure appropriate action is taken based on the state of the request.


Server Database Explanation

Server Database

Certificate Server includes a Server Database that maintains status information and a log of all issued certificates and certificate revocation lists (CRLs). The database is composed of two parts, the Server Log and the Server Queue.

The Server Log stores all certificates and CRLs issued by the server so administrators can track, audit and archive server activity using the MMC Administration (ADD LINK) tool. In addition, the Server Log is used by the Server Engine (ADD LINK)to store pending revocations prior to publishing them in the CRL. The Server Log also stores recent certificate requests for a configurable period of time in case a problem is encountered when issuing a certificate (for example, a delivery failure). The Certificate Log Utility provides administrative access to this part of the Certificate Server database.

The Server Queue maintains status information (receipt, parsing, authorization, signing, dispatch) as a certificate request is being processed by the server. The Certificate Queue Utility provides administrative access to this part of the Certificate Server database.


Policy Module Explanation

Policy Module

The Policy Module contains the set of rules governing issuance of certificates. All requests received by the Server Engine (ADD LINK) are passed to the Policy Module for validation. Policy modules are also used to parse any supplemental information provided within a request and set properties on the certificate accordingly.

The Policy Module is fully replaceable and customizable through an Automation interface to the Server Engine.


Extension Handler Explanation

Extension Handlers

Extension handlers work in tandem with the Policy Module (ADD LINK) to set custom extensions on a certificate. Each extension handler acts as a template for the custom extensions that should appear in a certificate. The appropriate extension handler must be loaded by the Policy Module when needed. Extension handlers can also be loaded by an exit module and used to decode custom extensions in a certificate.


Exit Modules Explanation

Exit Modules

Exit Modules publish completed certificates through any number of transports or protocols. By default, the server notifies each exit module installed on the server whenever a certificate is published.

A Component Object Model (COM) interface for writing custom exit modules for different transports/protocols or custom delivery options is provided with Microsoft® Certificate Server. For example, an LDAP exit module might be used to publish only client certificates in a Directory Service and not server certificates. In this case, the exit module can use the COM interface to determine the type of certificate that the server is issuing and filter out any that are not client certificates.


Certificate Repository

TBD


Processing Certificate Requests

How Certificate Server Processes Certificate Requests

Microsoft® Certificate Server performs the following steps when processing a certificate request:
  1. Request reception. The certificate request is sent by the client to an intermediary application, which formats it into a PKCS #10 format request and submits it to the (ADD LINK)Server Engine.

  2. Request approval. The Server Engine calls the Policy Module (ADD LINK), which queries request properties, decides whether the request is authorized or not, and sets optional certificate properties.

  3. Certificate formation. If the request is approved, the Server Engine takes the request, and any properties requested by the Policy Module, and builds a complete certificate.

  4. Certificate publication. The Server Engine stores the completed certificate in the certificate store and notifies the intermediary application of the request status. If the exit module (ADD LINK) has so requested, the Server Engine will notify it of a certificate issuance event. This allows the exit module to perform further operations such as publishing the certificate to a directory service. Meanwhile, the intermediary gets the published certificate from the certificate store and passes it back to the client.

The following diagram illustrates how a certificate request is processed by Certificate Server:

(ADD ART WORK)


Certificate Enrollment

As illustrated in the following diagram, HTTP-based enrollment is handled by Microsoft® Internet Information Server (IIS). The enrollment code on the IIS server can be configured to talk to multiple Certificate Servers by supplying the name of a specific Certificate Server in the call to the Server Engine. For example, an organization might use a separate Certificate Authority (CA) for each division to provide flexibility over policies and key management. If this is the case, the enrollment code would then supply the name of the Certificate Server for the user's division when making the call to the Server Engine.

The IIS server has a series of HTML forms that allow the user to request certificate types if applicable and any identifying information that the CA needs in order to validate the request and generate the certificate.


Administering Certificate Server Overview

TBD


Resources Page

Resources

TBD


Using Certificate Server Intro

Using Certificate Server

This section includes information about the following topics:(ADD LINKS)
  • Installing Certificate Server
  • Administering Certificate Server Using Certificate Server Manager
  • Administration Using Windows NT Event Viewer
  • Using Certificate Server Command Line Functions
  • Troubleshooting


Installing and Configuring Certificate Server Intro

Installing and Configuring Certificate Server

Although Certificate Server is an NT Service and is included with NT5 Server software, is not installed as part of the initial NT5 Server installation process. To install Certificate Server, you must select it from within the Control Panel using the Add/Remove Program function. After you select Certificate Server for installation, the Certificate Server Installation Wizard will guide you through the installation process. The following topics provide background information to help you configure Certficate Server during the installation process.

Certificate Types

Using Certificate Server, you can set up any of the following types of Certificate Authority.

Enterprise Root CA

The Enterprise Root CA (Root CA) will usually be the primary certifying authority on your enterprise network and will be the top level certifying authority in a CA Hierarchy. The Root CA requires the Directory Service. It self signs its own CA certificate, and issues that certificate to authenticate other CAs in your enterprise. Because Root CA certificates authenticate other CAs in the enterprise, the Root CA should be installed before other CAs on the network should not issue certificates directly to end users.

For more background information about Certification Hierarchies see (ADD LINK TO CERT HIER CONCEPTS). For more information about implementing a Certification Hierarchy see

(ADD LINK TO BEST PRACTICES CERT HIER)

Enterprise Subordinate CA

The Enterprise Subordinate CA is a network CA that must obtain its authenticating Certificate from another CA. Usually, the Enterprise Subordinate CA is used to issue Certificates to users or machines in an enterprise. This CA requires the Directory Service.

Stand-alone Root CA

The Stand-alone Root CA is a Root CA which is not a member of a domain and thus does not require the Directory Service. Like an Enterprise Root CA, the Stand-alone Root CA self-signs its own CA Certificate and issues it to authenticate other CAs. The Stand-alone Root CA is usually the most trusted CA in a CA hierarchy BECAUSE ??????? and, like the Enterprise Root CA, should not be used to issue Certificates directly to end-users.

Stand-alone Subordinate CA

The Stand-alone Subordinate CA

CA Identifying Information

Database and Configuration Storage

Cryptographic Service Providers


DN Fields Guidelines

Guidelines for Distinguished Name Fields

A certificate request contains information that should uniquely identify the individual making the request.

PKCS #10 format certificate requests that are accepted by Microsoft® Certificate Server contain identification fields that are referred to as Distinguished Name (DN) fields. These fields will contain the information that is input by the user when a certificate request is being created by Key Manager or some other means.

The following are some guidelines for completion of DN fields in a certificate request:

Field | Description
Common Name | In the Common Name field you should enter the fully qualified hostname/path used in DNS lookups that the server will be running on (for example, hostname.thecompany.com).
Organization | The Organization Name you specify should be the legal name for your organization. that is registered with the appropriate state, country or city authority. The legal name of the organization must be used in the Organization field.
Organizational Unit | The Organizational Unit field can be used to differentiate between different divisions within an organization, for example "Internet Security Unit" or "Human Resources." This field is also recommended to be used for specifying a DBA (Doing Business As...) value.
Locality | The Locality field denotes the city that the organization resides in. If the organization has local standing only, by virtue of having a business license registered with the City Clerk for the City of Cambridge in the State of Massachusetts, then the Locality field must contain Cambridge.
State or Province | The State or Province field specifies where the organization is physically located. If your organization is incorporated in Delaware but has a DBA (Doing Business As...) within California, use California. The State or Province field should not be an abbreviated field. For example, "CA" is not a valid state name. "California" is the proper state name.
Country | The X.500 Naming Scheme standard requires a 2-character country code. The country code for the United States is US; the code for Canada is CA.

ADD SECTION ON ALPHANUMERIC CHARACTERS


Using the Microsoft Management Console to Administer Certificate Server

Welcome to the Certificate Server Microsoft Management Console Snap-in

The Microsoft Management Console (MMC) provides a single program to manage all hardware, software, and network components of your windows NT system. Programs called snap-ins form the basic administrative components of every console. For more information about MMC generally, see (ADD LINK TO MMC INTRO FILE)

Using the Certificate Server Administration Snap-in you can operate the server, configure and maintain Certificate Authorities and manage the issuance and revocation of certificates.

This section includes information about the following topics:

  • Overview of the Certificate Server Snap-in console functions. (ADD LINKS)
  • Installing the Certificate Server Snap-in.(ADD LINKS)
  • Service Administration (ADD LINK) including configuring and operating the server and Certificate Authorities.
  • Certificate Administration (ADD LINK) including managing certificate requests and issued certificates.


Overview of Certificate Administration Console

Overview of the Certificate Administration Console

Like all MMC snap-ins, the Certificate Administration Snap-in consists of a left pane defining the scope of a particular administrative action and a right pane displaying the result of that action. The scope pane of the Certificate Administration Snap-in defines the components of the certificate server which can be administered. These components are the server itself, the CAs associated with the server, and the sub-components of each CA.

The following topic provides information about administering these components.

  • Service Administration

In addition to administering the server, you can also perform Certificate Administration using the Snap-in. The following topic provides information about administering certificates with the Certificate Administration Snap-in.

  • Certificate Administration


Installing the Cert Man Snap-in

Installing the Certificate Manager Snap-in

TBD


Service Admin intro

Service Administration

Administering the Certificate Server service includes the following tasks:

  • Starting and Stopping the Service (ADD LINK)
  • Configuring Policy and Exit Modules(ADD LINK)
  • Publishing Information about a Certificate Authority to the DS(ADD LINK)
  • Integrating the CA Into the NT5 Domain Trust Model(ADD LINK)
  • Installing Certificates(ADD LINK)
  • Renewing Certificates(ADD LINK)
  • Removing Certificate Authorities(ADD LINK)
  • Managing and Publishing Certificate Revokation Lists(ADD LINK)
  • Backing Up and Restoring a Certificate Authority(ADD LINK)
  • Setting Permissions(ADD LINK)


Service Admin- Starting and Stopping the Service

Starting and Stopping the Service

Certificate Server is an NT Service. Using the MMC Administration tool, you can start and stop the service from the MMC Toolbar or the CA icon in the left pane. For detailed procedures see How to Start and Stop the Service. (ADD LINK)


Service Admin - Publishing to DS

Publishing Information about a Certificate Authority to the DS

Installation Processing

Post Installation Processing


Service Admin - Configuring Policy Modules

Configuring Policy and Exit Modules

The MMC Administration tool makes it easy to work with CA policy and exit modules. Both the policy module and the exit module may be customized using the CA Properties status page accessed from MMC.

Certificate Server includes default policy and exit modules. Samples can be accessed by (WHERE CAN THE SAMPLES BE ACCESSED) One active Policy Module and only one Policy Module may be active at a time. The default Policy Module is installed when during the Certificate Server Installation process. An Exit Module is not required to operate Certificate Server, but only one Exit Module may be active at a time.

To learn how to add, remove or customize a Policy Module, see (ADD LINK)

To learn how to add remove or customize an Exit Module, see (ADD LINK

To learn more about Policy and Exit Modules, see

(ADD LINK)


Best Practices: Hierarchies

Establishing a Certification Hierarchy

PCAs

When implementing a Certification Hierarchy (ADD LINK) using Certificate Server, establishing a top level PCA which certifiies the issuing (or intermediate) CAs can enhance your ability to respond to potential problems resulting from the compromise of an issuing CA's keys. The PCA should be a member of the top level domain in the domain hierarchy, the PCA should only be used to issue Certificates to issuing CAs and the PCA should not be used to issue end-entity Certificates. In addition, you should set the following attributes for the PCA:

  • For RSA algorithms, use a key size of 2048 bits.
  • Use a default self-signed Certificate validity period of 10 years.
  • Operate the PCA off-line and use a high level of physical security to protect it: this reduces the probability that your keys will be compromised.
  • Apply the following attributes to the PCA Certificate:
    • Key Usage (OID 2.5.29.15) - keyCertSign and cRLSign
    • BasicConstraints (OID 2.5.29.10) - set maximum depth at 4.
    • CertificatePolicies (OID 2.5.29.32) - optional.
    • AuthorityInfoAccessSyntax (OID 1.3.6.15.5.7.1.2) - location of parent Certification if certified by another PCA
    • AuthorityKey Identifier (OID 2.5.29.1) - serial number and Issuer name if certified by another PCA.
    • CRLDistribution Points (OID 2.5.29.31) - appropriate LDAP path for CRLs issued by the parent if certified by another PCA.

Issuing CAs

When certifying an issuing CA, the PCA should use a minimum RSA key length of 1024 bits and the validity period of the issuing CA Certificate should default to 5 years but be user selectable. In addition, the PCA should encode the following extensions in the issuing CA's certificate.

  • KeyUsage (OID 2.5.29.15) - keyCertSign and cRL Sign.
  • ExtKeyUsageSyntax (OID 2.5.29.37) - set as desired for CA Policy.
  • BasicConstraints (OID 2.5.29.10) - set maximum depth of 4.
  • CertificatePolicies (OID 2.5.29.32) - optional.
  • AuthorityInfoAccessSyntax (OID 1.3.6.15.5.7.1.2) - location of PCA Certificate in the DS
    • AuthorityKeyIdentifier (OID 2.5.29.1) - serial number and Issuer name of PCA.
  • CRLDistribution Points (OID 2.5.29.31) - appropriate LDAP path in the DS for the PCA's CRL distribution point.

Note

  • See Extended Key Usage Syntax (ADD LINK) for current public and private defined usages.


Service Admin - Integrating to Trust Model

Integrating the CA Into the NT5 Domain Trust Model


Serv Admin - Installing Certs

Installing Certificates


Service Admin - Renew Certs

Renewing Certificates


Service Admin - Removing CAs

Removing Certificate Authorities


Serv Admin - CRLS

Managing and Publishing Certificate Revokation Lists

Using the Certificate Server Administration Snap-in, you can manage the CRL publication schedule, the publication location and the content of the CRL.

CRL Publication Schedule

By default, the CRLs are published once a week based upon the current machine time and starting from the date when the certificate server is first installed. The default publishing schedule may be changed from MMC by accessing the CRL Publishing Properties page. To learn how to change the CRL publishing schedule, see (ADD LINK)

CRL File Name and Publishing Location

CRL files may be published to a default location, to the Active Directory and to a URL for retrieval using HTTP. You can also manually publish a particular CRL on demand using the CRL Publishing Wizard.

By default, the CRL file is published to %systemroot%/system32/certsrv/certenroll. The default file name format is "cyymmddn.crl where yy, mm, and dd are the current year month and day corresponding to the date of publication. N denotes the order that files were published in if multiple files were published on the same date.

CRL files may also be published to the Active Directory as a DS object with designated attributes using the CRL Properties Page accessed from MMC. You can also use default Active Directory settings INSTALLED HOW ???

Note

  • The default setting is not to publish to the Active Directory. However, once the directory location is specified, the directory location becomes the default publishing location.

To learn how to publish a CRL to the Active Directory and designate attributes, see (ADD HOW TO LINK) To learn more about DS objects, attributes and the Active Directory, see (ADD LINK)

If you want CRLs to be accessed via HTTP, you can publish CRLs to a designated URL. You can specify the CRL file and URL using the CRL Publishing Properties page from MMC.

Note

  • There are no default settings supplied with the Certificate Server Administration Snap-in and the default setting is not to publish to a URL. However, once a URL is specified, this becomes the default publishing location.
To learn how to publish CRLs to a designated URL, see (ADD HOW TO LINK)

You can also publish a particular CRL on demand using the CRL Publishing Wizard. The publishing parameters you select using the CRL Wizard do not modify the permanent selections you made in the CRL Publishing Properties page and will only be applied once to the particular CRL you select. If you wish to manually publish the same CRL again, you must select it again and launch the CRL Wizard.

To learn how to publish a CRL on demand see, (ADD HOW TO LINK)

To learn more about CRLs see, (ADD LINK)


Serv Admin - Backup & Restore

Backing Up and Restoring a Certificate Authority

This function has not been implemented for this release.


Certificate Administration INtro

Certificate Administration

This section includes information about the following topics:

  • Displaying Revoked, Issued and Pending Certificates
    • (ADD LINKS)
  • Selecting the Certificate Log View.
  • Processing Certificates.


Administering Cert. Serv. With NT Event Viewer

Using NT Event Viewer to Administer Certificate Viewer

Microsoft® Windows NT® Event Viewer can be used to monitor certain activities of Microsoft Certificate Server. At this time, Event Viewer can be used to log issued certificates and denied requests processed by the Certificate Authority service.

To view events generated by the Certificate Authority service using Event Viewer
  1. In Windows NT, click the Start button, point to Programs, then point to Administration Tools, and click on Event Viewer. This runs the Event Viewer application. Another way to view events is to start the Microsoft Management Console and click on the Event Viewer icon on the toolbar.

  2. In the Event Viewer Log menu, click Application if it is not already selected.

The Event Viewer will now display the Event Viewer Application Log. Events generated by the Certificate Authority service will appear with the Source name "CertSvc."

To see the details of a Certificate Authority service event, double-click an event in the Event Viewer display.

Click Previous or Next to view details of the previous or next event, respectively. Click Close to return to the Application Log display.

The Event Viewer does not dynamically update the display of the Application Log when new events occur. To display new events, click Refresh on the Event Viewer View menu.


Command Line Summary Intro

Using Certificate Server Command Line Functions

This section includes information about the following command line functions:

  • CertHier

  • CertReq

  • CertSrv

  • CertUtil


CertHier

TBD


Command LIne CertReq

CertReq

CertReq

CertReq.exe is used to submit certificate requests to Certificate Server. CertReq command usage is as follows:

CertReq [-config ConfigString] [-attrib AttributeString] [RequestFile CertFile]
[CertChainFile]
Result: Submits the certificate request file specified by RequestFile to Certificate Server. CertReq will prompt the user for the request and certificate file names if the RequestFile and CertFile parameters are not given in the command line. If the request is accepted the certificate will be written to the file specified by CertFile. The following is a valid example:

certreq -attrib "attribname1:attribvalue1\nattribname2:37"
 ReqFile.req CertFile.crt

CertReq [-keygen -attrib AttributeString] KeyGenFile CertFile
[CertChainFile]
Result: Submits the KeyGen input file specified by KeyGenFile to Certificate Server. A KeyGen input file must have an attribute string containing a challenge string matching the challenge string in the KeyGen request, and the subject name. The following example sets a challenge string = "test":

certreq -keygen -attrib "challenge:test\ncn=Your Name" KeyGenFile.req
CertFile.crt

If the request is accepted the certificate will be written to the file specified by CertFile.

CertReq [-config ConfigString] -retrieve [RequestId CertFile] [CertChainFile]
Result: Resubmits the pending certificate request specified by RequestId to Certificate Server. If the request is accepted the certificate will be written to the file specified by CertFile.

The CertReq command options are as follows:

-attrib AttributeString | Sets the named attribute specified by AttributeString in the certificate request. The literal string "\n" separates multiple attributes. See example in CertReq command usage.
-config ConfigString | Causes the request to be processed using the Certificate Authority (CA) identified in the configuration string specified by ConfigString. Without this option, the default CA will process the request.
-? | Displays the command options.

The CertReq parameters are as follows:

KeyGenFile | Base64-encoded KeyGen input file name containing the raw request.
RequestFile | Base64-encoded PKCS10 input file containing the raw request. CertReq will prompt the user for the input file name if it is not provided in the command line.
CertFile | Base64-encoded X.509 certificate output file name. CertFile must be used when RequestFile is specified.
CertChainFile | Optional parameter specifying a Base64-encoded PKCS7 output file that will contain the CA certificate and the issued certificate.

For further explanation of how to use CertReq, see Requesting Certificates with CertReq.


CertSrv Command Line

CertSrv

CertSrv.exe is the Server Engine program that is executed when the Certificate Authority service runs. In ordinary use, CertSrv should be started as a service automatically or manually through use of the Services applet in the Control Panel. It can also be started manually as a service using the following syntax:

net start "Certificate Authority"

Or use the short name for the Certificate Authority service as shown here:

net start CertSvc

For troubleshooting purposes only it may be desirable to run CertSrv as a stand-alone application in a Command Prompt window. When CertSrv is running in the diagnostics mode it displays a log of its actions in the console window.

certsrv -z

where the command line option is as follows:

-z Runs CertSrv as a stand-alone application in a diagnostics mode for troubleshooting purposes only. If CertSrv is started from the command line without the -z option, there will be a delay and then the server will run in the diagnostics mode.

For more information about running CertSrv, see Running Certificate Server and Troubleshooting Server Issues.


CertUtil Command Line

CertUtil

CertUtil.exe is used for many purposes. It can:

  • Dump Certificate Server configuration information or a KeyGen file

  • Get the Certificate Authority (CA) configuration string

  • Retrieve the CA signing and key exchange certificates

  • Revoke certificates

  • Publish or retrieve a certificate revocation list (CRL)

  • Determine if a certificate is valid or if the encoding length is incompatible with old enrollment controls.

  • Verify one level of a certificate chain

  • Resubmit or deny pending requests

  • Set attributes or an integer or string value extension for a pending request

  • Verify a public/private key set

  • Decode hexadecimal- or Base64-encoded files

  • Encode files to Base64

CertUtil command usage is as follows:

CertUtil [options] -dump
Result: Dumps the Certificate Authority's configuration information.

CertUtil [options] -getconfig
Result: Gets the default configuration string for the Certificate Authority and displays it.

CertUtil [options] -keygen KeyGenFile
Result: Dumps the KeyGen file specified by KeyGenFile.

CertUtil [options] -decodehex InFile OutFile
Result: Decodes the hexadecimal-encoded file specified by InFile and writes the result to OutFile.

CertUtil [options] -decode InFile OutFile
Result: Decodes the Base64-encode file specified by InFile and writes the result to OutFile.

CertUtil [options] -encode InFile OutFile
Result: Encodes the file specified by InFile to Base64 and writes the result to OutFile.

CertUtil [options] [-config ConfigString] -deny RequestId
Result: Denies the pending certificate request specified by RequestId. RequestId must be in decimal format.

CertUtil [options] [-config ConfigString] -resubmit RequestId
Result: Resubmits the pending certificate request specified by RequestId. RequestId must be in decimal format.

CertUtil [options] [-config ConfigString] -revoke SerialNumber
Result: Revokes the certificate specified by SerialNumber. SerialNumber must be in hexadecimal format with an even number of digits. A single "0" may be prepended to a value with an odd number of digits.

CertUtil [options] [-config ConfigString] -CRL [OutFile | -]
Result: Publishes the current certificate revocation list (CRL.) Optionally the CRL is written to the file specified by OutFile, or to the Default Web Location if "-" is specifed. The expiration date is set to be one day and one hour from the time of publication to facilitate a daily publishing schedule.

CertUtil [options] [-config ConfigString] -GetCRL OutFile
Result: Retrieves the most recently published CRL and writes it to the file specified by OutFile.

CertUtil [options] [-config ConfigString] -isvalid SerialNumber
Result: Checks the certificate specified by SerialNumber to determine if it is valid. SerialNumber must be in hexadecimal format with an even number of digits. A single "0" may be prepended to a value with an odd number of digits.

CertUtil [options] [-config ConfigString] -setattributes RequestId
AttributeString
Result: Sets the named attributes specified by AttributeString in the certificate request specified by RequestId. The following is a valid example:

certutil -setattributes 123 "attribname1:attribvalue1\nattribname2:37"

CertUtil [options] [-config ConfigString] -setextension RequestId
ExtensionName Flags Value
Result: Sets the extension specified by ExtensionName in the certificate request specified by RequestId. RequestId must be in decimal format. Flags must be set to 0 or 1, 1 makes the extension "critical". Value must be a string and will be interpreted as a long integer in decimal format if all characters are digits. The following is a valid example for a non-critical extension:

certutil -setextension 123 "extension1" 0 Value1

CertUtil [options] [-config ConfigString] -ca.signature
OutCASignatureCertFile
Result: Retrieves the Certificate Authority (CA) signing certificate and writes it to the file specified by OutCASignatureCertFile.

CertUtil [options] [-config ConfigString] -ca.exchange
OutCAExchangeCertFile
Result: Retrieves the CA key exchange certificate and writes it to the file specified by OutCAExchangeCertFile.

CertUtil [options] -verifykeys KeyContainerName CACertFile
Result: Verifies the public/private key set in the key container specified by KeyContainerName using the CA certificate specified by CACertFile.

CertUtil [options] -verify CertFile CACertFile
Result: Verifies the certificate specified by CertFile was issued using the CA certificate specified by CACertFile. Both files must contain a single certificate, not a PKCS7. Also verifies the revocation status of the CertFile certificate. An error will occur if CertFile does not contain information on how to check revocation or the necessary URLs or CRLs are unavailable.

CertUtil [options] -7f CertFile
Result: Checks the certificate specified by CertFile for 0x7f length encodings. Avoiding 0x7f length encodings ensures compatibility with old enrollment controls.

CertUtil [options] -?
Result: Displays the command options.

The CertUtil command options are as follows:

-config ConfigString | Causes the operation to be processed using the Certificate Authority (CA) identified in the configuration string specified by ConfigString. Without this option, the default CA will process the request.
-idispatch | Causes CertUtil to use IDispatch methods instead of COM for the current operation.
-v | Causes CertUtil to display verbose output.
-db RequestID | Used only with the dump command. Only the database row specified by RequestID is dumped. The Certificate Server service must be stopped to use this option.

For further explanation of how to use CertUtil, see Examining Configuration Information.


Troubleshooting Intro

Troubleshooting

TBD


Administration Tools Explanation

Administration Tools

TO BE Determined


Administering Certificate Server Intro

Administering Certificate Server


Administering Certificate Server

Administering Certificate Server Using The Microsoft Management Console


Concepts Intro

Concepts

List Contents


Cert Admin - Intro

Certificate Administration


How To Topic

How To...


How To Intro

List Contents


Intermediary Explanation

Intermediary Application

The Intermediary is the architectural component that receives new certificate requests from clients and submits them to the Server Engine (ADD LINK). The intermediary is composed of two parts, the intermediary application that performs actions on behalf of clients, and the Certificate Server client interface (CertCli.dll) that handles communications between the intermediary application and the server engine.

Intermediaries can be written to handle certificate requests from different types of clients and across multiple transports. Microsoft® Internet Information Server is an intermediary that provides support for clients over HTTP. Intermediaries can also check on the status of a previously submitted request and obtain the Certificate Server's configuration information.


Establishing Domain Trust Relationships

TBD


Serv Admin - Set Permissions

Setting Permissions


Service Admin Intro

Service Administration

This section includes information about the following topics:

  • Starting and Stopping the service.
    • (ADD LINKS)
  • Configuring the Policy and Exit Modules.
  • Publishing Information About the CA to the Directory Service.
  • Establishing a Certification Hierarchy.
  • Establishing Domain Trust Relationships.
  • Installing Certificates.
  • Renewing a Certificate Authority.
  • Removing a Certificate Authority.
  • Managing and Publishing Certificate Revokation Lists.
  • Backing Up and Restoring a Certificate Authority.


Understanding the Certificate Store View

Certificates are stored


Using Cert. Server

Using Certificate Server


Using the Microsoft Management Console to Administer Certificate Server

Welcome to the Certificate Server Microsoft Management Console Snap-in

The Microsoft Management Console (MMC) provides a single program to manage all hardware, software, and network components of your windows NT system. Programs called snap-ins form the basic administrative components of every console. For more information about MMC generally, see (ADD LINK TO MMC INTRO FILE)

Using the Certificate Server Administration Snap-in you can operate the server, configure and maintain Certificate Authorities and manage the issuance and revocation of certificates.

This section includes information about the following topics:

  • Overview of the Certificate Server Administration Console
  • Installing the Certificate Server Snap-in.(ADD LINKS)
  • Service Administration (ADD LINK) including configuring and operating the server and Certificate Authorities.
  • Certificate Administration (ADD LINK) including managing certificate requests and issued certificates.


New Features Intro

New Features