Who will be interested in this feature?
CNG applies to public key infrastructure (PKI) deployments that require the use of Suite B algorithms and that do not need to integrate with certification authorities (CAs) that do not support Suite B algorithms, such as CAs installed on servers running the Windows Server® 2003 and Windows® 2000 Server operating systems.
Are there any special considerations?
To use the new cryptographic algorithms, both your CA and your applications should support ECC (or any other new algorithm you implement under CNG). While the CA needs to issue and manage these new certificate types, applications must be able to handle certificate chain validation and use the keys generated with Suite B algorithms.
Suite B algorithms such as ECC are supported only on the Windows Vista® and Windows Server 2008 operating systems. This means it is not possible to use those certificates on earlier versions of Windows such as Windows XP or Windows Server 2003. However, it is possible to use classic algorithms such as Rivest-Shamir-Adleman (RSA) even if the keys have been generated with a CNG key provider.
Clients running Windows Vista or Windows Server 2008 can use either CryptoAPI 1.0 or the new CNG API because both APIs can run side-by-side. However, applications such as SSL, IPsec, Secure/Multipurpose Internet Mail Extensions (S/MIME), and Kerberos must be updated in order to use Suite B algorithms.
How should I prepare for CNG?
Do not deploy certificates with Suite B algorithms before verifying these requirements:
Before issuing certificates that use algorithms such as ECC, verify that your CAs and operating systems support these algorithms.
Verify that your organization's PKI-enabled applications can use certificates that rely on CNG cryptographic providers.
If your organization uses certificates to support smart card logon, contact your smart card vendor to verify that their smart cards can handle CNG algorithms.
In Windows Vista and Windows Server 2008, the following certificate-enabled applications can handle certificates that use cryptographic algorithms that are registered in the CNG provider.
Application name
|
Verify a certificate chain that contains certificates with algorithms that are registered in a CNG provider
|
Use algorithms that are not supported by CryptoAPI
|
Encrypting File System (EFS)
|
Yes
|
No
|
IPsec
|
Yes
|
Yes
|
Kerberos
|
No
|
No
|
S/MIME
|
Outlook 2003: no
Outlook 2007: yes
|
Outlook 2003: no
Outlook 2007: yes
|
Smart card logon
|
No
|
No
|
SSL
|
Yes
|
Yes
|
Wireless
|
Yes
|
Yes
|
How should I prepare to deploy this feature?
To use Suite B algorithms for cryptographic operations, you first need a Windows Server 2008–based CA to issue certificates that are Suite B-enabled.
If you do not have a PKI yet, you can set up a Windows Server 2008–based CA where the CA certificates and the end-entity certificates use Suite B algorithms. However, you still have to verify that all your applications are ready for Suite B algorithms and can support such certificates.
If you already have a PKI with CAs running Windows Server 2003 or where classic algorithms are being used to support existing applications, you can add a subordinate CA on a server running Windows Server 2008, but you must continue using classic algorithms.
To introduce Suite B algorithms into an existing environment where classic algorithms are used, consider adding a second PKI and perform a cross-certification between the two CA hierarchies.
Additional references
For information about other features in AD CS, see Active Directory Certificate Services Role.
For more information about CNG, see Cryptography API: Next Generation (http://go.microsoft.com/fwlink/?LinkID=74141).
For more information about Suite B, see the NSA Suite B Cryptography Fact Sheet (http://go.microsoft.com/fwlink/?LinkId=76618).
AD CS: Online Certificate Status Protocol Support
Certificate revocation is a necessary part of the process of managing certificates issued by certification authorities (CAs). The most common means of communicating certificate status is by distributing certificate revocation lists (CRLs). In the Windows Server® 2008 operating system, public key infrastructures (PKIs) where the use of conventional CRLs is not an optimal solution, an Online Responder based on the Online Certificate Status Protocol (OCSP) can be used to manage and distribute revocation status information.
What does OCSP support do?
The use of Online Responders that distribute OCSP responses, along with the use of CRLs, is one of two common methods for conveying information about the validity of certificates. Unlike CRLs, which are distributed periodically and contain information about all certificates that have been revoked or suspended, an Online Responder receives and responds only to requests from clients for information about the status of a single certificate. The amount of data retrieved per request remains constant no matter how many revoked certificates there might be.
In many circumstances, Online Responders can process certificate status requests more efficiently than by using CRLs. For example:
Clients connect to the network remotely and either do not need nor have the high-speed connections required to download large CRLs.
A network needs to handle large peaks in revocation checking activity, such as when large numbers of users log on or send signed e-mail simultaneously.
An organization needs an efficient means to distribute revocation data for certificates issued from a non-Microsoft CA.
An organization wants to provide only the revocation checking data needed to verify individual certificate status requests, rather than make available information about all revoked or suspended certificates.
Who will be interested in this feature?
This feature applies to organizations that have PKIs with one or more Windows-based CAs.
Adding one or more Online Responders can significantly enhance the flexibility and scalability of an organization's PKI; therefore, this feature should interest PKI architects, planners, and administrators.
In order to install an Online Responder, you must be an administrator on the computer where the Online Responder will be installed.
Are there any special considerations?
Online Responders in Windows Server 2008 include the following features:
Web proxy caching. The Online Responder Web proxy cache is the service interface for the Online Responder. It is implemented as an Internet Server API (ISAPI) extension hosted by Internet Information Services (IIS).
Support for nonce and no-nonce requests. Configuration options for nonce and no-nonce requests can be used to prevent replay attacks of Online Responder responses.
Windows setup integration. An Online Responder can be set up by using Server Manager.
Advanced cryptography support. An Online Responder can be configured to use elliptic curve cryptography (ECC) and SHA-256 cryptography for cryptographic operations.
Preconfigured OCSP Response Signing certificate templates. Deployment of an Online Responder is simplified by using an OCSP Response Signing certificate template that is available in Windows Server 2008.
Kerberos protocol integration. Online Responder requests and responses can be processed along with Kerberos password authentication for prompt validation of server certificates at logon.
Microsoft® Online Responders are based on and comply with RFC 2560 for OCSP. For this reason, certificate status responses from Online Responders are frequently referred to as OCSP responses. For more information about RFC 2560, see the Internet Engineering Task Force Web site (http://go.microsoft.com/fwlink/?LinkId=67082).
What new functionality does Online Responder provide?
Two significant new sets of functionality can be derived from the Online Responder service:
Online Responders. The basic Online Responder functionality provided by a single computer where the Online Responder service has been installed.
Responder arrays. Multiple linked computers hosting Online Responders and processing certificate status requests.
An Online Responder is a computer on which the Online Responder service is running. A computer that hosts a CA can also be configured as an Online Responder, but it is recommended that you maintain CAs and Online Responders on separate computers. A single Online Responder can provide revocation status information for certificates issued by a single CA or multiple CAs. CA revocation information can be distributed using more than one Online Responder.
Why is this functionality important?
Applications that depend on X.509 certificates, such as Secure/Multipurpose Internet Mail Extensions (S/MIME), Secure Sockets Layer (SSL), Encrypting File System (EFS), and smart cards need to validate the status of the certificates whenever they are used to perform authentication, signing, or encryption operations. Certificate status and revocation checking verifies the validity of certificates based on:
Time. Certificates are issued to a fixed period of time and considered valid as long as the expiration date of the certificate is not reached and the certificate has not been revoked before that date.
Revocation status. Certificates can be revoked before their expiration date for a variety of reasons, such as key compromise or suspension.
CRLs contain the serial numbers of all of the certificates issued by a CA that have been revoked. In order for a client to check the revocation status of a certificate, it needs to download a CRL containing information about all of the certificates that have been revoked by the CA.
Over time CRLs can become extremely large, which can require significant network resources and storage for the CA and the relying party. This can result in tradeoffs between more frequent distribution of updated CRLs and the time and network bandwidth needed to distribute them. If CRLs are published less frequently, then clients have to rely on less accurate revocation information.
There have been numerous attempts to solve the CRL size issue through the introduction of partitioned CRLs, delta CRLs, and indirect CRLs. All of these approaches have added complexity and cost to the system without providing a solution.
What works differently?
When you are using Online Responders, the Online Responders, rather than the relying clients, receive all the certificate revocation data. A relying party submits a status request about an individual certificate to an Online Responder, which returns a definitive, digitally signed response indicating the status of only the certificate in the request. The amount of data retrieved per request is constant, no matter how many revoked certificates exist in the certificate database on the CA.
How should I prepare for this change?
Online Responders can be installed on computers running Windows Server 2008. They should be installed after the CAs but before any client certificates are issued. The certificate revocation data is derived from a published CRL that can come from a CA on a computer running Windows Server 2008, a CA on a computer running Windows Server 2003, or from a non-Microsoft CA.
Before configuring a CA to support the Online Responder service, the following must be present:
IIS must be installed on the computer before the Online Responder can be installed. The correct configuration of IIS for the Online Responder is installed automatically when you install an Online Responder.
An OCSP Response Signing certificate template must be configured on the CA, and autoenrollment used to issue an OCSP Response Signing certificate to the computer on which the Online Responder will be installed.
The URL for the Online Responder must be included in the authority information access (AIA) extension of certificates issued by the CA. This URL is used by the Online Responder client to validate certificate status.
After an Online Responder has been installed, you also need to create a revocation configuration for each CA and CA certificate served by an Online Responder.
A revocation configuration includes all of the settings that are needed to respond to status requests regarding certificates that have been issued using a specific CA key. These configuration settings include:
CA certificate. This certificate can be located on a domain controller, in the local certificate store, or imported from a file.
Signing certificate for the Online Responder. This certificate can be selected automatically for you, selected manually (which involves a separate import step after you add the revocation configuration), or you can use the selected CA certificate.
Revocation provider that will provide the revocation data used by this configuration. This information is entered as one or more URLs where valid base and delta CRLs can be obtained.
Important
Before you begin to add a new revocation configuration, make sure you have the information in this list.
Responder Arrays
Multiple Online Responders can be linked in an Online Responder Array. Online Responders in an Array are referred to as Array members. One member of the Array must be designated as the Array controller. Although each Online Responder in an Array can be configured and managed independently, in case of conflicts the configuration information for the Array controller will override configuration options set on other Array members.
Why is this functionality important?
An Online Responder Array can be created and additional Online Responders added to the Array for a number of reasons, including fault tolerance in case an individual Online Responder becomes unavailable, geographic considerations, scalability, or network design considerations.
For example, remote branch offices might not have consistent connections with headquarters where a CA is located. Therefore it is not always possible to contact the CA or a remote Online Responder to process a revocation status request.
What works differently?
Because members of a Online Responder Array may be remote and subject to less than optimal network conditions, each member of the Array can be monitored and managed independently.
How should I prepare for this change?
Setting up an Online Responder Array requires advance planning based on:
Number and location of the CAs being serviced by the Array.
Number of clients who will request certificates from the CAs and their locations.
Network connectivity between clients, CAs, and potential Online Responders.
Volume of certificate enrollments, certificate revocations, and certificate status requests that the organization's PKI handles.
Need for redundancy in case individual Online Responders become unavailable.
After the Online Responder Array has been planned, setting up the Array involves a number of procedures that must be coordinated.
What Group Policy settings have been added to support OCSP?
Several Group Policy settings have been added to enhance the management of OCSP and CRL data use. For example, CRLs have expiration dates, and if the expiration date passes before an update is published or becomes accessible, certificate chain validation can fail, even with an Online Responder present. This is because the Online Responder would be relying on data from an expired CRL. In situations where network conditions can delay the timely publication and receipt of updated CRLs, administrators can use these Group Policy settings to extend the expiration time of an existing CRL or OCSP response.
You can use the Revocation tab in Certificate Path Validation Settings (Computer Configuration, Windows Settings, Security Settings, and Public Key Policies) to extend the lifetime of CRLs and OCSP responses. To configure these options, you need to:
Click Define these policy settings.
Click Allow for all CRLs and OCSP responses to be valid longer than their lifetime.
Select Default time the validity period can be extended, and enter the desired value of time (in hours).
A separate option on the Revocation tab allows you to override OCSP responses with information contained in CRLs. Thus, a certificate that has been revoked by adding it to a local CRL could still be verified as valid if a client has a CRL that does not include its revocation status. Although this option is not recommended, it can be useful in circumstances where revocation changes made by a local administrator are not final until a CA administrator verifies the change.
Both of these settings are located at Computer Configuration, Windows Settings, Security Settings, and Public Key Policies.
Important
Administrative credentials are needed to modify Group Policy settings.
Share with your friends: |