Windows 2000 Server and PKI: Using the nCipher Hardware Security Module

By David Cross, Microsoft Corporation, and William A. Franklin, nCipher, Inc.

Abstract

The Microsoft Windows 2000 operating system provides users with an integrated public key infrastructure (PKI) that allows them to establish and maintain security - including cryptographic security. This paper examines how nCipher's hardware security modules (HSMs) and Windows 2000 Server work together to perform routine cryptographic and PKI operations. Issues related to HSMs that can affect the setup and operation of Windows 2000 Server and the PKI are also discussed.

On This Page

Introduction
Windows 2000 PKI
Hardware Security Module
CryptoAPI
nCipher Security World
HSM Installation Procedures
Additional Information

Introduction

The implementation of a public key infrastructure (PKI) is necessary to support many new technologies - this includes encrypting files and exchanging digitally-signed, encrypted e-mail with external partners and customers. By installing hardware security modules (HSMs) on certificate authorities, customers using Microsoft Windows 2000 Certificate Services and PKI are able to generate digital certificates and store encrypted keys at every level of their PKI solution. This is done with the highest cryptographic and operational security available in the marketplace.

Benefits

nCipher HSMs provide several benefits to Microsoft Windows 2000 Certificate Server installations. These benefits include secure forms of random number generation; hardware key generation; and hardware key management. Also provided is the capability to enforce administrative security policies regarding cryptographic operations. nCipher's HSMs provide the ability to securely store private keys in a way that is not available in software-based implementations.

An Administrative Guide

Because HSMs provide a series of security enhancements to Windows 2000-based servers, this white paper is designed to be an administrative guide for using HSMs with PKI and asymmetric key operations in the deployment of Windows 2000.

This guide provides information on the Microsoft Windows 2000 Certificate Server and its use of the nCipher HSM - including the use of PKI and other servers via the Microsoft CryptoAPI framework.

In addition to a broad overview, this document covers many of the installation and technical details involved in deploying Windows 2000 Server and PKI with HSMs.

Best Practices

The operations and recommendations presented in this white paper are consistent with emerging best practices in open standards groups and professional consortia. To learn more, refer to the following documents from the American National Standards Institute (https://www.ansi.org/):

ANSI ASC X9.79, PKI Practices and Policy Framework, September 2000

AICPA/CICA WebTrustSM/TM Security Principle and Criteria, Version 3.0, January 1, 2001

Windows 2000 PKI

Microsoft Windows 2000 Server includes a full-featured PKI that delivers the business benefits of public-key cryptography. In contrast to third-party PKI solutions that must be purchased separately, the Windows 2000 PKI is delivered as part of the operating system. It requires no per-certificate issuance fees and is seamlessly integrated into normal network management tasks. The result is a lower total cost of ownership.

Windows 2000 PKI Components

The primary components of the Windows PKI are the following:

Certificate Services

Certificate Services is a core operating system service that allows businesses to act as their own certificate authorities. They can issue and manage digital certificates to represent their e-business identities. Windows 2000 supports multiple levels of a Certificate Authority (CA) hierarchy and cross-certification as well as offline and online Certificate Authorities for maximum flexibility.

Active Directory

Active Directory™ is a core, Lightweight Directory Access Protocol (LDAP)-based operating system service that provides a single place to find network resources. It serves as the internal and external publication service in the PKI. Active Directory is also the centralized management interface for certificate issuance.

Windows 2000 introduces the concept of the enterprise certificate authority. This feature is integrated with the Active Directory and enables other features such as Secure Sockets Layer (SSL) client mapping, smart card logon and machine auto-enrollment.

Standards-based, PKI-enabled Applications

Standards-based, PKI-enabled applications include applications such as: Internet Explorer, Encrypting File System, Internet Protocol Security (IPSec) , Microsoft Money, Internet Information Services, Outlook , and Outlook Express - as well as numerous third-party applications that leverage the Windows 2000 PKI.

The Exchange Key Management Service

The Exchange Key Management Service (KMS) is a component of Microsoft Exchange that allows for the archiving and retrieval of keys used to encrypt e-mail. Both Microsoft Exchange Server 5.5 and Microsoft Exchange 2000 integrate with a Windows 2000 certificate authority for the issuance of x.509v3 compliant certificates for S/MIME. In a future version of Windows, the KMS will be integrated into the Windows operating system as an enterprise-wide key archival and recovery solution.

Hardware Security Module

Microsoft Windows 2000 Certificate Services ships with several software cryptographic service providers (CSPs), such as basic and enhanced CSPs. The private keys generated by software CSPs are archived and encrypted in the protected store. To provide higher-level key protection for a certificate authority's private key(s), a hardware-based CSP should be used.

For more information about the protected store, please refer to the Microsoft Windows 2000 Server Resource Kit from Microsoft Press (https://www.microsoft.com/mspress/). For details about the Resource Kit, visit https://www.microsoft.com/windows2000/techinfo/reskit/default.mspx.

HSM Defined

A hardware security module (HSM), such as nCipher's nShield, is a hardware encryption device that's connected to a server at the device level via PCI or SCSI interfaces. From an operating system view, the HSM interface is through the Microsoft CryptoAPI interfaces at the logical level. (Refer to Figure 1 for a logical representation of the technical relationship of the components.)

Figure 1: Cryptographic Service Providers (CSP) Framework with nShield HSM

Key Features

The HSM can provide secure operational management - protected by multi-layered hardware and software tokens - as well as a number of other key features, including:

• Hardware-based, cryptographic operations (such as random number generation, key generation, digital signatures, and key archive and recovery).

• Hardware protection of valuable private keys used to secure asymmetric cryptographic operations.

• Secure management of private keys.

• Acceleration of cryptographic operations. (This relieves the host server of having to perform processor-intensive, cryptographic calculations.)

• Load balancing and failover in hardware modules using multiple HSMs linked together through a daisy chain.

nCipher and Windows 2000 Server

nCipher's HSM supports Windows 2000 Server in the following ways:

• Protects the CA, and other private signing and encryption keys, in hardware validated to FIPS 140-1 Level 2 or Level 3 specifications.

• Creates keys using hardware-based, random-number generation.

• Provides robust and flexible administration of disaster recovery policies for key management.

• Provides life-cycle management of application keys.

• Provides administration of key access control through the use of multiple sets of smart card-based hardware tokens.

• Scales linearly across multiple Windows 2000 Server installations and facilitates multiple server PKI deployments.

By using HSMs on each Windows 2000 Certificate Server, customers are able to generate digital certificates and store encrypted keys at every level of their PKI deployment. This provides the cryptographic and operational security capabilities needed to meet all governmental and industrial customer requirements.

Hardware Cryptographic Service Providers

Hardware-based, cryptographic service providers (CSPs) have been used traditionally to provide enhanced performance by offloading cryptographic operations from host processors to specialized hardware. For certificate services, a hardware-based CSP can be used to provide a higher level of assurance for the storage of asymmetric private cryptographic key material. Protecting private keys in specialized, tamper-resistant hardware greatly increases their security, as well as the security of the CA and the certificates it signs. For high value CAs - those securely stored offline, or for high-assurance online CAs - those that issue "high-value" certificates, it is advisable to use a hardware CSP.

The Windows 2000 Certification Authority is automatically FIPS 140-1 Level 1-compliant through the FIPS 140-1 Level 1 status of Microsoft CSPs. The nShield HSM from nCipher provides both FIPS 140-1 Level 2 and Level 3 compliant solutions.

For additional information about FIPS 140-1, visit the National Institute of Standards and Technology Web site (https://csrc.nist.gov/cryptval/140-1.htm), where you'll find nCipher NIST-approved evaluations.

The Purpose of a Hardware-based CSP

A hardware-based CSP serves two purposes:

• It provides additional security for cryptographic keys.

• It accelerates cryptographic algorithms by offloading them to the HSM. (This frees the CPU to do other application processing.)

nCipher Hardware Security Module

nCipher's nShield HSMs provide hardware key storage and transactional acceleration when installed on Windows 2000 with a CSP that is digitally- and cryptographically-signed by Microsoft. These tamper-resistant, physically-hardened HSMs, with their key-management functionality, are well-suited for certificate authorities and other secure PKI applications - including cryptographic operations on any server that implements a Microsoft CSP.

HSM Security Policies

nCipher's HSMs allow users to create and enforce additional security policies. A Microsoft customer installing an nCipher HSM with Windows 2000 is able to reduce the threat of physical attacks on private keys by using split responsibility ("k of n" sharing policies) for key activation.

An nCipher HSM can require multiple smart cards, with correct pass phrases, to be presented before loading and activating private keys. This provides the most comprehensive protection available to HSMs and the keys they protect.

The nCipher nShield family of HSMs meets the UnitedStates federal standards for data security, FIPS 140-1 Level 2 or Level 3. This is important for establishing a level of trust between Microsoft and its business partners, including the U.S. government. The nShield HSMs are capable of 150 to 400 1024-bit RSA key signings per second, depending on the model.

(Additional information regarding the implementation of an nCipher HSM is found in later sections of this white paper.)

CryptoAPI

The Microsoft Cryptographic API (CryptoAPI) provides services that enable application developers to add cryptography and certificate management functionality to their Win32 applications. Applications can use the functions in CryptoAPI without knowing anything about the underlying implementation, just as an application can use a graphics library without knowing anything about the particular graphics hardware configuration.

The Microsoft CryptoAPI provides a set of functions that allow applications to encrypt or digitally sign data in a flexible manner, while protecting sensitive private key data. All cryptographic operations are performed by independent modules known as cryptographic service providers (CSPs). A number of software CSPs, including the Microsoft RSA and DSA/DH providers, are bundled with the operating system.

CryptoAPI supports many different types of CSPs. Some provide different cryptographic algorithm suites, while others contain hardware interface components such as smart cards. In addition, some CSPs, such as nCipher's nCore API, may occasionally communicate with users directly (for example, when digital signatures are performed with the user's signature private key).

Refer to Figure 2 for how an HSM works with Microsoft Windows 2000 Server through CryptoAPI.

Figure 2: Microsoft CAPI and its relationship to nCipher's HSM and Security World

CAPICOM

The CryptoAPI interfaces can also be accessed through a new method called CAPICOM, which is built on CryptoAPI. CAPICOM is a Component Object Model (COM) client, supporting Automation, that performs cryptographic functions using Microsoft ActiveX and COM objects.

CAPICOM can be used in applications created in many programming languages - such as Microsoft Visual Basic , Visual Basic Scripting Edition, and C++ - to perform fundamental cryptographic tasks. For example, a Visual Basic application can use CAPICOM objects to digitally sign data, verify digital data signatures, envelop data for privacy, and encrypt and decrypt arbitrary data.

For additional information regarding the CryptoAPI programming model or CAPICOM, refer to the Microsoft Developer Network (https://msdn.microsoft.com/).

nCipher Security World

The nCipher Security World framework is used by its hardware security modules (HSMs) to map a user's security policies into a flexible hardware infrastructure. nCipher's HSM plays a central role in nCipher's Security World.

nCipher's Security World framework extends across both Microsoft and non-Microsoft domains and servers; this means that keys generated, manipulated and stored in one operating system environment can be used across various operating systems within heterogeneous operating environments.

Framework Components

The nCipher Security World framework is made up of the components shown in Figure 3. The Microsoft PKI and CryptoAPI can exploit these components to protect and manage private keys in a networked environment.

Figure 3 Security World Framework

Systems Procedures	Operational Staff	Security Policies
	Security Officers	Access Control Rules
	Transaction Authorizer	Risk Control Strategies
	Key Management	Operational Procedures
	IT Administrator	7X24 Availability
	Outsourcing Agent (ISP)	Disaster Recovery

Command and Control Framework	nCipher Security World
	Shared Responsibility Risk Distribution and Sharing	Personal Pass Phrases "k of n" Authentication Schemes
	Operational Operator Card(s) Set Key Generation Tools	Administration Administrator Card(s) Set Administration Tools

Organization	Security Infrastructure
	Networked Servers	Physical Security	Logical Security
	SSL Web Servers	Keys stored and used in Hardware Security Module	ACLs for key usage
	Certificate Authorities		Perfect Key Sharing
	Registration Authorities	Tamper Resistant	3XDES Encryption
	OCSP Server	FIPS 140-1, Level 3 validated	RSA/DSA Authentication

Note: Figure 3 is not exhaustive in its examples; it's intended to highlight risks that can be better secured using cryptographic tools.

The nCipher Security World framework ties the operational staff and security policies of the systems department to the command and control framework. (This is how cryptographic security is used and controlled.) nCipher's Security World is also tied into the organization and security infrastructure in which it's used.

Security Infrastructure

The security infrastructure includes:

• Networked servers by type

• Physical security (cryptographic tokens and software)

• Logical security –(the actual cryptography used to support given policies)

Security World in Action

Consider the following example, using Figure 3 above as a reference.

nCipher Security World allows the use of a single private key on a number of servers. This is a typical situation in a server farm, where the private key would be exported as an object encrypted with 3DES in one of the HSMs attached to each of the subject servers. This means that a single server farm can offer its transactional partners a single public key safely and that each server can respond as called upon to execute security protocol transactions. This can be done in either a designated server or under failover conditions.

HSMs and Smart Cards

nCipher's HSMs use dedicated smart cards to provide two basic levels of security that protect access to the private key stored and used in the HSM:

• Operator Card Set

• Administrator Card Set

Each card set restricts access to features, functions, and keys in slightly different ways. "k of n" and pass phrases are required to gain access to the cards.

The potential for defeating HSM appliances is negligible if they're designed to meet a stringent policy concerning "k of n", pass phrases, and physical security.

Security World Benefits

nCipher's Security World allows you to do the following:

• Share keys securely between various HSMs, regardless of the operating system being used.

• Store an infinite number of keys.

• Build policies for failover and cryptographic load balancing.

• Create multi-layered protection for private keys.

• Back up critical key data securely, quickly, and simply across a given nCipher Security World.

• Build effective secure key retrieval plans for disaster or other recovery needs.

• Achieve detailed control of the security and cryptographic infrastructure.

• Delegate control to third parties without loss of overall control.

Key Backup

The basic functions of both nCipher's Security World and HSM include setting up for the storage and recovery of private keys.

When you use encryption in your business, you risk the possibility that critical intellectual property might be stranded in an encrypted state and become totally inaccessible. This can result from malicious activity or a simple accident or disaster. The security capabilities of nCipher's Security World and HSMs ensure that you have complete control over who can recover keys and under what circumstances. This allows you to recover data without compromising ongoing operations.

Key Recovery

In Windows 2000, key recovery using the Microsoft PKI is still limited to keys generated in the HSM and selected clients. It is also limited to the functions one can exercise via CryptoAPI and the nCipher Security World interface.

However, with clear, enforceable policies that specify who may generate valid key pairs and where those keys may be generated - combined with a designated storage, archive, or directory - a credible key recovery process may be developed.

(For more information, refer to the specifications in the Microsoft Platform Software Developer Kit , and nCipher's CipherTools™ Developer Kit.)

Additional Features

Additional features of nCipher's Security World include the capability to:

• Create backups of the nShield data on a disk, together with the administrative smart cards.

• Allow the routine backup of encrypted keys as part of the regular software backups required in an IT environment.

nShield allows an administrator to re-create a damaged or lost security world in the event of an HSM hardware failure. Without both steps, the CA environment cannot be rebuilt.

Backups of the CA database are required to restore a history of issued certificates. Without restoration of the certificate database, certificates cannot be revoked.

HSM Installation Procedures

The following sections describe the installation of the nCipher hardware security module.

Cryptographic Module Installation

The nCipher hardware cryptographic module must be installed properly prior to installing Certificate Services on Windows 2000 Server.

Install the nCipher software by performing the following tasks:

1. Log onto the machine as local Administrator.

2. Insert the nCipher CD-ROM that supports Windows 2000.

3. Run the setup program using the command R:\WIN\2000\NFAST\NFAST.EXE, where R represents the CD-ROM drive letter.

4. Accept the Welcome panel. Click Next.

5. Accept the software license agreement. Click Next.

6. Install all components (default setting), and install to the C:\NFAST directory.

7. Select the radio button that allows a high level of logging information to be recorded, and click Next.

   A panel appears, informing you that a shortcut will be placed on your desktop. Click OK. Do not run the shortcut until the hardware cryptographic module is installed. The installation wizard performs the following tasks:

   1. Creates a security world and operator card set.

   2. Installs the correct nCipher CSP.

   3. Makes the nCipher CSP the default Schannel provider for SSL functionality.

8. A panel appears indicating that the software installation is complete and prompts you to reboot. Select the No radio button, and click Finish. Shut down the computer manually.

Install the hardware cryptographic module by performing the following tasks:

1. Insert the internal SCSI controller, which should be compatible with Adaptec controller 29160N, internal Ultra 160.

   FOR INTERNAL CRYPTOGRAPHIC MODULES:

   1. Place the cryptographic module in initialization mode by adding the jumper J2.

   2. Set the SCSI ID to 2 by placing a jumper on J7.

   3. Terminate the SCSI device chain by placing a jumper on J9.

   4. Insert the cryptographic module, and connect to the SCSI controller.

   FOR EXTERNAL CRYPTOGRAPHIC MODULES:

   1. Connect the SCSI port of the cryptographic module to the SCSI controller.

   2. Place the SCSI terminator on the second SCSI port of the cryptographic module.

   3. Set the SCSI ID to 2 using the SCSI selector on the back of the cryptographic module.

1. Boot the computer after installing the nCipher hardware. Windows should detect the new hardware and install the new drivers. After it installs the new drivers, Windows may ask for another reboot.

   After the system has been rebooted with HSM in pre-initialization mode:

   1. Re-run CSP wizard.

   2. When prompted, select the radio button create new security world.

   3. Use the Wizard to create an ACS, then an OCS.

   Create the security world by performing the following functions. (The cryptographic module should still be in the initialization mode.)

   1. FOR EXTERNAL CRYPTOGRAPHIC MODULES ONLY:

      1. While holding the initialization switch on the rear of the cryptographic module, stop and start the nFast Server service.

      2. The cryptographic module is now in pre-initialization mode.

   2. From the Start menu, click Programs and then KMTool.

   3. Select the Modules button in the left-hand column. A Module Operations panel appears. Select Initialize Security World to prepare the security world for use.

   4. Select the radio button enabling key recovery. Enter a value of 2 for the total number of cards in set, and enter a value of 1 as the number of cards required for access. Then click the Initialize security world! button.

   5. A Create Administrator Card Set panel appears. Select yes to use a pass phrase. Insert the first card. Enter and verify the pass phrase. Click the Write Card button.

   6. Insert the second card, and repeat.

   7. A Module Initialized panel appears. Click the Finished button.

   8. Reboot the system.

      FOR INTERNAL CRYPTOGRAPHIC MODULES ONLY:

      1. Remove the J2 jumper, and reboot the server.

      2. The cryptographic module is now in the operational mode.

2. Check whether the installation was successful by opening a command prompt and running the following program: C:\nfast\bin\enquiry. Observe that the server and module modes are operational.

Certificate Authority (CA) Setup

Follow these instructions to install Windows 2000 Server Certificate Services using an nCipher hardware-based CSP.

Important: To install the Certificate Services Web enrollment pages, you need to ensure that Microsoft Internet Information Services (IIS) was already installed prior to installing Certificate Services.

nCipher CSP Install Wizard

1. Run the nCipher CSP Install Wizard shortcut on the Desktop.

2. A Welcome panel appears. Click Next.

3. A security world setup panel appears. It indicates that it detected the existing security world created earlier. Select the radio button that elects to use the existing security world, and then click Next.

   A Create Operator Card Set panel appears. Ensure that a suitable card set exists for use with nCipher CSPs. Fill in the answers on this panel as follows:

   1. Check the box to create an operator card set.

   2. Name the card set OCSCAXX or OCSKMXX, where XX represents the unique server identifier.

   3. Number of Cards required: 1

   4. Total number of cards: 3

   5. Do not select the option to create persistent cards.

   6. Click Next.

4. An Insert Card panel appears for each card. Do not check the box card to require a pass phrase. Erase the card if necessary.

5. A software installation panel will appear indicating that you have a valid security world and operator card set. Check the box to make the nCipher CSP the default SChannel CSP. Click Next to install the CSP.

CA Installation

1. Click the Start button, point to Settings, and then click Control Panel.

2. Double-click Add/Remove Programs. When an Add/Remove Programs dialog box similar to the following is displayed, click Add/Remove Windows Components.

   

3. Click to select the Certificate Services check box, and then click Next.

   

   Note: If you want to use the Web components of the Certificate Services, click to select the Internet Information Services (IIS) check box. When a warning message is displayed, click OK.

   The Certificate Services Web components allow you to:

   • Connect to the Web page to enroll for a certificate.

   • Download a CA certificate from the Web page.

   • Save the certificate request to a file so that it can be processed by an external CA.

   This component should already be installed.

4. When the Certification Authority Type dialog box is displayed, click the applicable CA types.

   (For additional information regarding the different types of Certificate Authorities possible in Windows 2000, please refer to Microsoft TechNet at https://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/depopt/2000cert.mspx.)

5. Select the Advanced options check box to change the default cryptographic settings, and then click Next.

6. After selecting the Advanced Options check box, the Public and Private Key Pair dialog box is displayed; use it to change the cryptographic settings, such as the cryptographic service provider (CSP), the hashing algorithm, and other advanced options.

   To support the NCIPHER hardware cryptographic module, select the nCipher Enhance Cryptographic provider from the drop-down box. In the Hash algorithm list, click SHA-1. Make sure that the Use existing keys check box is cleared (not selected). Choose an appropriate key length in the Key length list box.

   Note: It is recommended that a minimum key length of 2048 be used.

7. The CA Identifying Information dialog box is displayed. Type the identifying information that is appropriate for your site and organization.

   Note: The CA name (or common name) is critical; it is used to identify the CA object created in the directory.]

   You can only set the validity duration for a root CA. Enter an appropriate value in the Valid for box.

   Note: It is generally recommended that root CAs have a longer lifetime (such as 10 or 20 years) in comparison to an issuing CA that will be issuing end-entity certificates. Root certificates that are valid for a short duration require additional management because you must reissue root certificates to all of the client computers. The choice of a duration value is a trade-off between security and administrative overhead. Remember that each time a root certificate expires an administrator must update all of the trust relationships and "roll" the CA to a new certificate.]

8. The nCipher CSP Key Storage Wizard panel appears. Click Next.

9. The Load a token panel appears. Load the appropriate smart cards at this point. Click Next as required.

10. A panel appears indicating that the setup is finished. Click Finish.

11. The Data Storage Location dialog box is displayed. This is where you define the location of the certificate database, the location of configuration information, and the location of the Certificate Revocation List (CRL). Click to select the Store configuration information in a shared folder check box to specify the location of the folder where configuration information for the CA is stored. In the Shared folder box, type a Universal Naming Convention (UNC) path for this folder. Make sure that all of your CAs point to the same folder.

    Important: Both NTFS and non-NTFS partitions are supported with Certificate Services. For maximum security, performance and fault-tolerance, only NTFS partitions should be used, preferably in conjunction with fault tolerant hardware solutions such as RAID 5 disk arrays. For certificate authorities that will be used to issue high volumes of certificates, it is recommended that log files and the certificate database be placed on separate volumes for maximum performance. Actual performance characteristics will vary depending on hardware configuration and load placed on the certificate authority.

    Note: If you are installing a CA in the same location as a previously installed CA, the Preserve existing certificate database check box is selected by default. Click Next.

    Warning: Do not select the Preserve existing certificate database check box if you want to perform a new installation of the CA.

    

12. Click OK to stop IIS. You must stop IIS to install the Web components. If IIS is not installed, this dialog box is not displayed.

    

13. The Installing Components dialog box is displayed. Wait until the installation finishes. Click Finish.

14. The nCipher CSP key storage wizard appears again to load the signing key. Click Next.

15. Insert necessary smart cards, and enter pass phrases as necessary. Click Next.

16. A panel appears indicating that the installation is finished. Click Finished.

17. The main portion of the CA installation is now complete.

Adding CDP and AIA Extensions To a Root CA

Note that this procedure applies to Root CAs only. Root CAs are typically maintained in an offline or disconnected state. Therefore, CRL Distribution Points (CDPs) and the Authority Information Access (AIA) must be added so that applications can access CRLs from an accessible location. Adding CDP and AIA extensions is an optional configuration for a Certificate Authority.

1. Open the MMC Certification Authority applet for the recently installed Root CA. Right-click the CA, and select Properties; then select the Policy Module tab. Click Configure.

   

2. The Properties applet appears. Select the X.509 Extensions tab.

   

3. Configure appropriate CRL Distribution Points (CDPs).

4. Add appropriate Authority Information Access (AIA) locations.

   Note: The above steps could have been performed at CA installation time through the use of a capolicy.inf file stored in the c:\%systemroot% directory.

Using a Capolicy.inf File

To use a capolicy.inf file, it must be placed in %systemroot% on the system where the CA is to be installed. A capolicy.inf file may be used for both initial installation as well as renewal of a CA.

Notes on using a capolicy.inf file

• The key length and validity section of the capolicy.inf file may only be used during CA renewal, not during initial installation.

• During root CA certificate renewal, if no CDP or AIA sections are found in capolicy.inf, the previous certificate's CDP or AIA URLs are reused for the renewed root certificate. The defaults are used only when creating the initial CA root certificate during certificate server setup and no CDP or AIA sections are found in capolicy.inf.

• The capolicy.inf file is only used to control the CDP that gets inserted into root CA certificates. CDPs that get inserted into all certificates issued by a CA (including subordinate CA certificates) are controlled by the issuing CA's registry (managed through the Certification Authority snap-in).

• When escaping special characters in CDP or AIA URLs in capolicy.inf, four percent signs (%) must be used. To escape spaces, for example, "http:://crl.microsoft.com/Microsoft%%%%20Test%%%%20Network%%%%20CA.crl" must be used. This has been fixed in the next release of the operating system.

• When a PKCS#10 subordinate CA request is submitted to a parent CA to retrieve the new subordinate CA certificate, the parent CA's policy module must take action to pass the policy statement extension through to the new subordinate CA certificate. By default, extensions included in requests are added to the certificate server database, but are left disabled.

Sample capolicy.inf file

[Version]
Signature = "$Windows NT$"
[Certsrv_Server]
RenewalKeyLength = 4096
RenewalValidityPeriod = 20
RenewalValidityPeriodUnits = Years
[CAPolicy]
Policies = LegalPolicy, LimitedUsePolicy, ExtraPolicy, OIDPolicy
[LegalPolicy]
OID = 1.3.6.1.4.1.311.99.99; need an OID to identify policy
Notice = "https://www.microsoft.com/pki/mscorp/cps.htm"
[LimitedUsePolicy]
OID = 1.3.6.1.4.1.311.21.47
URL = "https://http.microsoft.com/somewhere/default.asp"
URL = "ftp://ftp.microsoft.com/somewhere-else/default.asp"
Notice = "Limited use policy statement text."
URL = "ldap://ldap.microsoft.com/somewhere-else-again/default.asp"
[ExtraPolicy]
OID = 1.3.6.1.4.1.311.21.53
URL = https://extra.microsoft.com/Extra Policy/default.asp
[oidpolicy]
OID = 1.3.6.1.4.1.311.21.55
[CRLDistributionPoint]
URL = 
"ldap:///CN=Microsoft%%%%20Corporate%%%%20Root%%%%20Authority,CN=TestCA,CN=CDP,CN
=Public%%%%20Key%%%%20Services,CN=Services,CN=Configuration,DC=Cor
p,DC=Microsoft,DC=Com?certificateRevocationList?base?objectclass=cRLDistributionPoint"
URL = 
"ldap://corp.microsoft.com/CN=Microsoft%%%%20Corporate%%%%20Root%%%%20Author
ity,CN=TestCA,CN=CDP,CN=Public%%%%20Key%%%%20Services,CN=Services,CN=Con
figuration,DC=Corp,DC=Microsoft,DC=Com?certificateRevocationList?base?objectclass=cRL
DistributionPoint"
URL = https://crl.microsoft.com/mscorp/mscra1.crl
[AuthorityInformationAccess]
URL = 
"ldap:///CN=Microsoft%20Corporate%20Root%20Authority,CN=AIA,CN=Public%20Key%20S
ervices,CN=Services,CN=Configuration,DC=Corp,DC=Microsoft,DC=Com?cACertificate?bas
e?objectclass=certificationAuthority"
URL = 
"ldap://corp.microsoft.com/CN=Microsoft%20Corporate%20Root%20Authority,CN=AIA,CN=P
ublic%20Key%20Services,CN=Services,CN=Configuration,DC=Corp,DC=Microsoft,DC=Com
?cACertificate?base?objectclass=certificationAuthority"

URL = https://www.microsoft.com/pki/mscorp/mscra1.crtRenewing the Root Certificate

After the CDP and AIA extensions have been added, the Root CA certificate must be updated to reflect the new CDPs and AIAs.

To perform this process:

1. Right-click the CA and select All Tasks, then Renew Certificate.

2. Click Renew to renew the new public and private key pair.

3. Click OK.

Additional Information

For additional information, refer to the following Web sites:

• Microsoft Public Key Infrastructure Information

  https://www.microsoft.com/technet/security/guidance/cryptographyetc/default.mspx

• Windows 2000 Certificate Services White Paper

  https://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/depopt/2000cert.mspx

• Microsoft CryptoAPI Overview on MSDN

  https://msdn.microsoft.com/workshop/security/capi/cryptapi.asp

• nCipher Product Information

  https://www.ncipher.com/index.php

• nCipher Documentation

  https://www.ncipher.com/documentation