Certificate Services

Certificate Services provides customizable services for issuing and managing certificates that are used in software security systems that employ public key technology.

  • Before deploying certification authorities and a public key infrastructure, see Checklists.
  • For tips about using Certificate Services, see Best practices.
  • For help with specific tasks, see How to.
  • For general background information, see Concepts.
  • For problem-solving instructions, see Troubleshooting.


Checklists

  • Checklist: Deploying certification authorities and PKI for an intranet
  • Checklist: Deploying certification authorities and PKI for the Internet
  • Checklist: Creating a certification hierarchy with an offline root certification authority
  • Checklist: Deploying smart cards for logging on to Windows


Checklist: Deploying certification authorities and PKI for an intranet

This checklist is focused on the configuration and setup of enterprise certification authorities (CAs) which are useful for public key infrastructure (PKI) architectures where Active Directory is present.

Please refer to Checklist: Deploying certification authorities and PKI for the Internet for information about configuring stand-alone CAs.

If you are going to have an offline root certification authority in your certification hierarchy, see Checklist: Creating a certification hierarchy with an offline root certification authority

Step | Reference
Review Concepts |
Review public key infrastructure concepts | Public key infrastructure
Review certificates concepts | Certificates concepts
Review concepts about certification authorities | Certificate Services concepts
Review concepts about using public key policy in Group Policy | Public key policy concepts
Set up certification authorities |
Plan a certification hierarchy | Certification authority hierarchies
Set up a Windows 2000 server for each certification authority | Set up for Windows 2000 Server
Ensure that Active Directory and DNS are installed on your network | Active Directory overview
Plan the renewal strategy you are going to use for the root certification authority | Renewing certification authorities
Install a root certification authority | Install an enterprise root certification authority
(Optional) Enable Netscape-compatible revocation checking URL extensions to be written in every certificate issued. |
Install subordinate certification authorities (as required by your planned certification hierarchy) | Install an enterprise subordinate certification authority
For each domain |
Set security permissions and delegate control of certificate templates | Set security permissions and delegate control of certificate templates
Set security permissions and delegate control of certification authorities | Set security permissions and delegate control of a certification authority
For each certification authority |
Specify which certificate types to issue | Establish the certificate types that an enterprise certification authority can issue
Schedule the publication of the certificate revocation list | Schedule the publication of the certificate revocation list
(Optional) Enable Netscape-compatible revocation checking URL extensions to be written in every certificate issued. | Refer to Revoking certificates and publishing CRLs
Confirm that the certification authority will properly authenticate certificate requesters from the CA Web pages | Set security for access to certification authority Web pages
Set up applications and services to use public key infrastructure |
Set up smart cards for Windows 2000 logon | Checklist: Deploying smart cards for logging on to Windows
Set up a web server to use certificates for secure access | Certificates and Internet Information Services (http://localhost/iishelp/iis/htm/core/iicerts.htm) (You need to have IIS installed to use this shortcut.)
Set up Internet Protocol security (IPSec) | Internet Protocol security (IPSec)
Set up Encrypting File System EFS Recovery agents | Encrypting File System and data recovery
Set up a Microsoft Exchange server to use certificates for secure e-mail | Refer to Microsoft Exchange documentation
Manage certificate issuance for computers |
(Optional) Establish certificate autoenrollment for machines | Create an automatic certificate request for computers in a Group Policy object
Ongoing administrative tasks |
Revoke certificates | Revoke an issued certificate
Back up each certification authority | Backing up and restoring a certification authority
Renew each certification authority | Renewing certification authorities


Checklist: Deploying certification authorities and PKI for the Internet

This checklist is focused on the configuration and setup of stand-alone certification authorities (CAs) which are useful for public key infrastructure (PKI) architectures where Active Directory is not used, such as the Internet.

For deploying certification authorities that use Active Directory, please refer to Checklist: Deploying certification authorities and PKI for an intranet.

If you are going to have an offline root certification authority in your certification hierarchy, see Checklist: Creating a Certification Hierarchy with an Offline Root Certification Authority.

Step | Reference
Review Concepts |
Review public key infrastructure concepts | Public key infrastructure
Review certificates concepts | Certificates concepts
Review concepts about certification authorities | Concepts
Set up certification authorities |
Plan a certification hierarchy | Certification authority hierarchies
Set up a Windows 2000 Server for each certification authority | Set up for Windows 2000 Server
Plan the renewal strategy you are going to use for the root certification authority | Renewing certification authorities
Install a root certification authority | Install a stand-alone root certification authority
(Optional) Enable Netscape-compatible revocation checking URL extensions to be written in every certificate issued. |
Install subordinate certification authorities (as required by your planned certification hierarchy) | Install a stand-alone subordinate certification authority
Install Web enrollment services on non-certification authority servers, as required. (Used to submit certificate requests via servers that are not certification authorities.) | Set up certification authority Web enrollment support
For each certification authority |
Specify whether to make each incoming certificate request pending (the recommended default for most cases) or automatically approved | Set the default action upon receipt of a certificate request
Schedule the publication of the certificate revocation list | Schedule the publication of the certificate revocation list
(Optional) Enable Netscape-compatible compatible checking URL extensions to be written in every certificate issued. | Refer to Revoking certificates and publishing CRLs
Set up applications and services to use public key infrastructure |
Set up a Web server to use certificates for secure access | Certificates and Internet Information Services (http://localhost/iishelp/iis/htm/core/iicerts.htm) (You need to have IIS installed to use this shortcut.)
Set up Internet Protocol security (IPSec) | Internet Protocol security (IPSec)
Set up a Microsoft Exchange server to use certificates for secure e-mail | Refer to Microsoft Exchange documentation
Ongoing administrative tasks |
Review pending certificate requests | Review pending certificate requests
Revoke certificates | Revoke an issued certificate
Back up each certification authority | Backing up and restoring a certification authority
Renew each certification authority | Renewing certification authorities


Checklist: Creating a certification hierarchy with an offline root certification authority

This checklist is provided for the cases where the root certification authority (CA) is not connected to your organization's network. You might choose to have an isolated, offline root CA for security reasons in order to protect it from possible attacks by hackers or malicious individuals via the network.

A major issue with an offline root certification authority is providing certificate verifiers with online certificate revocation checking. This checklist assists public key infrastructure (PKI) administrators with setting up functional certificate revocation checking for certificates issued by an offline root CA.

See Checklist: Deploying certification authorities and PKI for an intranet for further information about configuring enterprise CAs.

See Checklist: Deploying certification authorities and PKI for the Internet for further information about configuring stand-alone CAs.

Step | Reference
Review Concepts |
Review public key infrastructure concepts. | Public key infrastructure
Review certificates concepts. | Certificates concepts
Review concepts about certification authorities. | Certificate Services concepts
Set up the offline root certification authority |
Plan the certification hierarchy. | Certification authority hierarchies
Set up a Windows 2000 server that you will use for the root certification authority. The server needs to have Internet Information Services (IIS) installed as part of setup. The server needs to be a member server in an Active Directory domain. | Set up for Windows 2000 Server
Plan the renewal strategy you are going to use for the root certification authority | Renewing certification authorities
Log on to the network as a domain administrator and install the root certification authority on the server that will be offline (disconnected from the network). You need to install the root CA while the server is attached to the network so that it can update Active Directory and its root certificate will automatically be trusted by any computer or user in the domain. | Install a stand-alone root certification authority
On the new root CA, change the URL location of the certificate revocation list (CRL) distribution point to a location of your choice that is accessible to all users in you organization's network. It is possible to enter multiple URLs. It is necessary to do this because the offline root CA's default CRL Distribution Points (CDPs) are not accessible to users on the network and, if they are left unchanged, certificate revocation checking will fail. | Specify CRL distribution points in issued certificates
Schedule the publication of the certificate revocation list. | Schedule the publication of the certificate revocation list
For each subordinate certification authority |
Set up a Windows 2000 server for each subordinate certification authority | Set up for Windows 2000 Server
Install subordinate certification authorities, as required by your planned certification hierarchy. These can be stand-alone certification authorities or, if you are using Active Directory, enterprise certification authorities. During setup for each subordinate CA, choose to save the CA certificate request to a file, which will be a PKCS #10 request. | Install a stand-alone subordinate certification authority; Install an enterprise subordinate certification authority
Copy the CA certificate request file from the subordinate certification authority to some portable storage media. Take the CA certificate request to the root certification authority. |
Using the root certification authority's Web pages, submit the PKCS #10 request from the file to get the CA certificate for the subordinate certification authority. | Request a certificate using a PKCS #10 file
On the root certification authority, accept the pending certificate request and issue the CA certificate using the Certification Authority snap-in. | Review pending certificate requests
Using the root certification authority's Web pages, check on on the pending certificate request which you just approved. Download the new certificate and, if provided, the certification path to files on the portable storage media you are using. | Check on a pending certificate request
Take the portable storage media back to the subordinate certification authority. In Windows Explorer, locate the certificate and certification path files you just copied, right-click on each file and choose to Install Certificate. Have the Certificate Import wizard automatically place the certificates in stores based on the type of certificate. | Import a certificate
Before issuing any certificates from the subordinate certification authorities and, afterwards, every time a new CRL is published by the offline root CA |
On the root certification authority, publish a certificate revocation list. (Do this only if it has not already been published using its CRL publishing schedule). | Manually publish the certificate revocation list
In Windows Explorer on the root CA, locate the certificate revocation list you just published. The CRL's default location is: \Systemroot\system32\CertEnroll\CAname.crl Right-click on the CRL file and send it to a drive that has portable storage media. |
Copy the certificate revocation list file to every URL location that you specified as a CRL distribution point in the root CA's Policy settings. Your systems can now do certificate revocation checking on certificates issued by the offline root CA. |


Best practices

  • Plan your public key infrastructure (PKI) before deploying certification authorities (CAs).

    See Certificate Services Concepts and the resources listed in Resources: Public Key Infrastructure for information that will assist you with planning a PKI.

  • The root certification authority (CA) should be offline and its signing key should be secured by hardware and kept in a vault to minimize potential for key compromise.

    For more information, see Checklist: Creating a certification hierarchy with an offline root certification authority

  • If you are going to use a custom policy module for a Windows 2000 certification authority, you should install Certificate Services using stand-alone policy and then replace stand-alone policy with your custom policy. Replacing enterprise policy on a CA with a custom policy is not supported and will have unpredictable results

  • Only change security permissions for the certification authority (CA) using the Certification Authority snap-in. Setting permissions using other mechanisms (such as the Active Directory Sites and Services snap-in) may create problems when for users attempting to access and request certificates from the certification authority.

    For more information, see Set security permissions and delegate control of a certification authority

  • Organizations should not issue certificates to users or computers directly from the root certification authority (CA) but rather should deploy at least a three-level CA hierarchy compromised of Root-Intermediate-Issuer CAs to provide flexibility and insulate the root certification authority from attempts to compromise its private key by malicious individuals.

    For more information, see

    • Certification authority hierarchies
    • Establishing a certification hierarchy
  • Backing up the certification authority (CA) database, the CA certificate and the CA keys is essential to protect against the loss of critical data. The CA should be backed up on a regular basis (daily, weekly, monthly) based on the number of certificates issued over the same interval. The more certificates issued, the more frequently you should back up the CA.

    For more information, see Backing up and restoring a certification authority

  • You should review the concepts of security permissions and access control in Windows, since enterprise certification authorities issue certificates based on the security permissions of the certificate requester.

    For general information about access control and security permissions in Windows 2000, see Access Control. For the procedure to set access control on a CA, see Set security permissions and delegate control of a certification authority. For the procedure to set enterprise-wide access control on certificate templates, see Set security permissions and delegate control of certificate templates.


How To ...

  • Set up a certification authority
  • Administer a certification authority


Set up a certification authority

  • Install an enterprise root certification authority
  • Install an enterprise subordinate certification authority
  • Install a stand-alone root certification authority
  • Install a stand-alone subordinate certification authority
  • Uninstall a certification authority
  • Set up certification authority Web enrollment support


Install an enterprise root certification authority

To install an enterprise root certification authority

  1. Log on to the system as a Domain Administrator.
  2. Click Start, point to Settings, and then click Control Panel.
  3. Double-click Add/Remove Programs and then click Add/Remove Windows Components.
  4. In the Windows Components wizard, select the Certificate Services check box. A dialog box will appear to inform you that the computer cannot be renamed, and the computer cannot be joined to or removed from a domain after Certificate Services is installed. Click Yes and then click Next.
  5. Click Enterprise root CA.
  6. (Optional) Select the Advanced options check box to specify the following.
    Advanced option | Comment
    Cryptographic service provider (CSP) | The default is the Microsoft Base Cryptographic Provider. Certificate Services does support third party CSPs but you must refer to the CSP vendor's documentation for information about using their CSP with Certificate Services.
    Hash algorithm | The default is SHA-1.
    Existing keys | If you select this option, you can use an existing public key and private key pair instead of generating new ones. This is helpful if you are relocating or restoring a previously installed certification authority (CA).
    Key length | The default key length using the Microsoft Base Cryptographic Provider is 512 bits. Default key lengths for other CSPs vary. In general, the longer the key length, the more secure the key is. For a root CA, you should use a key length of at least 2048 bits. This option is not available if you are using existing keys.
    When you are done, click Next.
  7. Type the name of the certification authority and other necessary information. None of this information can be changed after the CA setup is complete.
  8. In Validity duration, specify the validity duration for the root CA. See the note below about things to consider when setting this value. Click Next.
  9. Specify the storage locations of the certificate database, the certificate database log, and the shared folder. Click Next.
  10. If the World Wide Web Publishing service is running, you will see a request to stop the service before proceeding with the installation. Click OK.
  11. If prompted, type the path to the Certificate Services installation files.

Notes

  • The enterprise root CA selection requires that the host computer be a member of a domain and that it use Active Directory. The administrator who is installing an enterprise CA must have Write permission to Active Directory.
  • If you have Write permission to Active Directory, then specifying the shared folder is optional, and is not typically done for enterprise certification authorities.
  • The validity duration you choose for the CA will determine when the CA "expires." For information about renewing CAs, see Related Topics.
  • Certain Windows components require configuration before thay can be used. If you installed one or more of these components, but did not configure them, when you click Add/Remove Windows Components, a list of components that need to be configured is displayed. To start the Windows Components wizard, click Components.

Related Topics


Install an enterprise subordinate certification authority

To install an enterprise subordinate certification authority

  1. Log on to the system as a Domain Administrator.
  2. Click Start, point to Settings, and then click Control Panel.
  3. Double-click Add/Remove Programs and then click Add/Remove Windows Components.
  4. In the Windows Components wizard, select the Certificate Services check box. A dialog box will appear to inform you that the computer cannot be renamed, and the computer cannot be joined to or removed from a domain after Certificate Services is installed. Click Yes and then click Next.
  5. Click Enterprise subordinate CA.
  6. (Optional) Select the Advanced options check box to specify the following.
    Advanced option | Comment
    Cryptographic service provider (CSP) | The default is the Microsoft Base Cryptographic Provider. Certificate Services does support CSPs from other vendors, but you must refer to the CSP vendor's documentation for information about using their CSP with Certificate Services.
    Hash algorithm | The default is SHA-1.
    Existing keys | You can use an existing public key and private key pair instead of generating new ones if you select this option. This is helpful if you are relocating or restoring a previously installed certification authority (CA).
    Key length | The default key length using the Microsoft Base Cryptographic Provider is 512 bits. Default key lengths for other CSPs vary. In general, the longer the key length, the more secure the key is. For a subordinate CA, you should use a key length of at least 1024 bits. This option is not available if you are using existing keys.
    When you are done, click Next.
  7. Type in the name of the CA and other necessary identifying information. None of this information can be changed after the CA setup is complete. Click Next.
  8. Specify the storage locations of the certificate database, the certificate database log, and the shared folder. Click Next.
  9. Obtain the certificate for the subordinate CA. For instructions on how to do this, see Notes.
  10. If the World Wide Web Publishing Service is running, the system will request that you stop the service before proceeding with the installation. Click OK.
  11. If prompted, type the path to the Certificate Services installation files.

Notes

  • To obtain the certificate for a subordinate CA, you must submit a certificate request to a parent CA. The procedure for doing so differs depending on whether the parent CA is available online.
    • If a parent CA is available online:
      1. Click Send the request directly to a CA already on the network.
      2. In Computer Name, type the name of the computer on which the parent CA is installed.
      3. In Parent CA, click the name of the parent CA.
    • If a parent CA is not available online:
      1. Click Save the request to a file.
      2. In Request file, type the path and file name of the file that will store the request.
      3. Obtain this subordinate CA's certificate from the parent CA.

        The procedure for doing this will be unique to the parent CA. At a minimum, the parent CA should provide a file containing the subordinate CA's newly issued certificate and, preferably, its full certification path. For the procedure to submit a certificate request using a file to a Windows 2000 CA, see Related Topics.

        If you get a subordinate CA certificate that does not include the full certification path, the new subordinate CA you are installing must be able to build a valid CA chain when it starts. Thus you must install the parent CA's certificate in the Intermediate Certification Authorities certificate store of the computer (if the parent CA is not a root CA), as well as the certificates of any other intermediate CA in the chain, and you must install the certificate of the root CA in the chain into the Trusted Root Certification Authorities store. These certificates should be installed in the certificate store before you install the CA certificate on the subordinate CA you have just set up.

      4. Open Certification Authority.
      5. In the console tree, click the name of the CA.

        Where?

        • Certification Authority (computer)
        • CA name
      6. On the Action menu, point to All Tasks, and then click Install CA Certificate.
      7. Locate the certificate file received from the parent certification authority, click this file, and then click Open.
  • The enterprise subordinate CA selection requires that the host computer be a member of a domain and that it use Active Directory. The administrator who is installing an enterprise CA must have Write permission to Active Directory.
  • If you have Write permission to Active Directory, then specifying the shared folder is optional, and is not typically done for enterprise CAs.
  • To open Certification Authority, click Start, point to Programs, point to Administrative Tools, and then click Certification Authority.
  • Certain Windows components require configuration before thay can be used. If you installed one or more of these components, but did not configure them, when you click Add/Remove Windows Components, a list of components that need to be configured is displayed. To start the Windows Components wizard, click Components.

Related Topics


Install a stand-alone root certification authority

To install a stand-alone root certification authority

  1. Log on to the system as an Administrator, or if you have Active Directory, log on to the system as a Domain Administrator.
  2. Click Start, point to Settings, and then click Control Panel.
  3. Double-click Add/Remove Programs and then click Add/Remove Windows Components.
  4. In the Windows Components wizard, select the Certificate Services check box. A dialog box will appear to inform you that the computer cannot be renamed, and the computer cannot be joined to or removed from a domain after Certificate Services is installed. Click Yes and then click Next.
  5. Click Stand-alone root CA.
  6. (Optional) Select the Advanced options check box to specify the following.
    Advanced option | Comment
    Cryptographic service provider (CSP) | The default is the Microsoft Base Cryptographic Provider. Certificate Services does support third party CSPs but you must refer the CSP vendor's documentation for information about using their CSP with Certificate Services.
    Hash algorithm | The default is SHA-1.
    Existing keys | You can use an existing public key and private key pair instead of generating new ones if you select this option. This is helpful if you are relocating or restoring a previously installed certification authority (CA).
    Key length | The default key length using the Microsoft Base Cryptographic Provider is 512 bits. Default key lengths for other CSPs vary. In general, the longer the key length, the more secure the key is. For a root CA, you should use a key length of at least 2048 bits. This option is not available if you are using existing keys.
    When you are done, click Next.
  7. Type the name of the certification authority and other necessary information. None of this information can be changed after the CA setup is complete.
  8. In Validity duration, specify the validity duration for the root CA. See the note below about things to consider when setting this value. Click Next.
  9. Specify the storage locations of the certificate database, the certificate database log, and the shared folder. Click Next.
  10. If the World Wide Web Publishing Service is running, you will receive a request to stop the service before proceeding with the installation. Click OK.
  11. If prompted, type the path to the Certificate Services installation files.

Notes

  • If Active Directory is available and you have Write permission to Active Directory, then specifying the shared folder is optional.
  • The validity duration you choose for the CA will determine when the CA "expires." For information about renewing CAs, see Related Topics.
  • Certain Windows components require configuration before thay can be used. If you installed one or more of these components, but did not configure them, when you click Add/Remove Windows Components, a list of components that need to be configured is displayed. To start the Windows Components wizard, click Components.

Related Topics


Install a stand-alone subordinate certification authority

To install a stand-alone subordinate certification authority

  1. Log on to the system as an Administrator, or if you have Active Directory, log on to the system as a Domain Administrator.
  2. Click Start, point to Settings, and then click Control Panel.
  3. Double-click Add/Remove Programs and then click Add/Remove Windows Components.
  4. In the Windows Components wizard, select the Certificate Services check box. A dialog box will appear to inform you that the computer cannot be renamed, and the computer cannot be joined to or removed from a domain once Certificate Services is installed. Click Yes, and then click Next.
  5. Click Stand-alone subordinate CA.
  6. (Optional) Select the Advanced options check box to specify the following.
    Advanced option | Comment
    Cryptographic service provider (CSP) | The default is the Microsoft Base Cryptographic Provider. Certificate Services does support CSPs from other vendors, but you must refer the CSP vendor's documentation for information about using their CSP with Certificate Services.
    Hash algorithm | The default is SHA-1.
    Existing keys | You can use an existing public key and private key pair instead of generating new ones if you select this option. This is helpful if you are relocating or restoring a previously installed certification authority (CA).
    Key length | The default key length using the Microsoft Base Cryptographic Provider is 512 bits. Default key lengths for other CSPs vary. In general, the longer the key length, the more secure the key is. For a subordinate CA, you should use a key length of at least 1024 bits. This option is not available if you are using existing keys.
    When you are done, click Next.
  7. Type in the name of the CA and other necessary identifying information. None of this information can be changed after the CA setup is complete. Click Next.
  8. Specify the storage locations of the certificate database, the certificate database log, and the shared folder. Click Next.
  9. Obtain the certificate for the subordinate CA. For instructions on how to do this, see Notes.
  10. If the World Wide Web Publishing Service is running, the system will request that you stop the service before proceeding with the installation. Click OK.
  11. If prompted, type the path to the Certificate Services installation files.

Notes

  • To obtaining the certificate for a subordinate CA, you must submit a certificate request to a parent CA. The procedure for doing so differs depending on whether the parent CA is available online.
    • If a parent CA is available online:
      1. Click Send the request directly to a CA already on the network.
      2. In Computer Name, type the name of the computer on which the parent CA is installed.
      3. In Parent CA, click the name of the parent CA.
    • If a parent CA is not available online:
      1. Click Save the request to a file.
      2. In Request file, type the path and file name of the file that will store the request.
      3. Obtain this subordinate CA's certificate from the parent CA.

        The procedure for doing this will be unique to the parent CA. At a minimum, the parent CA should provide a file containing the subordinate CA's newly issued certificate and, preferably, its full certification path. For the procedure to submit a certificate request using a file to a Windows 2000 CA, see Related Topics.

        If you get a subordinate CA certificate that does not include the full certification path, the new subordinate CA you are installing must be able to build a valid CA chain when it starts. Thus you must install the parent CA's certificate in the Intermediate Certification Authorities certificate store of the computer (if the parent CA is not a root CA), as well as the certificates of any other intermediate CA in the chain, and you must install the certificate of the root CA in the chain into the Trusted Root Certification Authorities store. These certificates should be installed in the certificate store before you install the CA certificate on the subordinate CA you have just set up.

      4. Open Certification Authority.
      5. In the console tree, click the name of the CA.

        Where?

        • Certification Authority (computer)
        • CA name
      6. On the Action menu, point to All Tasks, and then click Install CA Certificate.
      7. Locate the certificate file received from the parent certification authority, click this file, and then click Open.
  • If Active Directory is available and you have Write permission to Active Directory, then specifying the shared folder is optional.
  • To open Certification Authority, click Start, point to Programs, point to Administrative Tools, and then click Certification Authority.
  • Certain Windows components require configuration before thay can be used. If you installed one or more of these components, but did not configure them, when you click Add/Remove Windows Components, a list of components that need to be configured is displayed. To start the Windows Components wizard, click Components.

Related Topics


Uninstall a certification authority

To uninstall a certification authority

  1. Click Start, point to Settings, and then click Control Panel.
  2. Double-click Add/Remove Programs and then click Add/Remove Windows Components.
  3. In the Windows Components wizard, clear the Certificate Services check box, and then click Next.
  4. If the World Wide Web Publishing Service is running, the system will request that you stop the service before proceeding with the uninstall process. Click OK.

Notes

  • You should back up the entire server before uninstalling the certification authority (CA).
  • When you uninstall a CA, the following information is left on the server:
    • The CA's database
    • The CA's public and private keys
    • The CA's certificates in the Personal store
    • The CA's certificates in the shared folder (if a shared folder was specified during Certificate Services setup)
    • The CA chain's root certificate in the Trusted Root Certification Authorities store
    • The CA chain's intermediate certificates in the Intermediate Certification Authorities store
    • The CA's certificate revocation list (CRL)

    This information is kept on the server by default in case you are uninstalling and then reinstalling the CA. You might uninstall and reinstall if you wanted to change a stand-alone CA to an enterprise CA.

  • Certain Windows components require configuration before thay can be used. If you installed one or more of these components, but did not configure them, when you click Add/Remove Windows Components, a list of components that need to be configured is displayed. To start the Windows Components wizard, click Components.

Related Topics


Set up certification authority Web enrollment support

To set up certification authority Web enrollment support

  1. Log on to the system as an Administrator, or if you have Active Directory, log on to the system as a Domain Administrator.
  2. Click Start, point to Settings, and then click Control Panel.
  3. Double-click Add/Remove Programs and then click Add/Remove Windows Components.
  4. In the Windows Components wizard, select the Certificate Services check box. A dialog box will appear to inform you that the computer cannot be renamed, and the computer cannot be joined to or removed from a domain after Certificate Services is installed. Click Yes, and then click Details.
  5. Clear the Certificate Services CA check box, verify that the Certificate Services Web Enrollment Support check box remains selected, and then click OK. Click Next.
  6. In Computer Name, type in the name of the computer on which the certification authority (CA) is installed, the CA for which these Web enrollment pages will be used. The name of the CA will appear in the list. Click Next.
  7. If the World Wide Web Publishing Service is running, the system will request that you stop the service before proceeding with the installation. Click OK.
  8. If prompted, type in the path to the Certificate Services installation files.

Notes

  • Internet Information Services (IIS) must be installed on the server before you install the CA Web enrollment pages.
  • CA Web enrollment pages are installed by default when you set up Certificate Services on a server that has IIS installed. This procedure is necessary only if you want to install the CA Web enrollment pages on a server that is separate from the server on which the CA is installed.
  • If you changed the default option during Certificate Services setup and did not install the CA Web enrollment pages on the CA server, you can run certutil -vroot from the command prompt on the CA to install the Web enrollment pages.
  • Certain Windows components require configuration before thay can be used. If you installed one or more of these components, but did not configure them, when you click Add/Remove Windows Components, a list of components that need to be configured is displayed. To start the Windows Components wizard, click Components.

Related Topics


Administer a certification authority

  • Start or stop the certification authority service
  • View the certification authority certificate
  • Back up a certification authority
  • Restore a certification authority from a backup copy
  • Set security for access to certification authority Web pages
  • Renew a root certification authority
  • Renew a subordinate certification authority
  • Use the Certification Authority snap-in
  • Manage certificate revocation
  • Manage certificate requests on a stand-alone certification authority
  • Manage certificate templates for an enterprise certification authority
  • Change policy settings of a certification authority
  • Map certificates to user accounts
  • Change the policy or exit modules of a certification authority


Start or stop the certification authority service

To start or stop the certification authority service

  1. Log on to the system as an Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (computer)
    • CA name
  4. On the Action menu, point to All Tasks, and click Start Service to start the service or click Stop Service to stop the service.

Note

  • To open Certification Authority, click Start, point to Programs, point to Administrative Tools, and then click Certification Authority.
  • You can also start or stop Certificate Services if you open Computer Management, double-click Services and Applications, and then click Services. In the details pane, click Certificate Services. On the Action menu, click Stop or Start.

Related Topics


Set security permissions and delegate control of a certification authority

To set security permissions and delegate control of a certification authority

  1. Log on to the system as an Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (computer)
    • CA name
  4. On the Action menu, click Properties.
  5. Click the Security tab and specify the security permissions.

    For general information about setting access control security permissions, see Related Topics.

Note

  • To open Certification Authority, click Start, point to Programs, point to Administrative Tools, and then click Certification Authority.

Related Topics


View the certification authority certificate

To view the certification authority certificate

  1. Log on to the system as an Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (computer)
    • CA name
  4. On the Action menu, click Properties.
  5. On the General tab, click View CA Certificate.

Note

  • To open Certification Authority, click Start, point to Programs, point to Administrative Tools, and then click Certification Authority.

Related Topics


Back up a certification authority

To back up a certification authority

  1. Log on to the system as a Backup Operator or Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (computer)
    • CA name
  4. On the Action menu, point to All Tasks, and click Backup CA.
  5. Follow the instructions in the Certification Authority Backup wizard.

Notes

  • To open Certification Authority, click Start, point to Programs, point to Administrative Tools, and then click Certification Authority.

  • This procedure is useful if you want to backup a CA without backing up the entire server on which the CA is installed.

    In general, you should use Windows 2000 Backup and Windows 2000 Restore to back up and restore both the CA and the server. For more information about backing up a Windows 2000 server, see Windows 2000 Backup.

Related Topics


Restore a certification authority from a backup copy

To restore a certification authority from a backup copy

  1. Log on to the system as a Backup Operator or Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (computer)
    • CA name
  4. On the Action menu, point to All Tasks, and click Restore CA.
  5. Follow the instructions in the Certification Authority Restore wizard.

Notes

  • To open Certification Authority, click Start, point to Programs, point to Administrative Tools, and then click Certification Authority.

  • This procedure is useful if you want to restore a CA without restoring the entire server on which the CA is installed. To backup the CA for later restoration using this procedure, see Related Topics.

    In general, you should use Windows 2000 Backup and Windows 2000 Restore to back up and restore both the CA and the server. For more information about backing up a Windows 2000 server, see Windows 2000 Backup.

Related Topics


Set security for access to certification authority Web pages

To set security for access to certification authority Web pages

  1. Log on to the system as an Administrator.
  2. Click Start, point to Programs, point to Administrative Tools, and then click Internet Services Manager.
  3. In the console tree, right-click CertSrv, and click Properties..

    Where?

    • Internet Information Services
    • computer name
    • Default Web Site
    • CertSrv
  4. On the Directory Security tab, under Anonymous access and authentication control, click Edit.
  5. Clear all check boxes except Integrated Windows authentication.

Important

  • An enterprise certification authority (CA) requires that the certificate requester be authenticated by the page so that it can determine the correct information to put in the certificate. If you don't have authentication set for the Web pages in an enterprise CA, then the pages will fail to generate a certificate or, if a certificate is generated, it will be useless. For this reason, integrated Windows authentication is set by default on enterprise CAs. This procedure is provided so that you can confirm the default setting or fix an erroneous change to the IIS Directory Security settings for an enterprise certification authority.

Notes

  • You do not need to perform this procedure on a stand-alone certification authority.
  • If you cannot locate CertSrv in the console tree, confirm that Certificate Services is installed.
  • If Certificate Services is installed and the CertSrv virtual directory doesn't exist, run certutil -vroot from the command prompt to create it.

Related Topics


Renew a root certification authority

To renew a root certification authority

  1. Log on to the system as an Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (computer)
    • CA name
  4. On the Action menu, point to All Tasks, and click Renew CA Certificate.
  5. Do one of the following:
    • Click Yes if you want to generate a new public and private key pair for the certification authority's certificate.
    • Click No if you want to reuse the current public and private key pair for the certification authority's certificate.

Note

  • To open Certification Authority, click Start, point to Programs, point to Administrative Tools, and then click Certification Authority.

Related Topics


Renew a subordinate certification authority

To renew a subordinate certification authority

  1. Log on to the system as an Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (computer)
    • CA name
  4. On the Action menu, point to All Tasks, and click Renew CA Certificate.
  5. Do one of the following:
    • Click Yes if you want to generate a new public and private key pair for the CA's certificate.
    • Click No if you want to reuse the current public and private key pair for the CA's certificate.
  6. Get the CA certificate from the parent CA. For more information, see Notes.

Notes

  • To open Certification Authority, click Start, point to Programs, point to Administrative Tools, and then click Certification Authority.
  • To obtain the certificate for a subordinate CA, you must submit a certificate request to a parent CA. The procedure for doing so differs depending on whether the parent CA is available online.
    • If a parent CA is available online:
      1. Click Send the request directly to a CA already on the network.
      2. In Computer Name, type the name of the computer on which the parent CA is installed.
      3. In Parent CA, click the name of the parent CA.
    • If a parent CA is not available online:
      1. Click Save the request to a file.
      2. In Request file, type the path and file name of the file that will store the request.
      3. Obtain this subordinate CA's certificate from the parent CA.

        The procedure for doing this will be unique to the parent CA. At a minimum, the parent CA should provide a file containing the subordinate CA's newly issued certificate and, preferably, its full certification path. For the procedure to submit a certificate request using a file to a Windows 2000 CA, see Related Topics.

        If you get a subordinate CA certificate that does not include the full certification path, the new subordinate CA you are installing must be able to build a valid CA chain when it starts. Thus you must install the parent CA's certificate in the Intermediate Certification Authorities certificate store of the computer (if the parent CA is not a root CA), as well as the certificates of any other intermediate CA in the chain, and you must install the certificate of the root CA in the chain into the Trusted Root Certification Authorities store. These certificates should be installed in the certificate store before you install the CA certificate on the subordinate CA you have just set up.

      4. Open Certification Authority.
      5. In the console tree, click the name of the CA.

        Where?

        • Certification Authority (computer)
        • CA name
      6. On the Action menu, point to All Tasks, and then click Install CA Certificate.
      7. Locate the certificate file received from the parent certification authority, click this file, and then click Open.

Related Topics


Use the Certification Authority snap-in

  • Administer the certification authority on this computer
  • Administer the certification authority on another computer
  • Set display filters for the Certification Authority snap-in
  • Customize the display of columns in Certification Authority


Administer the certification authority on this computer

To administer the certification authority on this computer

  1. Log on to the system as an Administrator.
  2. Open Certification Authority.

Note

  • To open Certification Authority, click Start, point to Programs, point to Administrative Tools, and then click Certification Authority.

Related Topics


Administer the certification authority on another computer

To administer the certification authority on another computer

  1. Log on to the system as an Administrator.
  2. Open Certification Authority.
  3. On the Action menu, click Retarget Certification Authority.
  4. Click Another computer and type the name of the computer.

Notes

  • To open Certification Authority, click Start, point to Programs, point to Administrative Tools, and then click Certification Authority.
  • As an alternate way to manage a CA on another computer, perform the following steps:
    1. Log on to the system as an Administrator.
    2. Click Start, click Run, type mmc, and then click OK.
    3. On the Console menu, click Add/Remove Snap-in. Click Add.
    4. In Snap-in, double-click Certification Authority.
    5. Click Another computer and type the name of the computer.

Related Topics


Set display filters for the Certification Authority snap-in

To set display filters for the Certification Authority snap-in

  1. Log on to the system as an Administrator.
  2. Open Certification Authority.
  3. In the console tree, double-click the name of the certification authority (CA).

    Where?

    • Certification Authority (computer)
    • CA name
  4. Click any of the displayed folders, such as Revoked Certificates or Issued Certificates.
  5. On the View menu, click Filter.
  6. For each of the selection criteria:
    • Click Add.
    • In Field, click the field on which to filter.
    • In Operation, click the operation to qualify the filter value for this field.
    • In Value, type the qualification value.

Notes

  • To open Certification Authority, click Start, point to Programs, point to Administrative Tools, and then click Certification Authority.
  • Display filters are essentially a way to make simple queries against a CA's database. By using filters, you can restrict the items displayed in the details pane of the Certification Authority snap-in to items that meet a set of criteria you establish. For example, you can create a filter that will display in the Issued Certificates folder only those certificates that were effective after a specific date.
  • To remove a filter, click it in the Filter dialog box, and then click Remove.
  • To remove all existing filters, in the Filter dialog box, click Reset.

Related Topics


Customize the display of columns in Certification Authority

To customize the display of columns in Certification Authority

  1. Log on to the system as an Administrator.
  2. Open Certification Authority.
  3. In the console tree, double-click the name of the certification authority (CA).

    Where?

    • Certification Authority (computer)
    • CA name
  4. Click any of the displayed folders, such as Revoked Certificates or Issued Certificates.
  5. On the View menu, click Choose Columns.
  6. To | Do this
    Add a new column to the details pane | In Hidden Columns, click the column you want to add to the details pane. Click Add.
    Remove a column from the details pane | In Displayed Columns, click the column you want to remove from the details pane. Click Remove.
    Change the order of columns in the details pane | In Displayed Columns, click the column you want to move up or down in the order of the details pane. Click Move Up or Move Down as appropriate.

Notes

  • To open Certification Authority, click Start, point to Programs, point to Administrative Tools, and then click Certification Authority.
  • To sort the results, click the column heading in the details pane. You can only sort results based on columns (indicating the fields) that are indexed in the CA's database. There will be a small arrow on the column heading you are sorting by.

Related Topics


Manage certificate revocation

  • Revoke an issued certificate
  • Schedule the publication of the certificate revocation list
  • Specify certificate revocation list distribution points in issued certificates
  • Manually publish the certificate revocation list
  • View the certificate revocation list


Revoke an issued certificate

To revoke an issued certificate

  1. Log on to the system as an Administrator.
  2. Open Certification Authority.
  3. In the console tree, click Issued Certificates

    Where?

    • Certification Authority (computer)
    • CA name
    • Issued Certificates
  4. In the details pane, click the certificate you want to revoke.
  5. On the Action menu, point to All Tasks, and click Revoke Certificate.
  6. Select the reason for revoking the certificate and click Yes.

Notes

  • To open Certification Authority, click Start, point to Programs, point to Administrative Tools, and then click Certification Authority.
  • The certificate is marked as revoked and is moved to the Revoked Certificates folder. The revoked certificate will appear on the certificate revocation list (CRL) the next time it is published.
  • Certificates revoked with the reason code "Certificate Hold" can be unrevoked, left on "Certificate Hold" until they expire, or have their revocation reason code changed. This is the only reason code that allows you to change the status of a revoked certificate. It is useful if the status of the certificate is questionable and is meant to provide some flexibility to the CA administrator.

    • To unrevoke a certificate revoked with the reason code "Certificate Hold," at a command prompt on the CA, type

      certutil -revoke certificateserialnumber unrevoke

      To identify the certificateserialnumber, double-click the revoked certificate in the details pane of the Revoked Certificates folder, and then click the Details tab.

    • To change the reason code for a certificate previously revoked with the reason code "Certificate Hold," type the appropriate command at a command prompt on the CA.

      New reason code for
      revoking a certificate
      currently on "Certificate Hold"
      Command
      Unspecified | certutil -revoke certificateserialnumber 0
      Key Compromise | certutil -revoke certificateserialnumber 1
      CA Compromise | certutil -revoke certificateserialnumber 2
      Affiliation Changed | certutil -revoke certificateserialnumber 3
      Superseded | certutil -revoke certificateserialnumber 4
      Cessation of Operation | certutil -revoke certificateserialnumber 5

Related Topics


Schedule the publication of the certificate revocation list

To schedule the publication of the certificate revocation list

  1. Log on to the system as an Administrator.
  2. Open Certification Authority.
  3. In the console tree, click Revoked Certificates.

    Where?

    • Certification Authority (computer)
    • CA name
    • Revoked Certificates
  4. On the Action menu, click Properties.
  5. In Publish Interval, type the increment and click the unit of time to use for the automatic publishing of the certificate revocation list (CRL).

Notes

  • To open Certification Authority, click Start, point to Programs, point to Administrative Tools, and then click Certification Authority.
  • The CRL is published in:

    Systemroot\system32\CertSrv\CertEnroll\

    If the computer is a domain member and has permission to write to Active Directory, then the CRL is also published to Active Directory.

  • The publishing period for a CRL is not the same as the validity period for a CRL. By default, the validity period of a CRL exceeds the publishing period of a CRL by 10% (up to a 12-hour maximum) to allow for directory replication. For more information about revoking certificates and publishing CRLs, see Related Topics.

Related Topics


Specify certificate revocation list distribution points in issued certificates

To specify certificate revocation list distribution points in issued certificates

  1. Log on to the system as an Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the certification authority.

    Where?

    • Certification Authority (where)
    • CA name
  4. On the Action menu click Properties.
  5. On the Policy Module tab, click Configure.
  6. On the X.509 Extensions tab, under CRL Distribution Points, specify the distribution points.
    To | Do this
    Add a new certificate revocation list (CRL) distribution point. | Click Add, and type in the name of the new CRL distribution point.
    Remove a CRL distribution point from the list. | Click the CRL distribution point, then click Remove.
    Indicate that you do not want to use a URL as a CRL distribution point. | Clear the URL's check box.
    Indicate that you want to use a URL as a CRL distribution point. | Select the URL's check box.
  7. Stop and restart the Certificate Services service.

Notes

  • To open Certification Authority, click Start, point to Programs, point to Administrative Tools, and then click Certification Authority.

  • Certificate revocation list URLs can be either HTTP, FTP, LDAP, or FILE addresses. You can use the following variables when specifying the address of the CRL distribution point.

    Variable | Value
    %1 | The DNS name of the certification authority server
    %2 | The NetBIOS name of the certification authority server
    %3 | The name of the certification authority
    %4 | The renewal extension of the certification authority
    %5 | The location of the domain root in Active Directory
    %6 | The location of the configuration container in Active Directory
    %7 | The "sanitized" name of the certification authority, truncated to 32 characters with a hash on the end
  • To stop and restart the Certificate Services service, see Related Topics.

Related Topics


Manually publish the certificate revocation list

To manually publish the certificate revocation list

  1. Log on to the system as an Administrator.
  2. Open Certification Authority.
  3. In the console tree, click on Revoked Certificates.

    Where?

    • Certification Authority (computer)
    • CA name
    • Revoked Certificates
  4. On the Action menu, point to All Tasks, and click Publish.
  5. Click Yes to overwrite the previously published certificate revocation list (CRL).

Notes

  • To open Certification Authority, click Start, point to Programs, point to Administrative Tools, and then click Certification Authority.
  • Clients that have a cached copy of the previously published CRL will continue using it until its validity period has expired even though a new CRL has been published. Manually publishing a CRL does not affect cached copies of CRLs that are still valid; it only makes a new CRL available for systems that do not have a valid CRL.

    See Related Topics for the procedure clients can use to get the most recent CRL published by the certification authority (CA) even if they still have a valid CRL cached.

  • On the server on which the CA is installed, the CRL is published in:

    Systemroot\system32\CertSrv\CertEnroll\

    If Active Directory is available, the CRL is also published to Active Directory.

Related Topics


View the certificate revocation list

To view the certificate revocation list

  1. Log on to the system as an Administrator.
  2. Open Certification Authority.
  3. In the console tree, click Revoked Certificates.

    Where?

    • Certification Authority (computer)
    • CA name
    • Revoked Certificates
  4. On the Action menu, click Properties.
  5. Click View Current CRL.
  6. Click the Revocation List tab.

Notes

  • To open Certification Authority, click Start, point to Programs, point to Administrative Tools, and then click Certification Authority.

Related Topics


Manage certificate requests on a stand-alone certification authority

  • Review pending certificate requests
  • Set the default action upon receipt of a certificate request


Review pending certificate requests

To review pending certificate requests

  1. Log on to the system as an Administrator.
  2. Open Certification Authority.
  3. In the console tree, click Pending Requests.

    Where?

    • Certification Authority (computer)
    • CA name
    • Pending Requests
  4. In the details pane, examine the certificate request by noting the values for requester name, requester e-mail address, and any other fields that you consider critical information for issuing the certificate.
  5. To | Do this
    Reject the certificate request | Click the certificate request and on the Action menu, point to All Tasks, click Deny, and then click Yes.
    Issue the certificate | Click the certificate request and on the Action menu, point to All Tasks, and then click Issue.

Notes

  • To open Certification Authority, click Start, point to Programs, point to Administrative Tools, and then click Certification Authority.
  • This procedure applies only to stand-alone certification authorities (CAs) that are configured to have every incoming certificate request marked as pending.

Related Topics


Set the default action upon receipt of a certificate request

To set the default action upon receipt of a certificate request

  1. Log on to the system as an Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (computer)
    • CA name
  4. On the Action menu, click Properties.
  5. On the Policy Module tab, click Configure.
  6. To | Do this
    Have the certification authority administrator review every certificate request before issuing a certificate. | Click Set the certificate request status to pending.
    Have the certification authority always issue a certificate upon receiving a certificate request. | Click Always issue the certificate.
  7. Stop and restart the Certificate Services service.

Caution

  • In most cases, for security reasons, it is strongly recommended that all incoming certificate requests to a stand-alone CA be marked as "pending". Unlike enterprise CAs, stand-alone CAs do not use Active Directory, even if it is available, to verify that an individual or computer is authorized to be issued a certificate from the CA automatically. For stand-alone CA's, the CA administrator is responsible for verifying the identity of the certificate requestor.

Notes

  • To open Certification Authority, click Start, point to Programs, point to Administrative Tools, and then click Certification Authority.
  • This procedure applies only to stand-alone CAs. You cannot change the default action of enterprise certification authorities upon the receipt of a certificate request.
  • If you change the setting from Set the certificate request status to pending to Always issue the certificate, this will apply only to certificate requests submitted to the CA after the default action has been changed. If there are pending requests held by the CA, these requests will stay pending until the CA administrator issues the certificates or denies the requests.
  • To review pending certificate requests, see Related Topics.
  • To stop and restart the Certificate Services service, see Related Topics.

Related Topics


Manage certificate templates for an enterprise certification authority

  • Set security permissions and delegate control of certificate templates
  • Establish the certificate types an enterprise certification authority can issue


Set security permissions and delegate control of certificate templates

To set security permissions and delegate control of certificate templates

  1. Log on to the system as an Administrator.
  2. Open Active Directory Sites and Services.
  3. In the console tree, click Active Directory Sites and Services.
  4. On the View menu, click Show Services Node.
  5. In the console tree, click Certificate Templates.

    Where?

    • Active Directory Sites and Services
    • Services
    • Public Key Services
    • Certificate Templates
  6. For each certificate template for which you want to set security permissions:
    1. Click the certificate template in the details pane and on the Action menu, click Properties.
    2. Click Security and set the security permissions accordingly.

Notes

  • To open Active Directory Site and Services, click Start, point to Programs, point to Administrative Tools, and then click Active Directory Sites and Services.
  • These changes will apply only to certificate templates in the current domain.
  • Although there are nodes entitled Certification Authorities and Enrollment Services also under Public Key Services, you should not change the default security permissions for the objects in these containers. Instead, all security permissions for each certification authority (CA) should be set from Certification Authority. See Related Topics.
  • For general information about setting access control security permissions, see Related Topics.

Related Topics


Establish the certificate types that an enterprise certification authority can issue

To establish the certificate types that an enterprise certification authority can issue

  1. Log on to the system as an Administrator.
  2. Open Certification Authority.
  3. In the console tree, click Policy Settings.

    Where?

    • Certification Authority (computer)
    • CA name
    • Policy Settings
  4. To | Do this
    Issue additional certificate types from the certification authority. | On the Action menu, point to New, and then click Certificate to Issue. Click the new certificate template to use and click OK.
    Stop issuing a specific certificate type from the certification authority. | In the details pane, click the certificate template you no longer want to issue from this CA. On the Action menu, click Delete.

Notes

  • To open Certification Authority, click Start, point to Programs, point to Administrative Tools, and then click Certification Authority.
  • This procedure applies only to enterprise certification authorities. Stand-alone certification authorities do not use certificate templates.

Related Topics


Change policy settings of a certification authority

  • Publish certificates to Active Directory
  • Publish certificates to the file system
  • Specify CA certificate access points in issued certificates


Publish certificates to Active Directory

To publish certificates to Active Directory

  1. Log on to the system as an Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (computer)
    • CA name
  4. On the Action menu, click Properties.
  5. On the Exit Module tab, click Configure.
  6. On the Certificate Publication tab, select the Allow certificates to be published in the Active Directory check box, and then click OK.
  7. Stop and restart the Certificate Services service.

Notes

  • To open Certification Authority, click Start, point to Programs, point to Administrative Tools, and then click Certification Authority.
  • The server on which the CA is installed must be a member of the Certificate Publishers group in Active Directory to publish certificates in a domain. The server is automatically a member of the Certificate Publishers group for the domain of which it is a member.
  • Publishing certificates to Active Directory is the default setting for the CA if you have Active Directory available.
  • To stop and restart the Certificate Services service, see Related Topics.

Related Topics


Publish certificates to the file system

To publish certificates to the file system

  1. Log on to the system as an Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (computer)
    • CA name
  4. On the Action menu, click Properties.
  5. On the Exit Module tab, click Configure.
  6. On the Certificate Publication tab, select the Allow certificates to be published to the file system check box, and then click OK.
  7. Stop and restart the Certification Authority service.

Notes

  • To open Certification Authority, click Start, point to Programs, point to Administrative Tools, and then click Certification Authority.
  • Publishing certificates to the file system is turned off by default for the CA if you have Active Directory available. It is turned on by default if you do not have Active Directory.
  • To stop and restart Certificate Services, see Related Topics.
  • To request a certificate and have it published to the file system, the cerificate requestor must include an attribute of the form certfile:filename in their request. After the certificate is issued, it will be copied to filename.
    • The file will be written in the CertEnroll share on the CA.
    • Any paths included in the filename will be removed.
    • You cannot overwrite files using this method.
    • If an invalid or existing filename is given, no file will be written and an error will be written in the event log.

Related Topics


Specify CA certificate access points in issued certificates

To specify CA certificate access points in issued certificates

  1. Log on to the system as an Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (computer)
    • CA name
  4. On the Action menu, click Properties.
  5. On the Policy Module tab, click Configure
  6. On the X.509 extensions tab, under Authority Information Access, specify the locations from which users can obtain the certificate for this CA.
    To | Do this
    Add a URL that will be published as part of any certificate issued by a CA. | Click Add, then type a URL where users can obtain the CA's certificate.
    Remove an authority information URL from the list on issued certificates. | Click the URL and then click Remove.
    Indicate that that you do not want to use a URL as an authority information access point in certificates without removing it from the list. | Clear the URL's check box.
    Indicate that a URL can now be used as an authority information access point. | Select the URL's check box.
  7. Stop and restart the Certificate Services service.

Notes

  • To open Certification Authority, click Start, point to Programs, point to Administrative Tools, and then click Certification Authority.

  • Authority information access URLs can be either HTTP, FTP, LDAP, or FILE addresses. You can use the following variables when specifying the address of the authority information access point:

    Variable | Value
    %1 | The DNS name of the certification authority server
    %2 | The NetBIOS name of the certification authority server
    %3 | The name of the certification authority
    %4 | The renewal extension of the certification authority
    %5 | The location of the domain root in Active Directory
    %6 | The location of the configuration container in Active Directory
    %7 | The "sanitized" name of the certification authority, truncated to 32 characters with a hash on the end
  • To stop and restart the Certificate Services service, see Related Topics.

Related Topics


Map Certificates to User Accounts

  • Map a certificate to a user account in Internet Information Services (IIS)
  • Map a certificate to a user account in Active Directory


Map a certificate to a user account in Internet Information Services (IIS)

To map a certificate to a user account in Internet Information Services (IIS)

  1. Log on to the IIS server as an Administrator.
  2. See Mapping Client Certificates to User Accounts in the IIS 5.0 documentation. (http://localhost/iishelp/iis/htm/core/iimapsc.htm)

Note

  • The main menu of IIS 5.0 documentation can be found at http://localhost/iishelp. You must have IIS installed to have access to the documentation.

Related Topics


Map a certificate to a user account in Active Directory

To map a certificate to a user account in Active Directory

  1. Log on to the system as an Administrator.
  2. Open Active Directory Users and Computers.
  3. Click on Active Directory Users and Computers. On the View menu, click Advanced Features to put a check mark next to it (if it is not already checked).
  4. Double-click the domain name in the console tree.
  5. Do one of the following:
    • Click Users.
    • Click the container where the user account is located

      Where?

      • Active Directory Users and Computers
      • domain
      • user container
  6. In the details pane, click the user account to which you want to map a certificate.
  7. On the Action menu, click Name Mappings. On the X.509 Certificates tab in the Security Identity Mapping window click Add.
  8. Type the name and path of the .cer file that contains the certificate you want to map to this user account, then click Open.
  9. Do one of the following:
    To | Do this
    Map the certificate to one account (one-to-one mapping) | Confirm that both the Use Issuer for alternate security identity and the Use Subject of alternate security identity check boxes are selected.
    Map any certificate that has the same subject to the user account, regardless of the issuer of the certificate (many-to-one mapping) | Clear the Use Issuer for alternate security identity check box and confirm that the Use Subject of alternate security identity check box is selected.
    Map any certificate to that has the same issuer to the user account, regardless of the subject of the certificate (many-to-one mapping) | Clear the Use Subject of alternate security identity check box and confirm that the Use Issuer for alternate security identity check box is selected.

Notes

  • To open Active Directory Users and Computers, click Start, point to Programs, point to Administrative Tools, and then click Active Directories Users and Computers.
  • The certificate you are mapping to a user account must be in DER or Base64 encoded binary format. See Related Topics for instructions on exporting an existing certificate to a .cer file.
  • If Name Mappings does not appear on the Action menu, it is because you don't have Advanced Features checked in the View menu.

Related Topics


Change the policy or exit modules of a certification authority

  • Select a different policy module
  • Select a different exit module


Select a different policy module

To select a different policy module

  1. Log on to the system as an Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (computer)
    • CA name
  4. On the Action menu, click Properties.
  5. On the Policy Module tab, click Select
  6. Click the new policy module, and then click OK.
  7. If the policy module has its own configuration interface, you can configure it by clicking Configure.
  8. Stop and restart the Certificate Services service.

Notes

  • To open Certification Authority, click Start, point to Programs, point to Administrative Tools, and then click Certification Authority.
  • To register a new policy module so that it is available in the list of policy modules, refer to the Microsoft Platform Software Development Kit.
  • To stop and restart the Certificate Services service, see Related Topics.

Related Topics


Select a different exit module

To select a different exit module

  1. Log on to the system as an Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (computer)
    • CA name
  4. On the Action menu, click Properties.
  5. On the Exit Module tab, click Select
  6. Click the new exit module and then click OK.
  7. If the exit module has its own configuration interface, you can configure it by clicking Configure.
  8. Stop and restart the Certificate Services service.

Notes

  • To open Certification Authority, click Start, point to Programs, point to Administrative Tools, and then click Certification Authority.
  • To register a new exit module so that it is available in the list of exit modules, refer to the Microsoft Platform Software Development Kit.
  • To stop and restart the Certificate Services service, see Related Topics.

Related Topics


Concepts

Certificate Services and the Certification Authority snap-in provide a way for organizations to set up and manage a certification authority (CA) on a server for use in a public key infrastructure (PKI).

  • Certificate Services overview
  • Understanding Certificate Services
  • Using Certificate Services
  • Resources: Public key infrastructure


Certificate Services overview

Certificate Services provides customizable services for issuing and managing certificates used in software security systems employing public key technologies. For background information about public key cryptography and the benefits of having a public key infrastructure (PKI), see Public key infrastructure.

You can use Certificate Services in Windows 2000 to create a certification authority (CA) which will receive certificate requests, verify the information in the request and the identity of the requester, issue certificates, revoke certificates, and publish a certificate revocation list (CRL).

For more information about CAs, see Certification authorities

Certificate Services can also be used to:

  • Enroll users for certificates from the CA using the Web or the Certificates snap-in, depending upon the policy used by the CA.
  • Use certificate templates to help simplify the choices a certificate requester has to make when requesting a certificate, depending upon the policy used by the CA.
  • Take advantage of Active Directory for publishing trusted root certificates, publishing issued certificates, and publishing CRLs.
  • Implement the ability to log on to a Windows domain using a smart card.

Policy modules

A policy module in Certificate Services is like a set of instructions or rules that a CA uses when processing certificate requests, issuing certificates, revoking certificates, and publishing CRLs.

When you install Certificate Services, you have the choice of using one of two different CA policies, each of which causes the CA to have different characteristics and behavior. You choose the policy you want to use, based on how you need the CA to behave, given its role in your public key infrastructure. (Note that these policies have nothing to do with Windows 2000 Group Policy.) The two Certificate Services policies included with Windows 2000 are referred to as enterprise policy and stand-alone policy.

In this documentation, a CA using the enterprise policy will be referred to as an enterprise CA. A CA using the stand-alone policy will be referred to as a stand-alone CA. You select the policy a CA will use when you install Certificate Services.

Additionally, you can set up up a stand-alone CA and then replace the stand-alone policy with your own custom policy module. For more information about policy modules see Policy and exit modules. For information about creating custom policy modules for Certificate Services, see the Microsoft Platform Software Development Kit.

Processing certificate requests

A user can request certificates from an enterprise or stand-alone CA using Internet Explorer 3.0 or later or a browser such as Netscape Navigator 3.0 or later. In addition, a user can use the Certificates snap-in to request a certificate from an enterprise CA. (At a base program level, all requests for certificates are submitted to a CA via a remote procedure call (RPC) or through DCOM.)

Typically, when a user initiates a certificate request, a cryptographic service provider (CSP) on their computer generates a public key and private key pair for the user. The user's public key is sent with their necessary identifying information to the CA. If the user's identifying information meets the CA criteria for granting a request, the CA generates the certificate, which is retrieved by the client application and stored locally. For more information about certificates, see Understanding Certificates.

Security considerations for CAs

CAs are valuable resources, and you should provide them with a high degree of protection. Specific actions that should be considered include:

  • Physical protection. Since CAs represent highly-trusted entities within an enterprise, you should protect them from tampering, depending on the inherent value of the certification made by the CA. Physical isolation of the CA server, in a facility accessible only to security administrators, can dramatically reduce the possibility of such attacks.
  • Restoration. A CA might be lost if there is a hardware failure. This can create a number of administrative and operational problems, and can prevent revocation of existing certificates. Certificate Services supports the backup of a CA so that it can be restored at a later time. This is an important part of the overall CA management process.
  • Key management. The CA's keys are its most valuable asset, because the private key provides the basis for trust in the certification process. Other cryptographic hardware modules can provide tamper-resistant key storage and isolate the cryptographic operations from other software running on the server. This reduces the likelihood of a CA key being compromised. Certificate Services supports cryptographic service providers (CSPs) from other sources, but the documentation included with Windows 2000 is specific to the software CSPs that are included with Windows 2000. If you use a CSP from another source, you should confirm with the vendor that the CSP can work with Certificate Services. You will also need supplementary documentation from the vendor to explain how to operate Certificate Services with their CSP.

Customizing Certificate Services

Certificate Services includes programmable interfaces so that developers can create support for additional transports, policies, and certificate properties and formats. Refer to the Microsoft Platform Software Development Kit for information about customizing Certificate Services.

For more information about Certificate Services, see Understanding Certificate Services


Understanding Certificate Services

  • Processing certificate requests
  • Certificate revocation
  • Certificate templates
  • Policy and exit modules
  • Certification authority hierarchies
  • Certification authority database
  • Certification authority Web enrollment services
  • Interoperability in Certificate Services
  • Certification authorities


Processing certificate requests

A Windows 2000 certification authority (CA) performs the following operations when processing a certificate request:

  1. Request reception. The certificate request is sent by the client application (such as the Certificate Request wizard in the Certificates snap-in), which formats it into a PKCS #10 format request and submits it to the CA.
  2. Request approval. The CA server engine calls the CA policy module, which queries the request properties, decides whether the request is authorized or not, and sets optional certificate properties.
  3. Certificate formation. If the request is approved, the CA server engine takes the request, and any properties requested by the policy module, and builds a complete certificate.
  4. Certificate publication. The CA server engine stores the completed certificate in its certificate database and notifies the intermediary application of the request status. If the exit module has requested it, the server engine notifies it of a certificate issuance event. This allows the exit module to perform further operations, such as publishing the certificate to Active Directory. Meanwhile, the client application gets the published certificate from the certificate database and saves it in its own local certificate store.


Certificate revocation

Revocation of a certificate invalidates a certificate as a trusted security credential prior to the natural expiration of its validity period. There are a number of reasons why a certificate, as a security credential, could become untrustworthy prior to its expiration. Examples include:

  • Compromise, or suspected compromise, of the certificate subject's private key.
  • Discovery that a certificate was obtained fraudulently.
  • Change in the status of the certificate subject as a trusted entity.

A public key infrastructure (PKI) depends on distributed verification of credentials in which there is no need for direct communication with the central trusted entity that vouches for the credentials. This creates a need to distribute certificate revocation information to individuals, computers, and applications attempting to verify the validity of certificates. The need for revocation information and its timeliness will vary, according to the application and its implementation of certificate revocation checking.

To support a variety of operational scenarios, Certificate Services incorporates support of industry-standard certificate revocation lists (CRLs) to distribute information about revoked certificates. Windows 2000 certification authorities (CAs) support certificate revocation and publication of the CRL to Active Directory. Clients can fetch the CRL from a CA and then keep it in a local cache to use when verifying certificates issued by that CA. This same mechanism supports CRLs published by commercial CAs, or other certificate services products, provided the published CRLs are accessible to clients via the network.

For conceptual information about using certificate revocation in Certificate Services, see Revoking certificates and publishing CRLs. For procedures to manage certificate revocation, see Manage Certificate Revocation.


Certificate templates

A certificate template profiles certificates based on their intended use. When requesting a certificate from a Windows 2000 enterprise certification authority (CA), the certificate requester will, depending on their access rights, be able to select from a variety of certificate types that are based on certificate templates, such as User and Code Signing. The certificate template saves users from low-level, technical decisions about the type of certificate that they need. Instead, they can rely on the judgement of their administrators and use the template name that indicates the purpose of the certificate.

The following certificate templates are included with Windows 2000 Certificate Services.

    Certificate Template Name | Certificate Purposes | Issued To People or Computers
Administrator | Code signing, certificate trust list (CTL) signing, encrypting file system (EFS), Secure E-mail, Client Authentication | People
Authenticated session | Client authentication | People
Basic EFS | Encrypting File System | People
Computer | Client authentication, server authentication | Computers
Code Signing | Code signing | People
Domain Controller | Client authentication, server authentication | Computers
EFS Recovery Agent | File recovery | People
Enrollment Agent | Certificate request agent | People
Enrollment Agent (Offline request) | Certificate request agent | People
IPSec (Offline request) | Internet Protocol security | Computers
IPSec | Internet Protocol security | Computers
Router (Offline request) | Client authentication | Computers/routers
Smart Card Logon | Client authentication | People
Smart Card User | Client authentication, secure e-mail | People
Subordinate certification authority | All | Computers
Trust List Signing | Certificate trust list signing | People
User | Encrypting File System, secure e-mail, client authentication | People
User Signature Only | Secure e-mail, client authentication | People
Web Server | Server authentication | Computers

Every enterprise CA, as part of its policy settings, can issue specific certificate types based on certificate templates selected by the CA administrator. When you install a new enterprise CA, by default, only the following certificate templates can be issued: Administrator, Domain Controller, Computer, Basic EFS, EFS Recovery Agent, User, Web Server. For the procedure to add or remove certificate templates that a CA can issue, see Establish the certificate types that an enterprise certification authority can issue

Certificate templates have the following features:

  • Security permission set

    Indicates who is allowed to receive a certificate of this type. This decision is enforced by the CA, and requires that the certificate requester securely authenticate itself to the CA. See Set security permissions and delegate control of certificate templates for procedures to set security permissions on certificate templates.

  • Display Name

    The name that is displayed in the user interface when the client or administrator selects a certificate template.

  • Extended Key Usages

    Identifies the purpose of the certificate, such as e-mail protection, CTL signing, and so on. It is represented by Object Identifiers (OIDS).

  • Key Usages

    Identifies the use of the public key in a certificate at a basic cryptographic level. Typically, it indicates whether the key may be used for a signature, key exchange, encryption, or other uses. Key Usages is stored as a bit field.

  • Basic Constraints

    Indicates whether the resulting certificate may be used by a CA to sign lower-level certificates, which allows the construction of CA hierarchies. This value also specifies the maximum depth of the hierarchy beneath the certificate.

  • Default CSP List

    Contains the names of the cryptographic service providers (CSPs) that may be used if the enrollment takes place outside of the normal Windows user interface. There are specific constraints on the CSPs used for certain types of certificates, and this list verifies that certificates enrolled by the system will meet those constraints. For example, EFS requires the Microsoft RSA CSP.

  • Include E-Mail Name

    Indicates that the e-mail name of the principal should be included in the certificate, if there is one.

  • Machine Certificate Template

    Indicates whether the certificate template is appropriate for a computer or a user.

For procedures to manage certificate templates, see Manage Certificate Templates for an Enterprise CA


Policy and exit modules

One powerful administrative feature of Certificate Services is the ability to control and customize the behavior of the certification authority (CA) through the use of policy and exit modules.

Policy modules can determine whether a certificate request should be automatically approved, denied, or marked as pending. Exit modules provide an opportunity to perform post-processing after a certificate is issued, such as the publication of an issued certificate to Active Directory.

Certificate Services comes with one exit module (Certxds.dll) and one policy module (Certpdef.dll). The policy module includes two separate policies: enterprise and stand-alone. For information about the operational characteristics of a CA using enterprise policy versus a CA using stand-alone policy, see Enterprise certification authorities and Stand-alone certification authorities.

As a CA administrator, you can replace these default modules with your own custom policy and exit modules or third-party policy and exit modules. In addition, if you have upgraded to Windows 2000 Certificate Services from Certificate Server 1.0, you will have the option of using the policy module you have been using with Certificate Server 1.0. It will be listed as a legacy policy module when you look at the properties of the CA.

The policy module provided with Windows 2000 performs the following functions:

  • Adds certificate revocation list distribution points (CDP) to a certificate being issued. The certificate revocation list (CRL) distribution point is an optional extension in an X.509v3 certificate that is a directory entry or other distribution source for certificate revocation lists. A verifier of a certificate, such as a secure Web site, can use the CRL distribution point address, contained in a certificate, to retrieve a current copy of the issuing CA's CRL in order to insure that the certificate being presented has not been revoked by the CA.
  • Adds authority information access points to a certificate being issued. The authority information access point is an optional extension in an X.509v3 certificate. It serves as a directory entry or other distribution source for the certificate of the certification authority.
  • Determines the default action of a certification authority upon receiving a certificate request. Upon receiving a certificate request, a certification authority can either automatically issue a certificate or hold it as pending until an administrator reviews the request.

    In Windows 2000, an enterprise CA will always immediately either issue a certificate or deny a request. This policy setting cannot be changed for enterprise CAs. Because enterprise certification authorities use Active Directory to determine the identity of the requester and to determine whether the requester has the security permissions to request a certificate of the type that they specify, the CA automatically determines whether a requester is authorized to receive the certificate requested.

    In Windows 2000, a stand-alone certification authority can either issue a certificate automatically upon receiving a request or hold the request as pending. In the majority of instances, the administrator of a stand-alone CA will want to have all incoming certificate requests set to pending. Otherwise, because the stand-alone CA does not verify the identity of requesters via Active Directory, there is no way to verify the identity and validity of the certificate requester.

Please note that this is not an exhaustive list of the functions of the policy module.

The exit module provided with Windows 2000 performs the following functions:

  • Allows certificate publication to Active Directory. If the certificate request specifies a location to publish the certificate in Active Directory, the exit module will do so.
  • Allows certificate publication to the file system. If the certificate request specifies a location to publish the certificate in the file system, the exit module will do so.
  • Publishes certificate revocation lists to specified URLs. The exit module determines where the CA publishes the certificate revocation list .

Please note that this is not an exhaustive list of the functions of the exit module.

To configure the settings of the default policy and exit modules see Configuring the policy and exit modules

Customizing Certificate Services policy and exit modules

Programmable interfaces are included in Certificate Services for developers to create customized policy modules. For more information, refer to the Microsoft Platform Software Development Kit.

If you have created a customized policy module using the guidelines in the Microsoft Platform Software Development Kit, see Select a different policy module to change the policy module.

If you have created a customized exit module using the guidelines in the Microsoft Platform Software Development Kit, see Select a different exit module to change the exit module


Certification authority hierarchies

The Windows 2000 public key infrastructure (PKI) assumes a hierarchical certification authority (CA) model. A certification hierarchy provides scalability, ease of administration, and consistency with a growing number of commercial and other CA products.

In its simplest form, a certification hierarchy consists of a single CA. However, in general, a hierarchy will contain multiple CAs with clearly defined parent-child relationships. In this model, the child subordinate certification authorities are certified by their parent CA-issued certificates, which bind a certification authority's public key to its identity. The CA at the top of a hierarchy is referred to as the root authority or root CA. The child CAs of the root CAs are called subordinate certification authorities (CAs).

In Windows 2000, if you trust a root CA (by having its certificate in your Trusted Root Certification Authorities certificate store), you trust every subordinate CA in the hierarchy, unless a subordinate CA has had its certificate revoked by the issuing CA or has an expired certificate. Thus, any root CA is a very important point of trust in an organization and should be secured and maintained accordingly.

Verification of certificates thus requires trust in only a small number of root CAs. At the same time, it provides flexibility in the number of certificate-issuing subordinate CAs. There are several practical reasons for supporting multiple subordinate CAs, including:

  • Usage. Certificates may be issued for a number of purposes, such as secure e-mail and network authentication. The issuing policy for these uses may be distinct, and separation provides a basis for administering these polices.
  • Organizational divisions. There may be different policies for issuing certificates, depending upon an entity's role in the organization. Again, you can create subordinate CAs to separate and administer these policies.
  • Geographic divisions. Organizations may have entities at multiple physical sites. Network connectivity between these sites may dictate a requirement for multiple subordinate CAs to meet usability requirements.

Such a certification authority hierarchy also provides administrative benefits, including:

  • Flexible configuration of the CA security environment to tailor the balance between security and usability, such as key strength, physical protection, and protection against network attacks. For example, you may choose to employ special-purpose cryptographic hardware on a root CA, operate it in a physically secure area, or operate it offline. These may be unacceptable for subordinate CAs, due to cost or usability considerations.
  • Use of frequent updates for issuing CA keys and certificates, which are most often exposed to compromise, without requiring a change to established trust relationships.
  • The ability to "turn off" a specific portion of the CA hierarchy without affecting the established trust relationships. For example, you can easily shut down and revoke an issuing CA certificate that is associated with a specific geographic site without affecting other parts of the organization.

See Establishing a certification hierarchy


Certification authority database

When you install a certification authority (CA), you create a certification authority database on the server. This database has to be located on an NTFS file system partition on the server's disk drives. You specify the locations for the database during the setup of a CA. By default, the database is located in:

\Systemroot\system32\certlog

The name of the database file is based on the name of the CA, with an .edb extension.

The Certification Authority MMC console provides a view into the certification authority database on a CA and the ability to administer the database.

A certification authority database stores:

  • Every certificate issued by the CA.
  • Every certificate revoked by the CA.
  • Every certificate request received by the CA.
  • Every certificate request rejected by the CA.
  • Every certificate request considered pending by the CA.

You also specify the location of the certificate database log during Certificate Services setup. The certificate database log keeps a record of every transaction involving the certificate database. Certificate database logs are used when restoring the CA from a backup. If a CA is restored from a backup that is one month old, then the certification database logs that have been generated since the last backup can be replayed against the database to restore it to its most current state. When you back up a certification authority, the existing certificate database logs will be truncated in size, because they will no longer be needed to restore the certificate database to its most current state.

For more information about CA backup and restore, see Backing up and restoring a certification authority.


Certification authority Web enrollment services

A set of certification authority (CA) Web pages is provided with Certificate Services in Windows 2000. These Web pages provide a simple user interface to perform many of the common user tasks on a CA, and they are installed by default when you set up Certificate Services.

These Web enrollment pages allow you to connect to the CA via a Web browser, and perform common tasks, such as requesting certificates from a CA, requesting the CA's certificate, submitting a certificate request using a PKCS #10 file, retrieving the CA's certificate revocation list (CRL) or performing smart card certificate enrollment. For a stand-alone CA, the Web pages are the primary way a certificate requester can interface with the CA, since the Certificates snap-in cannot be used to request certificates from a stand-alone CA. Enterprise CAs can accept certificate requests via the Certificates snap-in or the Web enrollment pages.

You can install Web enrollment pages for a CA on a Windows 2000 server that is not a CA in order to divert Web-based traffic from the actual CA. For more information about installing the Web pages on a server that is not a CA, see Set up certification authority Web enrollment support

For more information about using the Web enrollment pages, see Using Windows 2000 Certificate Services Web pages


Interoperability in Certificate Services

By using industry-standard X.509v3 certificate formats and open interfaces, Windows 2000 Certificate Services operates with many products and technologies that support the use of public key cryptography and public key infrastructure (PKI).

Internet standards

PKI standards for the Internet are still evolving as this is being written. However, Certificate Services has been designed to adhere to existing PKI interoperability standards established by the Internet Engineering Task Force (IETF). The IETF working group charged with defining the basis for an interoperable PKI is PKIX. For more information on PKIX, see the PKIX Web page (http://www.ietf.org/html.charters/pkix-charter.html). The Web page also has a link to RFC 2459, "Internet Public Key Infrastructure X.509 Certificate and CRL Profile, Part 1," which is the specification for the basic architecture of PKI. (Web addresses can change, so you may be unable to connect to some of the Web sites mentioned here.)

Public Key Cryptography Standards

There is a set of de facto cryptographic message standards called Public Key Cryptography Standards (PKCS) which are developed and maintained by RSA Laboratories. (For more information, see the RSA Laboratories (http://www.rsa.com/rsalabs/html/standards.html) Web page.)

PKCS provides a basic, but well-understood framework for interoperability. The standards that are most relevant to PKI and ones that are used by Certificate Services are PKCS #7, Cryptographic Message Syntax Standard, and PKCS #10, Certification Request Syntax Standard.

Web servers

On a corporate intranet or on the Internet, Web servers, such as those using Microsoft Internet Information Services (IIS), can perform client authentication for secure communications using certificates generated by Certificate Services. Certificate Services 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.

For more information about IIS and certificates, see Certificates and Internet Information Services (http://localhost/iishelp/iis/htm/core/iicerts.htm).

Web browsers

Certificate Services can be used to issue certificates to Web browsers that support client authentication, such as Microsoft Internet Explorer 3.0 or later.

LDAP directories

The programmability of Certificate Services makes it possible to issue certificates to any directory that is compliant with Lightweight Directory Access Protocol (LDAP). LDAP is a subset of the X.500 DAP standard for directory services. Compliance with LDAP enables Certificate Services to operate with policy tools and other third-party applications that support LDAP directory services.

Microsoft Windows 2000

Windows 2000 enables you to map certificates to Windows 2000 users and groups. This mapping is automatic if the certificate is issued from an enterprise certification authority (CA). You can then use standard Windows 2000 administrative tools, such as security permission sets, to implement Internet and intranet security requirements taking advantage of the relationship established between Windows 2000 domain users and the certificates issued to them.

For more information about mapping certificates in Windows 2000 see Mapping certificates to user accounts.

Microsoft Exchange Server

Microsoft Exchange 5.5 SP1 Key Management Server (KMS) and Exchange 5.5 SP3 KMS can use Windows 2000 Certificate Services for issuing certificates when you install the Exchange policy module on the Windows 2000 CA. (This replaces the stand-alone policy.) The Exchange 5.5 KMS policy module will be listed a "Legacy" policy module in the Certificate Services console. See the documentation for your version of Microsoft Exchange for detailed information about how to use the KMS with this version of Certificate Services.

More interoperability information

For detailed information about interoperability of other products with Windows 2000 Certificate Services, see:

  • Windows 2000 Resource Kits
  • Microsoft Product Support Services


Certification authorities

A certification authority (CA) is an entity entrusted to issue certificates to individuals, computers, or organizations that affirm the identity and other attributes of the certificate subject to other entities. A CA accepts a certificate request, verifies the requester's information according to the policy of the CA, and then uses its private key to apply its digital signature to the certificate. The CA then issues the certificate to the subject of the certificate for use as a security credential within a public key infrastructure (PKI). A CA is also responsible for revoking certificates and publishing a certificate revocation list (CRL).

A CA can be a remote third party, such as VeriSign, or it can be a CA that you create for use by your organization by installing Windows 2000 Certificate Services. Each CA can have distinct proof-of-identity requirements for certificate requesters, such as a Windows 2000 domain account, employee badge, driver's license, notarized request, or physical address. Identification checks such as this often warrant an onsite CA, so that organizations can validate their own employees or members.

Enterprise CAs in Windows 2000 use a person's Windows 2000 user account credentials as proof of identity. In other words, if you are logged on to a Windows 2000 domain and request a certificate from an enterprise CA, the CA knows that you are who Active Directory says you are.

Every CA also has a certificate to confirm its own identity, issued by another trusted CA or, in the case of root CAs, issued by itself. It is important to remember than anyone can create a CA. The real question revolves around whether you, as a user or an administrator, trust that CA and, by extension, the policies and procedures that CA has in place for confirming the identity of the entities issued certificates by that CA.

For more information about certificates, see Certificates overview.

Root and subordinate certification authorities

A root CA, sometimes called a root authority, is meant to be the most trusted type of CA in an organization's PKI. Typically, both the physical security and the certificate issuance policy of a root CA are more rigorous than those for subordinate CAs; if the root CA is compromised or issues a certificate to an unauthorized entity, then any certificate-based security in your organization is suddenly vulnerable. While root CAs can be used to issue certificates to end users for such tasks as sending secure e-mail, in most organizations they will only be used to issue certificates to other CAs, called subordinate CAs.

A subordinate CA is a CA that has been certified by another CA in your organization. Typically, a subordinate CA will issue certificates for specific uses, such as secure e-mail, Web-based authentication, or smart card authentication. Subordinate CAs can also issue certificates to other, more subordinate CAs. Together, a root CA, the subordinate CAs that have been certified by the root, and subordinate CAs that have been certified by other subordinate CAs form a certification hierarchy.

For more information about certification hierarchies, see Certification authority hierarchies.

Enterprise and stand-alone certification authorities

This version of Certificate Services supports the installation of stand-alone CAs and enterprise CAs. For information about the operational characteristics of enterprise CAs and standalone CAs, see Enterprise certification authorities and Stand-alone certification authorities.


Enterprise certification authorities

You can install Certificate Services to create an enterprise certification authority (CA). Enterprise CAs can issue certificates for purposes such as digital signatures, secure e-mail using S/MIME (Secure Multipurpose Internet Mail Extensions), authentication to a secure Web server using Secure Sockets Layer (SSL) or Transport Layer Security (TLS), and logging on to a Windows 2000 domain using a smart card.

An enterprise CA has the following features:

  • An enterprise CA requires Active Directory.
  • When you install an enterprise root CA, it is automatically added to the Trusted Root Certification Authorities certificate store for all users and computers in the domain. You must be a Domain Administrator or be an administrator with write access to Active Directory to install an enterprise root CA.
  • All certificate requests sent to the enterprise CA will be fulfilled or denied based on the policy and security permission set for the certificate type requested. Enterprise CAs never set a certificate request to pending, they immediately either issue the certificate or deny the request.
  • Certificates can be issued for logging on to a Windows 2000 domain using smart cards.
  • The enterprise exit module publishes user certificates and the certificate revocation list (CRL) to Active Directory. In order to publish certificates to Active Directory, the server that the CA is installed on must be a member of the Certificate Publishers group. This is automatic for the domain the server is in, but the CA will need to be delegated the proper security permissions to publish certificates in other domains. For more information about the exit module, see Policy and exit modules.

An enterprise CA uses certificate types, which are based on a certificate template. The following functionality is possible due to the use of certificate templates:

  • Enterprise CAs enforce credential checks on users during certificate enrollment. Each certificate template has a security permission set in Active Directory that determines whether the certificate requester is authorized to receive the type of certificate they have requested.
  • The certificate subject name is automatically generated.
  • The policy module adds a predefined list of certificate extensions to the issued certificate from the certificate template. This reduces the amount of information a certificate requester has to provide about the certificate and its intended use.

For more information, compare Stand-alone certification authorities. For more information about certificate templates, see Certificate templates. For general information about CAs, see Certification authorities.


Stand-alone certification authorities

You can install Certificate Services to create a stand-alone certification authority (CA). Stand-alone CAs can issue certificates for purposes such as digital signatures, secure e-mail using S/MIME (Secure Multipurpose Internet Mail Extensions), and authentication to a secure Web server using Secure Sockets Layer (SSL) or Transport Layer Security (TLS).

A stand-alone CA has the following characteristics:

  • Unlike an enterprise CA, a stand-alone CA does not require the use of Active Directory. Stand-alone CAs are primarily intended to be used when extranets and the Internet are involved. Additionally, if you want to use a custom policy module for a CA, you would first install a stand-alone CA and then replace the stand-alone policy module with your custom policy module.
  • When submitting a certificate request to a stand-alone CA, a certificate requester must explicitly supply all identifying information about himself or herself and the type of certificate desired in the certificate request. (This does not need to be done when submitting a request to an enterprise CA, since the enterprise user's information is already in Active Directory and the certificate type is described by a certificate template).
  • By default, all certificate requests sent to the stand-alone CA are set to pending until the administrator of the stand-alone CA verifies the identity of the requester and okays the request. This is done for security reasons, because the certificate requester's credentials are not verified by the stand-alone CA.
  • Certificate templates are not used.
  • No certificates can be issued for logging on to a Windows 2000 domain using smart cards, but other types of certificates can be issued and stored on a smart card.
  • The administrator has to explicitly distribute the stand-alone CA's certificate to the domain user's trusted root store or users must perform that task themselves.
When a stand-alone CA uses Active Directory, it has these additional features:
  • If a member of the Domain Administrators group or an administrator with write access to Active Directory, installs a stand-alone root CA, it is automatically added to the Trusted Root Certification Authorities certificate store for all users and computers in the domain. For this reason, if you install a stand-alone root CA in an Active Directory domain, you should not change the default action of the CA upon receiving certificate requests (which marks requests as pending). Otherwise, you will have a trusted root CA that automatically issues certificates without verifying the identity of the certificate requester.

  • If a stand-alone CA is installed by a member of the Domain Administrators group of the parent domain of a tree in the enterprise, or by an administrator with write access to Active Directory, then the stand-alone CA will publish certificates and the certificate revocation list (CRL) to Active Directory.

For more information, compare Enterprise certification authorities. For general information about CAs, see Certification authorities.


Using Certificate Services

  • Installing and configuring a certification authority
  • Configuring the policy and exit modules
  • Establishing a certification hierarchy
  • Backing up and restoring a certification authority
  • Revoking certificates and publishing CRLs
  • Mapping certificates to user accounts
  • Renewing a certification authority
  • Certificate Services command line functions


Installing and configuring a certification authority

Planning the installation of a certification authority

Before installing Certification Services, you should plan the deployment of certification authorities (CAs) and public key infrastructure in your organization.

For more information about deploying a PKI, see Checklists, Resources: Public key infrastructure, Windows 2000 Resource Kits, and Microsoft Product Support Services.

Ways to install Certificate Services to create a certification authority

If you are installing Certificate Services on a Windows 2000 Server, there are a number of situations in which you may want to set up a CA. (The most typical is listed first here.)

  • After Windows 2000 Server base setup has completed:

    To install Certificate Services on a server that already has Windows 2000 Server installed, double-click Add/Remove Programs in Control Panel. After you select Certificate Services for installation, the Certificate Services Installation wizard guides you through the installation process.

    For the procedures to set up a certification authority (CA) on a server that already has Windows 2000 installed, see Set up a certification authority.

  • As part of Windows 2000 Server base setup:

    Although Certificate Services is a Windows 2000 service and is included with Windows 2000 Server, it is not installed as part of the initial Windows 2000 Server installation process by default. (You would not want every file server to be a CA.)

    To install Certificate Services during the initial base installation of Windows 2000 Server, you must select it from the optional components list that is displayed during setup. Certificate Services will not actually be installed until you log on to the server after the Windows 2000 setup has completed. Then, a message will prompt you to complete the setup of the CA.

  • Upgrading from Certificate Server 1.0:

    See Upgrading Certificate Server 1.0.

  • As part of the unattended installation of a Windows 2000 Server:

    Certificate Services can be installed as part of an unattended installation of a Windows 2000 server. For information about unattended installation of Windows 2000, see Planning for unattended setup.

Setup options and information

When you set up Certificate Services, you will be prompted for the following information:

Certification authority type selection

During the Certificate Services installation, you can choose to set up any of the following types of certification authority (CA):

Certification Authority (CA) Type | Description
Enterprise root CA | An enterprise root CA is a top-level CA in a certification hierarchy. An enterprise root CA requires Active Directory. It self-signs its own CA certificate and publishes that certificate to the Trusted Root Certification Authorities store of all Windows 2000 servers and workstations in the domain. For more information, see Enterprise certification authorities
Enterprise subordinate CA | An enterprise subordinate CA must obtain its CA certificate from another CA. An enterprise subordinate CA requires Active Directory. You would use enterprise subordinate CAs when you want to take advantage of Active Directory, certificate templates, and smart card logon to Windows 2000 computers
Stand-alone root CA | A stand-alone root CA is a top-level CA in a certification hierarchy. The stand-alone root CA may or may not be a member of a domain and, therefore, does not require Active Directory. However, it will use Active Directory if it exists. Since a stand-alone root CA doesn't require Active Directory, it can easily be disconnected from the network and placed in a secure area, which is useful when deciding to create a secure offline root CA. For more information, see Stand-alone certification authorities
Stand-alone subordinate CA | A stand-alone subordinate CA must obtain its CA certificate from another CA. The stand-alone subordinate CA may or may not be a member of a domain and, therefore, does not require Active Directory. However, it will use Active Directory if it exists. It must obtain its CA certificate from another CA.
Advanced Options: cryptographic service providers, key lengths, hash algorithms

If you enable advanced options when you choose the type of CA to install, you can select the cryptographic service provider (CSP) to use. The CSP generates the public key and private key pair and performs cryptographic operations on behalf of the CA.

In advanced options, you also can set the key length for the public key cryptographic keys that the CA uses to sign certificates. In general, the longer the key length, the more secure it is. Note that a longer key will take longer time to generate during setup.

In advanced options, you can also choose the message hash algorithm used by the CA, as well as specifying the use of existing cryptographic keys instead of generating new ones.

Certification authority identifying information

The following are some guidelines for completing the CA identifying information in Certificate Services setup:

Field | Description
CA Name The name you want to give to the CA. You can enter a string using almost any character. The name of the CA will also be the common name of the CA's distinguished name in Active Directory.

When special characters exist in the CA name, a sanitized CA name is used for operations that are unable to use the unmodified CA name. A CA's sanitized name is the name of the CA with all special characters encoded in a form that will allow them to be used for file names, CryptoAPI (CAPI) key container names, and Active Directory object names. Special characters are those characters that cannot be used in one or more of these names; the list includes all characters which are not ASCII characters and many ASCII punctuation characters.

Further, Active Directory object names are limited to 64 characters by the LDAP standard. To accommodate this limit, Active Directory object names are constructed by truncating the sanitized name and appending a hash computed over the truncated part of the sanitized name.

Run certutil.exe at a command line prompt without arguments to see the sanitized name for all of the published CAs. Run certutil.exe -v -ds to see all of the CA-related Active Directory names. The first column is a truncated CA name with the hash appended (the actual Active Directory objects's container name, with special characters reverted back to their original form). A second column is displayed only if the truncated, sanitized name does not match the truncated CA name, and it is the actual Active Directory object's container name.

Organization | The legal name of your organization that is registered with the appropriate state, country/region, or city authority.
Organizational Unit | Can be used to differentiate between different divisions within an organization, for example, Internet Security Unit or Human Resources. If your business has a different name from its parent organization, you can use that name here.
Locality | The city that the organization resides in.
State or Province | The physical location of the organization.
Country | A two-character country/region code, as required by the X.500 Naming Scheme standard. For example, the country/region code for the United States is US, and the code for Canada is CA.
Database and Configuration Storage

Certificate Services uses local storage for its database, configuration data, backup data and logging data. You can specify locations for the database and log during CA setup. By default, the certificates issued by a CA are stored in:

\Systemroot\system32\certlog

You also have the option of specifying a shared folder when setting up a CA. The shared folder acts as a location where computer users can find information about certification authorities. This option is only useful if you are installing a stand-alone CA and do not have Active Directory.

If the host computer for Certificate Services is a member of a domain, information about the CA is automatically published to the Active Directory. However, the Active Directory does not act as the database for Certificate Services. This function remains with the local computer.

(Optional) Creating an issuer policy statement for the CA

When you set up a CA, you can add a CA policy statement to the CA certificate that is created during setup or a CA certificate renewal, in the form of text or a pointer to a Web site. The CA policy statement gives legal and other pertinent information about the CA and its issuing policies, limitations of liability, and so on. An end user will see this CA policy statement when they view the CA certificate and click Issuer Statement.

Here are the steps you need to follow to attach a policy statement to a CA's certificate:

  1. The policy statement file must be installed on the Windows 2000 server before you set up Certificate Services. This file, named CAPolicy.inf, must be placed in the systemroot directory. URLs in CAPolicy.inf should use the replaceable parameter syntax that also appears in the policy module configuration screen. If you don't use the replaceable parameter syntax, then CDP and AIA extensions in renewed CA root certificates may point to the same location that was specified in the previous CA root certificate. See Specify certificate revocation list distribution points in issued certificates to see the replaceable parameter syntax.

  2. The first two lines of CAPolicy.inf must be:

    [Version]
    Signature="$Windows NT$"

  3. The next two lines of the file list the name of the policies for this CA. Multiple policies can be listed in Policies= if they are separated by commas. The name LegalPolicy is used here as an example, but the name can be whatever the CA administrator chooses when creating CAPolicy.inf:

    [CAPolicy]
    Policies=LegalPolicy

  4. For each policy, you need to provide a user-defined object identifier and either the text you want displayed as the policy statement or a URL pointer to the policy statement. (The URL can be in the form of an HTTP, FTP, file, or LDAP address.) Continuing on with the example, if you are going to have text in the policy statement, the next three lines of CAPolicy.inf will read:

    [Legal Policy]
    OID=1.1.1.1.1.1.1.1.1
    Notice="Legal policy statement text"

    If you are going use a URL to host the CA policy statement, the next three lines would instead read:

    [Legal Policy]
    OID=1.1.1.1.1.1.1.1.1
    URL="http:://CompanyWebSite/CAPolicy/default.asp"

    (Please note that the "OID=" entry used in this example is arbitrary and is shown only for illustrative purposes.)

    Additional notes:

    • Multiple URLs are supported
    • Multiple notices are supported
    • Mixed notices and URLs are supported
    • URLs with spaces or text with spaces must be surrounded by quotes

    An example of multiple notices and URLs in a policy section might be:

    [Legal Policy]
    OID=1.1.1.1.1.1.1.1.1
    URL = "http://http.site.com/somewhere/default.asp"
    URL = "ftp://ftp.site.com/somewhere else/default.asp"
    Notice = "Legal policy statement text."
    URL = "ldap://ldap.site.com/somewhere else again/default.asp"

  5. You can specify CRL Distribution Points (CDPs) in CAPolicy.inf. Note that any CDP in CAPolicy.inf will take precedence for certificate verifiers over the CDP's specified in the CA policy module. If you want to specify the CDP using CAPolicy.inf, a sample of the syntax is:

    [CRLDistributionPoint]
    URL="http:://CompanyWebSite/Public/myCA.crl"

    Some additional notes about the CRL section:

    • Multiple URLs are supported.
    • HTTP, file, FTP, and LDAP URLs are supported.
    • This section can be used during CA setup or CA certificate renewal.
    • This section is only used if you are setting up a root CA or renewing a root CA certificate. Subordinate CA CRL distribution point extensions are determined by the CA which issued the subordinate CA's certificate.
    • URLs with spaces must be surrounded by quotes.

    • If no URLs are specified(in other words, if the [CRLDistributionPoint] section is empty), the default CRL Distribution point extension will be suppressed.

  6. You can specify the authority information access points in CAPolicy.inf. The syntax is:

    [AuthorityInformationAccess]
    URL="http:://CompanyWebSite/Public/myCA.crl"

    Some additional notes about the authority information access section:

    • Multiple URLs are supported.
    • HTTP, file, FTP, and LDAP URLs are supported.
    • This section can be used during CA setup or CA certificate renewal.
    • This section is only used if you are setting up a root CA or renewing a root CA certificate. Subordinate CA authority information access extensions are determined by the CA which issued the subordinate CA's certificate.

    • If no URLs are specified (in other words, if the [AuthorityInformationAccess] section is empty), the default authority information access extension will be suppressed.

  7. Another optional section of CApolicy.inf is [EnhancedKeyUsage], which is used to specify EnhancedKeyUsage extension OIDs.

    • Multiple OIDs are supported.
    • This section can be used during CA setup or CA certificate renewal.
    • This section is only used if you are setting up a root CA or renewing a root CA certificate. The EnhancedKeyUsage extension for a subordinate CA is determined by the CA which issued the subordinate CA's certificate.

    An example of this section is:

    [EnhancedKeyUsage]
    OID=1.2.3.4.5
    OID=1.2.3.4.6

  8. Another optional section of CApolicy.inf is [certsrv_server], which is used to specify renewal key length, the renewal validity period, and renewal validity period units for a CA that is being renewed.

    An example would be:

    [certsrv_server]
    RenewalKeyLength=2048
    RenewalValidityPeriod=8
    RenewalValidityPeriodUnits=Years

    • RenewalKeyLength sets key size for renewal only. This is only used when CA renewal is generating new keys.
    • RenewalValidityPeriod and RenewalValidityPeriodUnits establish the lifetime of new root CA certificate when renewing the old CA certificate.
    • [certsrv_server] is only used when renewing a root CA certificate.
Upgrading Certificate Server 1.0

If you upgrade a Windows NT 4.0 server that is running Certificate Server 1.0 to Windows 2000 Server, Certificate Server 1.0 will automatically be upgraded to the new version of Certificate Services. If the CA being upgraded is using a policy module other than the default policy module for Certificate Server 1.0, it will continue using its old policy module. Certificate Services will refer to it as the "Legacy" policy module. If the CA being upgraded uses the default policy module provided with Certificate Server 1.0, the upgraded CA will use the Certificate Services stand-alone policy.

The Certificate Server 1.0 database does not get upgraded automatically when you upgrade to Windows 2000 Server. The upgraded CA will have an empty database and an empty certificate revocation list (CRL). You must perform the following steps to import the old database information into the new database:

  1. Stop Certificate Services
  2. At the command prompt, run certutil -ConvertMDB
  3. Start Certificate Services
  4. Publish a new CRL

If you are not upgrading a Certificate Server 1.0 CA and, instead, are installing a separate Windows 2000 CA that will replace the old CA, you can find information about installing the policy module developed for Certificate Server 1.0 on a Windows 2000 CA in Configuring the policy and exit modules. This assumes that you want to use the older policy module instead of the default policy module that is provided with Certificate Services.


Configuring the policy and exit modules

The administrator of a certification authority (CA) can configure a number of settings in the default policy and exit modules provided with Certificate Services by using the Certification Authority snap-in.

Policy module settings you can change:

    Certificate revocation list distribution points. You can add or remove certificate revocation list distribution point addresses, which are the URLs a CA writes in every certificate which tell the verifier of a certificate where to retrieve the current version of the CA's certificate revocation list (CRL). These URLs can be either HTTP, FTP, LDAP, or FILE addresses. You can use variables when specifying the address of the CRL Distribution Point (CDP). Refer to the variable table in the procedure for further information about the variables you can use in a URL.

    For the procedure to change the CRL distribution points, see Specify certificate revocation list distribution points in issued certificates.

    Authority information access points. You can add or remove authority information access addresses, which are the URLs in the certificates that a CA issues which tell the verifier of a certificate where to retrieve the certificate of the CA. These addresses can be either HTTP, FTP, LDAP, or FILE addresses. Like the CRL distribution point URLs, you can use variables when specifying the address of the authority information access point. Refer to the variable table in the procedure for further information about the variables you can use in a URL.

    For the procedure to change the authority information access points., see Specify CA certificate access points in issued certificates.

    (For stand-alone CAs only) The default action of the certification authority upon receiving a valid certificate request. You can specify whether a stand-alone CA will hold incoming certificate requests as pending or automatically issue the certificate. In most cases, for security reasons, it is recommended that all incoming certificate requests to a stand-alone CA be marked as pending.

    For the procedure to change the default action of a stand-alone certification authority upon receipt of a certificate request, see Set the default action upon receipt of a certificate request.

Exit module settings you can change:

    Allow certificate publication to Active Directory. You can select whether to allow the publishing of certificates to Active Directory when they are issued. They will be associated with the object in Active Directory to which they were issued.

    For the procedure to allow or disallow the publishing of certificates to Active Directory, see Publish certificates to Active Directory.

    Allow certificate publication to the file system. You can select whether to allow the publishing of certificates to the file system. Actual publication will only occur if the certificate request specifies a file system location where the certificate is to be published.

    For the procedure to allow or disallow the publishing of certificates to the file system, see Publish certificates to the file system.

For more information about policy and exit modules, see Policy and exit modules.

If you want to replace the policy module provided with Certificate Services with a custom policy module or a policy module developed for Certificate Server 1.0 and Windows NT 4.0, you must first register the policy module .dll file using the rgsrv32 yourmodule.dll command and then follow the procedure in Select a different policy module.


Establishing a certification hierarchy

The first step to establish a certification hierarchy is to install a root certification authority (CA).

Using a Windows 2000 certification authority as your root authority

The installation process for a Certificate Services root authority generates a root CA certificate containing the CA's public key and the digital signature created using the root's private key. If the root authority is installed using Windows 2000 Certificate Services on a server that has access to Active Directory, the root authority's certificate will automatically be placed in all domain users' Trusted Root Certification Authorities certificate store thereby establishing domain-wide trust in the root CA.

Using a certification authority outside your organization as your root authority

If your organization is using a third-party certification authority from outside your organization as the root authority (such as Verisign), you will need to obtain the root certificate and distribute it to any user and computer that needs to establish trust in the third-party root authority. One way to distribute a third party's root certificate to Windows 2000 users is to use a certificate trust list (CTL) via Group Policy. See Enterprise trust policy for more information about distributing third party root certificates using Group Policy.

Using a non-Microsoft certification authority inside your organization as your root authority

If your organization is using its own non-Microsoft certification authority (CA) as the root authority, you will need to obtain the root certificate and distribute it to any user and computer that needs to establish trust in the non-Microsoft CA root authority. One way to distribute a non-Microsoft root certificate to Windows 2000 users is to use the Trusted Root Certification Authorities policy setting via Group Policy. See Policies to establish trust of root certification authorities for more information about distributing non-Microsoft root certificates using Group Policy.

Subordinate certification authorities

After trust in a root authority has been established, you can install certification authorities (CAs) that are "subordinate" to the root CA as well as installing subordinate CAs that are subordinate to other subordinate CAs. By doing this, you can create a chain of parent-child relationships between CAs that serve different functions in an organization's public key infrastructure (PKI). The only significant difference in the installation process between a root CA and a subordinate CA is that a certificate request is generated for submission to another CA by a subordinate CA instead of creating a self-signed certificate. This request may be routed automatically to online CAs located via Active Directory, or routed manually if offline. In either case, the resulting certificate must be installed on the new subordinate CA before it can begin operation.

Note that there is a relationship between the enterprise CAs and the Windows 2000 domain trust model, but this does not imply a direct mapping between CA trust relationships and domain trust relationships. There is nothing that prevents a single CA from servicing entities in multiple domains or even entities outside the domain boundary. Similarly, a given domain may have multiple enterprise CAs.

For a brief overview of certification hierarchies, see Certification authority hierarchies.

For extensive information about planning certification hierarchies, refer to the Windows 2000 Resource Kits.


Backing up and restoring a certification authority

The purpose of backup and restore operations is to protect the certification authority (CA) and its operational data from accidental loss due to hardware or storage media failure.The recommended method to back up a CA is to use Windows 2000 Backup to back up the entire file server.

It is also possible to back up and restore a CA using the Certification Authority snap-in, but this backup method is intended for use only in special cases where you don't want to back up the entire server on which the CA is installed. Using Certification Authority, you can back up and restore the following types of information:

  • Public key, private key, and the CA certificate
  • Certificate database

The public key and private key are backed up or restored using the PKCS #12 PFX format.

The Backup wizard will request that you supply a password when backing up the public and private keys and CA certificate. This password will be needed to restore the CA. See Back up a certification authority for procedures on backing up a CA using the Certification Authority snap-in.

After performing the initial full backup of the CA, you can do incremental backups from that point on. When restoring, you will need to restore the full backup first and then each incremental backup in the order that they were created. See Restore a certification authority from a backup copy for procedures on restoring a CA using the Certification Authority snap-in.

Important

  • In general, you should use Windows 2000 Backup and Windows 2000 Restore to back up and restore both the CA and the server. See Windows 2000 Backup for more information about backing up a Windows 2000 server.

Upon restoring a CA, the Internet Information Services (IIS) metabase must also be restored if it has been damaged or lost. If a damaged or missing IIS metabase is not restored, IIS will fail to start, and that will result in Certificate Services Web pages failing to load. The IIS snap-in is used to back up the IIS metabase. Windows 2000 Backup should be used to back up the IIS Web content pages and the CA.

Upon restoring a CA, the Internet Information Services (IIS) metabase must also be restored if it has been damaged or lost. If a damaged or missing IIS metabase is not restored, IIS will fail to start, and that will result in Certificate Services failing to start. The IIS snap-in is used to back up the IIS metabase. Windows 2000 Backup should be used to back up the IIS Web content pages and the CA.

When restoring a CA, if the database logs are not manually deleted before the restore, the CA will be restored to the point in time of the restore--the database logs will be replayed, and changes made since the last backup will be applied to the database. (The default location of the database logs is systemroot\system32\certlog). If the database logs are manually deleted before the restore, the CA will be restored to the point in time that the backup was performed.


Revoking certificates and publishing CRLs

You can use the Certification Authority snap-in to revoke a certificate, to administer certificate revocation list (CRL) publication, and to specify the CRL Distribution Points (CDPs) published in every certificate issued by the certification authority (CA).

Revoking a certificate

To help maintain the integrity of an organization's public key infrastructure (PKI), the administrator of a CA has to revoke a certificate if the subject of certificate leaves the organization, or if the certificate subject's private key has been compromised, or if some other security-related event dictates that it is no longer desirable to have a certificate considered "valid." When a certificate is revoked by a CA, it is added to that CA's certificate revocation list (CRL).

For conceptual information about the role of certificate revocation and revocation checking in a PKI, see Certificate revocation. For the procedure to revoke a certificate, see Revoke an issued certificate. For instructions on how to display the current CRL, see View the certificate revocation list.

Scheduling certificate revocation list (CRL) publication

One of the features of Certificate Services is that every CA automatically publishes an updated CRL after an interval of time specified by the administrator of the CA. This interval of time is known as the CRL "publish period". After the initial setup of a CA, the CRL publish period is set to one week (based upon the local computer's time, starting from the date when the CA is first installed). You can change a certification authority's CRL publishing interval using the procedure Schedule the publication of the certificate revocation list.

A CA administrator should understand that there is a difference between a CRL publish period and the validity period of a CRL. The "validity period" of a CRL is the period of time that the CRL is considered authoritative by a verifier of a certificate. As long as the verifier of a certificate has a valid CRL in its local cache, it will not attempt to retrieve another CRL from the CA which publishes it.

The publish period of a CRL is established by the CA administrator. However, the validity period of the CRL is extended from the publish period to allow for Active Directory replication. By default, Certificate Services extends the publish period by 10% (up to a maximum of 12 hrs) to establish the validity period. So, for example, if a CA is publishing a CRL every 24 hours, the validity period is set to 26.4 hours.

Additionally, there is a clock skew of an additional 10 minutes added to the validity period on either side of the publish period, so a CRL will be valid 10 minutes before the beginning of its publish period to account for variances in computer clock settings.

There are registry entries which allow an administrator to control the variance between publish period and validity period to allow for slower directory replication. Refer to the Windows 2000 Resource Kits for information about these registry entries.

Publishing a certificate revocation list (CRL) before the next scheduled publish period

You can also publish a CRL on demand by using the CRL Publishing wizard. The publishing parameters you select using the CRL Publishing wizard will not modify the scheduled publication period. In other words, if you manually publish a CRL in the middle of a scheduled publish period, the CRL will still be automatically republished at the end of the current publish period.

It's important to realize that clients that have a cached copy of the previously published CRL will continue using it until its validity period has expired, even though a new CRL has been published. Manually publishing a CRL does not affect cached copies of CRLs that are still valid; it only makes a new CRL available for systems that do not have a cached copy of a valid CRL.

See Manually publish the certificate revocation list for the procedure to force the immediate publication of a CRL.

CRL distribution points and the CRL file name

Every certificate that is issued by a Windows 2000 certification authority has CRL distribution points as part of its content. A CRL distribution point provides a certificate verifier with the network location where it can retrieve the current copy of the CRL. For procedures to designate the certificate revocation list distribution points in certificates, see Specify certificate revocation list distribution points in issued certificates.

By default, a CRL file is published on the CA in the following location:

Systemroot\System32\Certsrv\Certenroll

The format of the CRL file name is the "sanitized name" of the CA plus, in parentheses, the "key id" of the CA (if the CA certificate has been renewed with a new key) and a .crl extension. Refer to the table for some sample CRL file names based on sample renewal histories of a CA:

Scenario | Name of CRL file
A certification authority named "MyCA" that has never had its CA certificate renewed | myca.crl
A certification authority named "MyCA" that has been renewed once with the same key | myca.crl
A certification authority named "MyCA" that has been renewed once with a new key | myca(1).crl
A certification authority named "MyCA" that has been renewed 4 times, twice with a new key | myca(2).crl

See Installing and configuring a certification authority for information about a CA's "sanitized name."

See Renewing a certification authority for more information about CA renewal.

Enabling Netscape-compatible Web-based revocation checking

To enable Netscape-compatible Web-based revocation check extensions to be added to every certificate, run the following certutil command from the command prompt on the certification authority:

certutil -SetReg Policy\RevocationType +AspEnable

Then, stop and start the Certification Authority service. Certificates issued by the certification authority after it is restarted will contain the extension. For more information on the certutil command, see CertUtil


Mapping certificates to user accounts

It is possible to map (or create an association from) a certificate that has been issued to a user to the user's account. A server application can then use public key cryptography technology to authenticate the user using this certificate. If the user is authenticated, then the user's account is logged on. The end result is the same as if the user provided a user ID and password, yet the process is much more manageable.

Traditionally, computer systems have used a centralized accounts database to manage users, their privileges, and their access controls. This technique has worked well and is well understood. However, as systems become more and more distributed--with hundreds of thousands to millions of users--this form of centralized control becomes unwieldy. The problems range from trying to verify an account against a database located on the other side of the Internet to administering a lengthy list of users.

Public key certificates can help simplify these problems. Certificates can be widely distributed, issued by numerous parties, and can be verified by simply examining the certificate, without having to refer to a centralized database. However, existing operating systems and administration tools can only deal with accounts, not certificates. The simple solution--one that maintains the advantages of both certificates and user accounts-- is to create a mapping between a certificate and a user account. This allows the operating system to continue using accounts while the larger "system" and the user use certificates.

In this model, when a user presents a certificate, the system looks at the mapping to determine which user account should be logged on. (Note that this should not be confused with logging on with a smart card. Windows 2000 supports logging on with a smart card using account mapping that is automatic.)

Mapping a certificate to a Windows 2000 user can be done in one of two ways: the mapping can be done either by the Windows 2000 Active Directory service or it can be done with rules defined in Microsoft Internet Information Services (IIS).

Types of mapping

In most cases, a certificate is mapped to a user account in one of two ways: a single certificate is mapped to a single user account (one-to-one mapping) or multiple certificates are mapped to one user account (many-to-one mapping).

User principal name mapping

User principal name mapping, is a special case of one-to-one mapping. To use user principal name mapping, you must use Active Directory. With user principal name mapping, the user principal name is used to find the user's account in Active Directory and log it onto the network or host. The user principal name looks very much like an e-mail name, and is unique within a Windows 2000 domain. Enterprise certification authorities (CAs) place the user principal name of the certificate holder into each certificate. Thus, for accessing a secure IIS server or logging on to Windows 2000 with a smart card, the mapping of user names to accounts is automatic on these certificates.

One-to-one mapping

One-to-one mapping maps a single user certificate to a single Windows 2000 user account. For example, imagine you want to provide a Web page to your employees that will allow them to view and modify their deductions, manage their health care, and a number of other benefits options. This page should work over the Internet and should be secure. As a solution, you decide to use Windows 2000, certificates, and certificate mapping. You can either issue certificates to each of your employees from your own certificate service, or you can have your employees get certificates from a certification authority approved by your company. You can then take these user certificates and map them to the employee's Windows 2000 user account. This allows a user to connect to the Web page using SSL (Secure Sockets Layer) or TLS (Transport Layer Security) from anywhere by providing his or her client certificate. The user then logs onto his or her own user account and normal Windows 2000 access controls can be applied.

Many-to-one

Many-to-one mapping maps many certificates to a single user account. For example, you have a partnership with an agency that provides temporary workers for your job openings. You would like to allow the agency personnel to view Web pages that describe current job openings that only company employees can see. The agency has its own certification authority that it uses to issue certificates to its employees. After installing the agency certification authority's root certificate as a trusted root in your enterprise, you can set a rule that maps all certificates issued by that certification authority to a single Windows 2000 account. You can then set the access rights of the account so this account can access that Web page.

See Map certificates to user accounts for procedures to map certificates to user accounts.


Renewing certification authorities

Why certification authorities need to be renewed

Every certificate issued by a certification authority (CA) has a validity period. The validity period is the range of time where the certificate can be accepted as an authoritative credential of the identity of the subject of the certificate. This is, of course, assuming the certificate is not revoked before the validity period ends and that the issuing CA is trusted.

Since a CA is really just another entity that has been issued a certificate--either issued by itself (in the case of a root CA) or issued by a parent (in the case of a subordinate CA)--every CA has a built-in "expiration date" as determined by the end of the validity period on its CA certificate. This is not meant to imply that the "lifetime" of a CA is equivalent to the validity period of its CA certificate, only that a CA can not issue certificates if it does not have a valid certificate of its own. The lifetime of a CA includes the validity periods of all its CA certificates--past and present. With these considerations in mind, an organization with a public key infrastructure (PKI) has to plan for the "renewal" of every certificate issued to a CA in the certification hierarchy in order to maintain the existing trust relationships in the PKI and to extend the lifetimes of CAs.

The validity period of a CA and the validity period of the certificates it issues

Before discussing the renewal of a CA certificate, it's helpful to understand how the end of the validity period of a CA affects the validity period of the certificates it issues. Certificate Services enforces a rule that a CA never issues a certificate to be valid beyond the expiration date of its own certificate. Therefore, when a CA's certificate reaches the end of its validity period, all certificates it has issued will also expire. This way, if the CA is purposely not renewed and the CA reaches the end of its lifetime, a PKI administrator can be assured that all the certificates that the now-expired CA has issued can no longer be used as valid security credentials. In other words, there will be no "orphaned" certificates that are still within their validity period but which have been issued by a CA that is no longer valid.

To illustrate how a decreasing validity period works, consider the following scenario: An organization installs a root CA with a certificate validity period of five years. The organization then uses this root CA to issue certificates with a validity period of two years to subordinate CAs. For the first three years every certificate issued to a subordinate CA by the root CA will continue to have a validity period of two years. After three years, when there is less than two years left in the validity period of the root CA certificate, Certificate Services begins to reduce the validity period of the certificates issued by the root CA so that they do not exceed the end of the CA's certificate's expiration date. Therefore, after four years, the CA issues subordinate CA certificates that are valid for one year. After 4.5 years, issued subordinate CA certificates have a validity period of only six months.

Certificate Services allows for the following maximum validity periods that are based on the type of certificate. Except for the root CA, none of these validity periods are configurable by the CA administrator:

Type of certificate | Maximum validity period
Root CA | Specified during setup of Certificate Services
Subordinate CA, Internet Protocol Security, Enrollment Agent, Domain Controller | Two years
All other certificates | One year

Planning for the renewal of a CA

Since a CA that is approaching the end of its own validity period issues certificates valid for shorter and shorter periods of time, you need to have a plan in place to renew the CA well before it expires in order to avoid issuing certificates of a very short validity period.

One renewal consideration: When you renew a CA, you have the option of re-using its existing key pair or generating a new key pair. When you generate a new key pair for a CA that is being renewed, a new certificate revocation list (CRL) distribution point is also created. This is to ensure that the key used to sign a certificate issued by the CA also matches the key used to sign the CRL. For more information about how renewing a CA with a new key affects certificate revocation and and the name of CRLs, see Revoking certificates and publishing CRLs.

The following strategies are presented as possible approaches an organization could take when planning for CA renewal. You may need to adapt these to your specific situation.

  • Renewing a root certification authority

    Since the root CA is the most critical CA in the hierarchy, you may prefer to have a strategy here that reduces the need to renew the root certificate often.

    The first consideration is choosing the key length of the root's public key and private key pair during setup of the root authority. By using a long key length, which is generally more secure against brute force attack by a hacker than a shorter key length, you increase the length of time that the CA can use the same private key and have reasonable confidence that it has not been compromised. The second consideration is establishing the validity period of the root certificate itself. In general, you will want to create a root certificate that has a shorter validity period than the estimated lifetime of the key.

    Keeping these considerations in mind, a possible strategy for setting up a root CA that reduces the need for frequent renewal would be to create a 4096-bit RSA key during Certificate Services setup. Given the state of computer technology in the late 1990's, one estimate is that a 4096-bit private key is reasonably secure from a brute force attack for 15-20 years. After creating the 4096-bit key in Certificate Services setup, you could create a root certificate using the 4096-bit key that is valid for five years. Afterwards, the CA's certificate should be renewed every four years (one year before the expiration of the validity period), each time with a certificate validity of five years. Of course, every time the CA certificate is renewed, the administrator will have to assess whether the same key, given current computer technology and other security considerations, can be used with confidence for the next five years.

  • Renewing a subordinate certification authority

    Intermediate CAs

    Within an organization's certification hierarchy, some subordinate CAs may be "intermediate" CAs--in other words, they don't issue certificates to end users or computers, they only issue certificates to other subordinate CAs below them in the certification hierarchy. For these intermediate CAs, given their limited role and the relative ease of monitoring their certificate database logs, a possible strategy may be to renew them a year to six months before they expire and re-use the existing key.

    Issuing CAs

    For subordinate CA's that do issue certificates to end users and computers, sometimes referred to "issuing" CAs, a preferable strategy may be to renew the CA's certificate regularly with a new key 6-12 months before the end of the CA's validity period. This makes an attack by a hacker on any one key less valuable, since any compromised key would have a relatively limited lifetime.

    The other advantage of renewing an issuing CA using a new key is CRL management. When a CA is renewed with a new key, it begins to publish a separate CRL for the revoked certificates it has issued using the new key. It also will continue to publish a CRL for certificates signed with the old key, for as long as those revoked certificates validity period is still in effect. This is something a CA administrator may want to exploit if the CA is issuing a large number of certificates and, potentially, revoking a large number of those certificates. It may be advantageous to reduce the possibility of having one huge CRL that certificate verifiers have to download by instead issuing a number of certificates with one key, renewing the CA early into its validity period with a new key, then issuing a number of certificates using the new key. In this way, you will reduce the size of the CRL that certificate verifier has to download when presented with a certificate from an issuing CA.

For more detailed information about planning for renewal and renewing Windows 2000 certification authorities, refer to the Windows 2000 Resource Kits.

Procedures to renew CAs

See Renew a root certification authority for the procedure to renew a root CA.

See Renew a subordinate certification authority for the procedure to renew a subordinate or intermediate CA.


Certificate Services Command-Line Functions

Windows 2000 includes three command-line functions to help you administer Certificate Services. They extend the functions and control of certificate requests and certification authorities that are already provided by the Windows graphic user interface. They are primarily intended for developers and knowledgeable certification authority administrators.

This section covers:

  • CertUtil
  • CertReq
  • CertSrv


CertUtil

CertUtil.exe can:

  • Display Certificate Services configuration information or a file containing a request, a certificate, a PKCS #7, or certificate revocation list (CRL).
  • Get the certification authority (CA) configuration string.
  • Retrieve the CA signing certificate.
  • 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 or all levels of a certification path.
  • 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 files based on hexadecimal or base 64.
  • Encode files to base 64.
  • Shut down the server.
  • Display the database schema.
  • Convert a Certificate Server 1.0 database to a Certificate Services 2.0 database.
  • Backup and restore the CA keys and database.
  • Display certificates in a certificate store.
  • Display error message text for a specified error code.
  • Import issued certificates that are missing from the database.
  • Set and display certification authority registry settings.
  • Create or remove Certificate Services Web virtual roots and file shares.

Syntax

Documentation regarding [options] in each entry is available at the end of this page.

certutil [options] -?
Displays the command options.
certutil [options] -7f CertFile
Checks the certificate specified by CertFile for 0x7f-length encodings. Avoiding 0x7f-length encodings ensures compatibility with old enrollment controls.
certutil [options] -decode InFile OutFileResult
Decodes the base 64-encode file specified by InFile and writes the result to OutFileResult.
certutil [options] -decodehex InFile OutFileResult
Decodes the hexadecimal-encoded file specified by InFile and writes the result to OutFileResult.
certutil [options] -dump
Dumps the certification authority's configuration information.
certutil [options] -encode InFile OutFileResult
Encodes the file specified by InFile to base 64 and writes the result to OutFileResult.
certutil [options] -error ErrorCode
Displays localized error message text for the specified error code. ErrorCode may be in signed or unsigned decimal format, or hexadecimal format with a leading 0x.
certutil [options] -getconfig
Gets the default configuration string for the certification authority and displays it.
certutil [options] -SetReg Policy\RevocationType [+|-]AspEnable
Using a plus sign (+) enables you to add Netscape-compatible Web-based revocation check extensions to every certificate issued by the CA. After running this command, you need to stop and restart the Certification Authority service for it to take effect. The revocation check extension contains a URL that points to a Web page that performs revocation checks. Revocation checking code passes the serial number of the certificate to the Web page as a parameter by appending the serial number to the URL in hexadecimal format. (See the certutil -IsValid and -Revoke command descriptions for an explanation of the serial number format.) The Web page calls the CA to verify that the serial number was issued by the CA and has not yet been revoked, and returns a zero (0) or one (1) to indicate the result. Using a minus sign (-) keeps the revocation-checking URL extension from being added to certificates that are issued (after the Certification Authority service is stopped and restarted).
certutil [options] -store [CertificateStoreName [CertIndex [OutputFile]]]
Displays the certificates in the Local Machine certificate store. If CertificateStoreName is not specified, the CA store is used. If CertIndex is specified, only the indexed certificate is displayed. If CertIndex and OutputFile are specified, the displayed certificate is written to OutputFile. Use the -user option to display certificate stores for the current user instead of the local computer.
certutil [options] -verify CertFile [CACertFile]
Verifies that the certificate specified by CertFile was issued using the CA certificate specified by CACertFile. Both files must contain a single certificate, not a PKCS #7 certificate. 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 if the necessary URLs or CRLs are unavailable.

If CACertFile is not specified, then CertFile's certification path is constructed using certificates installed on the computer, and all certificates in the chain are verified and checked to see if they have been revoked.

certutil [options] -verifykeys KeyContainerName CACertFile
Verifies the public/private key set in the key container specified by KeyContainerName using the CA certificate specified by CACertFile.
certutil [options] -verifystore CertificateStoreName [CertIndex]
Similar to -store, but this command also verifies the associated private keys if they exist, and verifies each certificate by building a chain from the installed CA and root certificates and verifying all certificates in the chain to make sure they are still valid and have not been revoked.
certutil [options] -vroot [delete]
Creates or deletes the standard set of Certificate Services Web server virtual roots and file shares. Useful when IIS is installed after Certificate Services.
certutil [options] [-config ConfigString] -backup BackupDirectory [password [incremental] [KeepLog]]
Backs up the certification authority database, certificates, and keys to BackupDirectory. Specifying an asterisk for the PFX file password will cause it to be collected during program execution but not displayed on the screen. See also notes regarding -backupDB.
certutil [options] [-config ConfigString] -backupDB BackupDirectory [[incremental] [KeepLog]]
Backs up certification authority database to BackupDirectory. Use the -f option to overwrite existing files in BackupDirectory. The server must be running. This command may be executed remotely or locally. Normal use involves infrequent full backups, followed by frequent incremental backups. Each backup must be made into a separate directory tree. All backups starting with the most recent full backup will be required to correctly restore the database.
certutil [options] [-config ConfigString] -backupKey BackupDirectory [password]
Backs up certification authority certificate and keys to BackupDirectory. Specifying an asterisk for the PFX file password will cause it to be collected during program execution but not displayed on the screen. Specifying an asterisk for the PFX file password will cause it to be collected during program execution but not displayed on the screen.
certutil [options] [-config ConfigString] -ca.cert OutCASignatureCertFileResult
Retrieves the CA signing certificate and writes it to the file specified by OutCASignatureCertFileResult.
certutil [options] [-config ConfigString] -ca.chain OutCAsignatureCertChainFileResult
Retrieves the certification authority (CA) signing certificate and chain and writes it to a PKCS #7 file specified by OutCAsignatureCertChainFileResult.
certutil [options] [-config ConfigString] -ConvertMDB
After upgrading a Windows NT 4.0 server with Certificate Services 1.0 to Windows 2000 with Windows 2000 Certificate Services, this command migrates the old database records to the current database. The server must not be running. The command must be started locally on the server running Certificate Services. The CertSrv ODBC User DSN must still be accessible.
certutil [options] [-config ConfigString] -CRL [OutFileResult|-]
Publishes the current certificate revocation list (CRL). Optionally, the CRL is written to the file specified by OutFileResult, or to the default Web location if a minus sign (-) is specified. 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] -databaselocations
Displays a list of tagged database files and database directories. Hexadecimal buffer offset and hexadecimal type tag are displayed on each line. See the Certificate Services backup API documentation and certbcli.h in the Microsoft Platform Software Development Kit for type tag definitions.
certutil [options] [-config ConfigString] -deny RequestId
Denies the pending certificate request specified by RequestId. RequestId must be in decimal format (or hexadecimal format with a leading 0x).
certutil [options] [-config ConfigString] -dynamicfilelist
Displays a list of dynamic files that must be backed up separately. Includes the server's local copy of the certificate revocation list (CRL). Hexadecimal buffer offset is displayed on each line.
certutil [options] [-config ConfigString] -GetCRL OutFileResult
Retrieves the most recently published CRL and writes it to the file specified by OutFileResult.
certutil [options] [-config ConfigString] -getreg [{ca|restore|policy|exit} [\ProgId] \RegistryValueName
Allows mnemonic display of certification authority registry values.

Some examples are:

certutil -getreg Active

certutil -getreg ca\LogLevel

certutil -getreg Policy\RevocationType

certutil [options] [-config ConfigString] -importcert Certfile [Flags]
Used to import a certificate into the server database. Useful for making a certificate revocable after it was inadvertently lost from the database, possibly due to database restore from an incomplete database backup. The certificate must have been issued by the server. Flags must be zero (0), if specified.
certutil [options] [-config ConfigString] -installcert [CACertFile]
Completes subordinate CA certificate installation for a subordinate CA installation that generated a request, but has not yet received and installed its CA certificate. A PKCS #7 certification path is the preferred content of CACertFile, although an X.509 certificate is accepted if all of the certificates that would be used to form the chain are already installed on the local computer. Also allows installation of a requested renewal CA certificate.
certutil [options] [-config ConfigString] -isvalid SerialNumber
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 zero (0) can be prefaced to a value with an odd number of digits. No leading Ox is allowed.
certutil [options] [-config ConfigString] -ping
Verifies the server is running (via the ICertRequest interface). ConfigString may consist of just a computer name or DNS name. If the server is running, this command will report the CA name of the server.
certutil [options] [-config ConfigString] -pingadmin
Verifies the server is running (via the ICertAdmin interface), and that the user has minimal administrative access to the server.
certutil [options] [-config ConfigString] -renewCert [RequestFile]
Used to initiate requesting a renewal CA certificate. If an online parent CA does not exist or if it does not imediately issue a renewal CA certificate, use the -installCert command to complete the renewal certificate installation when the certificate is available.
certutil [options] [-config ConfigString] -restore BackupDirectory [password]
Restores certification authority database, certificates, and keys from BackupDirectory. Specifying an asterisk for the PFX file password will cause it to be collected during program execution but not displayed on the screen. See also -restoreDB notes.
certutil [options] [-config ConfigString] -restoreDB BackupDirectory
Restores certification authority database from BackupDirectory. The server must not be running. This command may be executed remotely or locally. Restoring a full backup plus incremental backups requires restoring the full backup first, followed by restoring all subsequent incremental backups in any order. Use the -f option for the full restore to overwrite existing server database files. The server must not be started until all backups are restored. Starting the server initiates database recovery. Successful start of the server as recorded in the Application Event Log indicates the restore and recovery successfully completed.
certutil [options] [-config ConfigString] -restoreKey BackupDirectory|PFXFile [password]
Restores certification authority certificate and keys from BackupDirectory or PKCS #12 PFXFile. Specifying an asterisk for the PFX file password will cause it to be collected during program execution but not displayed on the screen.
certutil [options] [-config ConfigString] -resubmit RequestId
Resubmits the pending certificate request specified by RequestId. RequestId must be in decimal format or hexadecimal format with a leading 0x.
certutil [options] [-config ConfigString] -revoke SerialNumber
Revokes the certificate specified by SerialNumber. SerialNumber must be in hexadecimal format with an even number of digits. A single zero (0) can be prefaced to a value with an odd number of digits. No leading Ox is allowed.
certutil [options] [-config ConfigString] -schema
Dumps the certification authority database schema, for example, column names, types, and max sizes.
certutil [options] [-config ConfigString] -setattributes RequestId AttributeString
Sets the named attributes specified by AttributeString in the certificate request specified by RequestId. RequestId must be in decimal format (or hexadecimal format with a leading 0x). The specified request must be in the pending state. The following is a valid example:

certutil -setattributes 123 attribname1:attribvalue1\nattribname2:37

certutil [options] [-config ConfigString] -setextension RequestId ExtensionName Flags Value
Sets the extension specified by ExtensionName in the certificate request specified by RequestId. RequestId must be in decimal format (or in hexdecimal format with a leading 0x). Flags must be set to zero (0) or one (1); a one 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, or in hexadecimal format if it starts with a leading 0x and all the remaining characters are hexadecimal digits. The following is a valid example for a noncritical extension:

certutil -setextension 123 1.3.6.1.4.1.311.20.2 0 SubCA

The specified request must be in the pending state.

certutil [options] [-config ConfigString] -setreg [{ca|restore|policy|exit}\[ProgId]\RegistryValueName
Allows edits and mnemonic display of certification authority server registry values.

Examples:

certutil -setreg Policy\RevocationType -0x100

Turns off the 0x100 bit.

certutil -setreg Policy\RevocationType +0x100

Turns on the 0x100 bit.

certutil -setreg Policy\RequestDisposition 1

Overwrites existing value with 1.

certutil [options] [-config ConfigString] -shutdown
Shuts down the certification authority server, even if it was started in console mode

The CertUtil command options are:

-config ConfigString | Causes the operation to be processed using the certification 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.
-f | Forces overwrite.
-user | Use HKEY_CURRENT_USER certificate store.
-gmt | Display times as Greenwich Mean Time (GMT).


CertReq

You can use CertReq.exe to request certificates from a certification authority (CA) from the command prompt.

Syntax

CertReq [-rpc] [-binary] [-config ConfigString] [-attrib AttributeString] [RequestFile [Certfile[CertChainFile]]]
CertReq -retrieve [-rpc] [-binary] [-config ConfigString] [RequestId [Certfile [CertChainFile]]]
CertReq -?

The CertReq command options are as follows:

-attrib AttributeString | Attribute name, value string pairs. (See example of AttributeString below.)
-binary | Output files in binary format instead of Base64-encoded.
-config ConfigString | Server\CertificationAuthority configuration string. To choose the default, use a single minus sign (-) as the configuration string.
-rpc | Instructs Certificate Services to use RPC server connection instead of DCOM .
-retrieve | If you submit a request to the certification authority (CA), the policy module of the CA may leave the request in a pending state and return the RequestId to the certreq caller for display. Eventually, the certification authority's administrator will use the Certification Authority snap-in or an equivalent custom user interface to resubmit the request and issue the certificate, or to deny the request. Certreq -retrieve RequestId may be used to retrieve the certificate after the certificate authority has actually issued it. It also may be used to retrieve any certificate that has ever been issued by the certification authority (even revoked or expired certificates), without regard to whether the certificate's request was ever in the pending state.
-? | Display usage assistance.
RequestFile | Base64-encoded or binary input file name. May be a PKCS #10 certificate request, PKCS #7 certificate renewal request, or KeyGen tag format certificate request
CertFile | Base64-encoded, X-509 output file name
CertChainFile | Base64-encoded, PKCS #7 output file name
ConfigString | Server Name and Certification Authority Name, separated by a backslash.
AttributeString | Name and Value string pairs, separated by a colon. Each pair is separated by \n. For example: Name1: Value1\n Name2: Value2


CertSrv

CertSrv.exe, from the command prompt, starts the Certificate Services as a stand-alone application instead of as a Windows 2000 service. (This should be used only for diagnostic purposes.) When CertSrv is running in this diagnostics mode, it displays a log of its actions in the console window

Syntax

certsrv -z

net start certsvc

Parameters

certsrv -z
Starts the Certification Authority service as a stand-alone application in diagnostic mode, displaying its actions in the console window.

It is important to note that the Certification Authority service cannot be run in diagnostic mode if it is currently running as a service. If you want to stop the Certification Authority service in order to run certsrv in diagnostic mode, do one of the following before typing certsrv -z at the command prompt:

  • Open the Certification Authority snap-in, click the name of the certification authority in the console tree, then on the Action menu, point to All Tasks and click Stop Service.
  • Open Computer Management, click on Services and Applications, then click on Services. In the details pane, click on Certificate Services. On the Action menu, click Stop.
net start certsvc
Manually starts the Certification Authority service.

Ordinarily, the Certification Authority service starts automatically, with no user intervention. If the Certification Authority service is stopped, you can start it a number of ways:

  • Open the Certification Authority snap-in, and click on the name of the certification authority in the console tree. On the Action menu, point to All Tasks, and click on Start Service.
  • Open Computer Management, click on Services and Applications, then click on Services. In the details pane, click Certificate Services. On the Action menu, click Start.
  • At the command prompt, type net start certsvc.


Troubleshooting

What problem are you having?

General troubleshooting for a certification authority (CA).

Check the event log of the Windows 2000 server. It often logs more detailed errors than you will notice from doing the procedure you're attempting.

If the problem is reproducible, run Certificate Services in diagnostic mode using the certsrv -z command. For more information see CertSrv.

See Microsoft Product Support Services for updated information about Certificate Services.

Error when accessing the certification authority Web pages.

Cause: Web pages aren't installed on the certification authority (CA).

Solution: Run certutil -vroot from the command prompt on the CA to install the Web enrollment pages.

Cause: Web pages don't have execute script permissions.

Solution: From Internet Information Services (IIS), open the CertSrv folder and confirm that there are execute script permissions on the folder. The CertSrv folder is:

Systemroot/System32/Certsrv

Web pages on an enterprise certification authority (CA) either don't generate certificates or generate certificates that are not valid.

Cause: For an enterprise CA, Web pages require that the user be authenticated. If the pages are set to allow anonymous connections, then the CA will either not generate certificates or will generate certificates that are not valid.

Solution: See Set security for access to certification authority Web pages.

Can't log into certification authority (CA) Web pages.

Cause: If the Web pages negotiate basic authentication with the browser, then your Windows 2000 user account must have the privilege to log on to the server.

Solution: By default, only domain administrators have this privilege. You will need to change this default security permission setting for the server hosting the CA if you use the Netscape browser.

Certification authority (CA) Web enrollment pages that are installed on a remote server other than the CA do not work.

Cause: The pages are set to use NTLM authentication instead of basic authentication.

Solution: If the Web pages are located on a different server than the CA, then you must set the pages to use basic authentication rather than NTLM if the CA is an enterprise CA. You should also use SSL to secure these pages to protect the passwords. See the Internet Information Services (IIS) documentation to change these settings.

Internet Information Services (IIS) 4.0 and Certificate Server 1.0 cannot enroll for certificates using Windows 2000 Certificate Services Web pages.

Cause: IIS 4.0 and Certificate Server 1.0 cannot process a certification path, rather than just a single certificate.

Solution: Use the command line utility CertReq to process the enrollment request.

A user tries to log on with the smart card and receives this message: "The system cannot log you on to this domain because the system's computer account in its primary domain is missing or the password on the account is incorrect".

Cause: The computer account may be disabled, or the CA that issued the smart card certificate is not trusted by the computer.

Solution:

  1. Make sure that the computer account is enabled in the domain.
  2. Use the Certificates snap-in to verify that the root CA's certificate is in the Trusted Root Certification Authorities store on the user's computer.
  3. Use the Certificates snap-in to verify that the domain controller has been issued a domain controller certificate that can be verified to a trusted root.

After renewing a CA, computers are no longer automatically enrolling for certificates from that CA

Cause: CA renewal requires that all automatic certificate enrollment objects that enroll for certificates from that CA be recreated.

Solution: See Create an automatic certificate request for computers in a Group Policy object.

When trying to enroll for a certificate from a computer or account belonging to a child domain of the domain where the CA is located, the following error appears: "No template could be found. There are no CAs from which you have permission to request a certificate, or an error occurred while accessing the Active Directory."

Cause: You don't have the proper security permissions set on the certificate templates.

Solution: Modify the security permissions for the certificate templates to include the child domain accounts from which you want to allow enrollment. To set access control for certificate templates , see Set security permissions and delegate control of certificate templates. Some access control caches must time out after making changes to security permissions, so you have to wait a short period of time before seeing the new security permissions replicate through the network.