Freigeben über

Requesting Offline Domain Controller Certificates (Advanced Certificate Enrollment and Management)

  • Artikel

Applies To: Windows Server 2003 with SP1

In branch-office scenarios with limited connectivity or those requiring a VPN or IPSec connection to the primary data center will often require an asynchronous enrollment process to enroll or provision the domain controller with an X.509 certificate. Asynchronous or (offline) certificate requests for domain controllers must be created with command-line tools because the operating system does not natively support an offline enrollment Wizard such as the one found in IIS. Since any type of certificate request can be created with the command-line tools, you can also build other certificate request types with these tools once you understand the general procedures. The following sections provide the steps required to enroll a domain controller for a certificate through an offline process.

Note

Some differences and capabilities exist between a Windows 2000 system and a Windows Server 2003 family operating system. The differences and required procedures specific to an operating system family are noted accordingly.

Preparing a Windows 2000 Domain Controller

For a Windows 2000 family operating system, the first step is to prepare the Windows 2000 domain controller. Since Windows 2000 has no natively installed tools to create certificate requests at a command line, a Windows Server 2003 tool must be used. The version of the certreq.exe and certutil.exe command-line tools available on Windows 2000 have only limited capabilities and do not satisfy the requirements for offline certificate request processing, which is required for this scenario. For example, the Windows 2000 version of certreq.exe does not support the –new option which is required to create new certificate requests. Certutil.exe has many more options to verify and process certificates.

The Windows Server 2003 Administration Tools Pack includes the latest version of certreq.exe and certutil.exe and is required as part of this process. To install the tools on a Windows 2000 computer, you must first install the Windows Server 2003 Administration Tools Pack on a Windows XP or Windows Server 2003 system because it cannot be installed directly on a Windows 2000 computer.

The Windows Server 2003 Administration Tools Pack can be downloaded from the Web site at https://www.microsoft.com/downloads/details.aspx?FamilyID=c16ae515-c8f4-47ef-a1e4-a8dcbacff8e3&DisplayLang=en

To install the tools on a Windows 2000 system, perform the following steps.

Important

Once you have copied the new files to the Windows 2000 domain controller, two versions of these files will reside on the Windows 2000 computer. Do not remove the natively installed files on the Windows 2000 system because other applications, like the Certificates MMC Snap-in, depend on these native versions. Also, do not register certcli.dll and certadm.dll on the Windows 2000 system through the regsvr32.exe command.

  1. Log on to a computer that runs Windows XP Service Pack 1 or Windows Server 2003.

  2. Install the Windows Server 2003 Administration Tools Pack.

  3. Copy the following files to a removable storage medium such as a diskette.

    • certreq.exe

    • certutil.exe

    • certcli.dll

    • certadm.dll

  4. Log off the computer.

  5. Make the removable storage medium available to the domain controller that requires an offline domain controller certificate.

  6. Log on to the domain controller as a domain administrator and create a new directory to store the files, for example, %HOMEDRIVE%\W2K3AdmPak.

    Note

    Do not include this path in your system search path to avoid conflicts with the tool versions that already exist on your computer.

  7. From the removable storage medium, copy the four files to the newly created directory.

Generating an Offline Certificate Request

This section applies to both Windows 2000 and Windows Server 2003 domain controllers. The next step is to generate an offline certificate request for the domain controller. As mentioned previously, you must create an offline certificate request with a command-line tool called certreq.exe. This tool supports a rich set of command-line options, but only a few options are required in this procedure. For more information about the certreq.exe tool and its syntax, see Appendix 3: Certreq.exe Syntax.

Certreq.exe requires a text (instruction) file to generate an appropriate X.509 certificate request for a domain controller. You can create the file with your preferred (ASCII) text editor and save the file with an *.inf extension to any directory on your hard drive.

In general, a domain controller certificate that is to be used for SMTP replication must meet the following requirements.

  • The certificate must contain the "Certificate Template Name" (referenced by the object identifier 1.3.6.1.4.1.311.20.2) extension.

  • The certificate must contain a "Subject Alternative Name" extension that includes the Globally Unique Identifier (GUID) of the domain controller account and the fully qualified domain name (FQDN) of the domain controller Domain Name System (DNS) host name. The subject alternative name is uniquely identified with object identifier 2.5.29.17.

Typically, both extensions are automatically inserted in the certificate by an enterprise CA when the certificate is enrolled automatically or manually while connected to a CA. However, when you request the domain controller certificate offline, you must provide these extensions explicitly in the offline request.

There are several different approaches to adding extensions in certificate requests and, ultimately, issued X.509 certificates. For a Windows 2000 CA, you can either include the extension(s) in the INF instruction file, or you can add the extension(s) to a pending certificate request. If you add the extension(s) to a pending certificate request, it is not necessary to also use the INF instruction file to perform the same task.

For a Windows Server 2003 CA, you can either use the same procedures as a Windows 2000 CA, or you can specify certificate extensions using certreq.exe from a command-line when the certificate request is submitted.

Important

When you submit extensions from the certreq.exe command-line tool, you cannot set the critical flag for the submitted extensions. Therefore, if an extension is required to be marked critical, you must use an INF instruction file as the submission method.

Identifying the Domain Controller GUID

Active Directory replication via SMTP requires the domain controller GUID as an attribute in the domain controller certificate. Thus, you must identify the domain controller GUID if you are going to issue certificates for SMTP replication from a Windows Server 2003 enterprise or stand-alone CA. Since the GUID of the domain controller is stored in Active Directory, there are several ways to read this attribute from the domain controller’s computer object. You do not need to be logged on to a domain controller or the CA to read the GUID from Active Directory; any computer that has read permissions to objects in the domain is sufficient to complete this task. The following is a partial list of tools that can be used to determine the domain controller GUID from Active Directory.

  • Adsiedit.exe (available as part of the Windows® support tools)

  • Ldp.exe (available as part of the Windows support tools)

  • Dsquery.exe (available as part of the Windows support tools)

  • Netdiag.exe (available as part of the Windows support tools)

  • Replmon.exe (available as part of the Windows support tools)

  • Windows Management Instrumentation (WMI)

For more information, see the Microsoft Knowledge Base article “Determining the Server GUID of a Domain Controller” at https://support.microsoft.com/default.aspx?scid=kb;en-us;224544

Since it may be complicated in some scenarios to easily identify a domain controller GUID, a script is provided in Appendix 2 to look up the GUID from Active Directory automatically when the certificate request is generated. This script simplifies the process for administrators. For more information, see Reqdccert.vbs – Generates Domain Controller Certificate Requests.

Creating an Offline Certificate Request

Every X.509 certificate that is issued by a CA requires a unique certificate request to initiate the issuance process. If required, you can create several certificate requests as a batch process before submitting them to a CA.

However, to avoid potential errors and confusion, ensure that you are using unique names for your request files. It is necessary to create the certificate request as a member of the local Administrators group because only this group has interactive logon permissions to a domain controller by default. The first step is to define the input information in an INF file.

To create the INF file that will supply input information for the request, perform the following steps.

  1. Log on as a member of the local Administrators group on the domain controller that requires a certificate.

  2. Make the reqdccert.vbs script, found in Appendix 2, available locally to the domain controller.

  3. If you plan to submit the certificate request to a Windows 2000 or Windows Server 2003 stand-alone CA, run the script from a command-line prompt without any additional parameters. In this case, the Domain Controller certificate template is assumed and the domain controller’s GUID and DNS name are included as a subject alternative name in the issued certificate.

    If you plan to submit the certificate request to a Windows Server 2003 enterprise CA, you must specify the specific name of the certificate template that is used for enrollment. The name depends on the certificate template name that was previously chosen in Certificate Template Creation. In addition, you must specify if the certificate is enrolled for either domain controller authentication or for e-mail replication. This is required because the authentication and e-mail replication templates differ in the subject alternative name construction.

    According to your requirement, run one of the following commands at the command-line prompt.

    To create a certificate request for a domain controller authentication certificate with a custom template:

    cscript reqdccert.vbs <Templatename> A

    To create a certificate request for a directory e-mail replication certificate with a custom template:

    cscript reqdccert.vbs <Templatename> E

    To create a certificate request with the default domain controller template:

    cscript reqdccert.vbs

    The script creates an INF file that is used as an input file to build the certificate request. It also creates some additional syntax that contains the appropriate command syntax to submit the request to the CA and verify the certificate.

    For a detailed description of the tasks that are performed by the script, see Reqdccert.vbs – Generates Domain Controller Certificate Requests in Appendix 2.

  4. Open a command-prompt window. On a Windows 2000 domain controller, type

    %HOMEDRIVE%\W2K3AdmPak\CERTREQ -new <dcname>.inf <dcname>.req

    On a Windows Server 2003 domain controller, type

    CERTREQ -new <dcname>.inf <dcname>.req

    Replace the <dcname> variable with the hostname of the domain controller. If you are unsure of the name, look up the name of the INF file saved in your current directory. Note that it may take a few seconds or minutes before the command prompt returns. Depending on the size and available cycles of the system CPU as well as the key length that was set in the INF file, it may take several minutes for the key material to be generated.

Important

The certreq.exe tool performs several tasks that are often not apparent. First, it generates the public and private key material, and then, it generates the actual certificate request. The key material generation process is the reason why certificate requests must not be generated for several domain controllers on a single computer. The key material must be unique per domain controller to ensure a secure solution.

Viewing the Certificate Request

At this stage, you have successfully generated the public and private key material and created the certificate request. The certificate request is stored in a file and is kept in the Certificate Enrollment Requests store of the local computer. To find the enrollment request that was generated, perform the following steps.

  1. While still logged on as a member of the local Administrators group, start the Microsoft Management console.

  2. Add the Certificates MMC Snap-In.

  3. Select Computer Account when the Add window asks for the certificate store that should be managed.

  4. In the Certificates MMC Snap-In, navigate to Certificate Enrollment Requests in the left pane.

    The certificate request appears in the right pane. It is expected that there is no more than one certificate request pending in this container. Otherwise, this would imply that other certificate request attempts have been submitted but have not yet been approved or accepted.

  5. When you double-click the certificate request, the message “You have a private key that corresponds to this certificate” is displayed in the General tab at the bottom. As mentioned previously, certreq.exe has generated the certificate request and the key material. You can safely ignore the warning at the top of the window that says the certificate might be altered. This is an expected warning since the certificate has not yet been issued.

Verifying a Certificate Request

It is recommended that the offline domain controller certificate request be validated before it is sent to a CA for processing. Verification will ensure that all request fields are set properly and that the certificate, when processed and issued, will provide the expected functionality. To examine the previously generated certificate request, perform the following step.

  • While still logged on as a member of the local Administrators group to the domain controller, type certutil –dump <dcname>.req at a command-line prompt, and then press Enter.

Replace the <dcname> option with the name used in the previous section to generate the offline request. If you have properly created a request that has used the DomainController certificate template, the command will display an output similar to the following:

PKCS10 Certificate Request: 
Version: 1 
Subject: 
    CN=W2K3-BO-DC.contoso2.com 
Public Key Algorithm: 
    Algorithm ObjectId: 1.2.840.113549.1.1.1 RSA 
    Algorithm Parameters: 
    05 00 
Public Key Length: 1024 bits 
Public Key: UnusedBits = 0 
    0000  30 81 89 02 81 81 00 95  b8 e9 18 84 df 95 ce 37 
    0010  ce f6 af 32 40 43 14 d5  0f 7b 3b 76 36 8c dd 8b 
    0020  7c 03 29 33 26 d3 84 c3  7e ae 25 34 ea 1e db 3a 
    0030  b9 01 e3 a7 02 3c 6b 8f  66 99 c8 ac 51 70 03 bc 
    0040  47 06 ef 2f 62 3e c3 8d  e1 51 bd 9d c8 7d 95 8c 
    0050  08 0a bf 54 a6 f3 1d 2f  cd b8 7d 17 fc 4c 7d a5 
    0060  a6 ce 90 d0 a3 21 c5 b0  c1 f0 de ae 00 43 16 cb 
    0070  eb 73 01 e7 71 79 ed dd  72 d0 cc 4a 55 26 a2 99 
    0080  03 21 dc d1 5b b4 b9 02  03 01 00 01 
Request Attributes: 4 
  4 attributes: 
  Attribute[0]: 1.3.6.1.4.1.311.13.2.3 (Operating System Version) 
    Value[0][0]: 
        5.2.3790.2 
  Attribute[1]: 1.3.6.1.4.1.311.21.20 (Client Information) 
    Value[1][0]: 
    Unknown Attribute type 
    Client Id: = 1 
    XECI_XENROLL -- 1 
    User: CONTOSO2\administrator 
    Machine: W2K3-BO-DC.contoso.com 
    Process: certreq 
  Attribute[2]: 1.2.840.113549.1.9.14 (Certificate Extensions) 
    Value[2][0]: 
    Unknown Attribute type 
Certificate Extensions: 4 
    2.5.29.14: Flags = 0, Length = 16 
    Subject Key Identifier 
        55 93 fd 45 5b 22 87 33 95 96 4a 77 e3 ff 08 08 f6 83 de fc 
    2.5.29.17: Flags = 1(Critical), Length = 3c 
    Subject Alternative Name 
        Other Name: 
             1.3.6.1.4.1.311.25.1= 0410 6661 6135 3636 3234 3831 6263 3866 6662 
        DNS Name=W2K3-BO-DC.contoso.com 
    2.5.29.37: Flags = 0, Length = 16 
    Enhanced Key Usage 
        Server Authentication (1.3.6.1.5.5.7.3.1) 
        Client Authentication (1.3.6.1.5.5.7.3.2) 
    2.5.29.15: Flags = 0, Length = 4 
    Key Usage 
        Digital Signature, Key Encipherment (a0) 
  Attribute[3]: 1.3.6.1.4.1.311.13.2.2 (Enrollment CSP) 
    Value[3][0]: 
    Unknown Attribute type 
    CSP Provider Info 
    KeySpec = 1 
    Provider = Microsoft RSA SChannel Cryptographic Provider 
    Signature: UnusedBits=0 
    0000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
    Remaining 78 bytes are zero 
Signature Algorithm: 
    Algorithm ObjectId: 1.2.840.113549.1.1.5 sha1RSA 
    Algorithm Parameters: 
    05 00 
Signature: UnusedBits=0 
    0000  45 4c 4f ca 00 52 36 88  a0 2d 2e 45 f3 87 be ac 
    0010  89 4f 4e d4 19 42 a7 e5  cb 7a 15 d5 eb e2 a0 96 
    0020  6c 39 94 c5 71 d6 e7 03  10 9c 45 a0 ad c7 34 e6 
    0030  f9 f2 31 da ce e2 2e 6f  b7 23 6f 12 53 6a 40 89 
    0040  ba a9 2e 2f bc cf d4 00  72 18 82 05 33 ea 0e 20 
    0050  0b e2 5c 4c 5a 57 b5 71  08 e0 3e d8 8b 0d 18 05 
    0060  7b 11 4d b1 e9 db 16 e5  78 e8 c2 b2 ff bb c2 9d 
    0070  e6 2b 17 83 dc 1d 43 fd  4e 0e 37 58 f0 ac a9 95 
Signature matches Public Key 
Key Id Hash(sha1): 55 93 fd 45 5b 22 87 33 95 96 4a 77 e3 ff 08 08 f6 83 de fc 
CertUtil: -dump command completed successfully.

It should be expected from the output of the certificate request that the majority of attributes from the generated INF file appear in the actual encoded certificate request.

The reqdccert.vbs script creates an INF instruction file that contains the extension information for DNS name and GUID of the domain controller in an encoded format. This enables the certificate requested to be constructed with certreq.exe –new, whereby the extension information will be automatically included in the certificate request from the INF file.

Deleting a Certificate Request

Sometimes it may be necessary to either delete an unneeded or unused certificate request or even delete erroneous certificate requests due to mistakes in the INF input file. If you are logged on as a normal user, you can remove certificate requests only from your own certificate store. However, if you are logged on as Administrator, you can also remove certificate requests from the computer’s certificate store. To delete a certificate request, perform the following steps.

  1. Open the Certificates MMC Snap-In for the computer account (as described previously).

  2. Navigate to Certificate Enrollment Requests in the left pane.

  3. Remove the pending certificate request in the right pane by pressing Delete on your keyboard.

  4. Close the Certificates MMC Snap-In.

  5. If the request has already been submitted to a CA, it may be necessary to also deny the pending request on the CA.

The key material that was generated for the certificate request will remain on the system in the local system (computer) profile unless explicitly deleted by an administrator. Orphaned key material may only be removed manually at the command-line prompt using certutil.exe. However, the administrator will need to know the key container.

Important

If you delete keys manually from your computer, you will invalidate all data that was encrypted with an encryption key. If you have not implemented a key recovery mechanism, it is recommended that you leave unused keys on the system instead of deleting them.

Use the following command to display the list of available key containers for the machine context.

certutil –store my

Use the following command for the current user’s context.

certutil –store –user my

The output will display the key container name for each certificate. Key container names typically are created with random GUID strings as the name.

If you have determined the keycontainername for a specific certificate, you can delete the key container with the following command.

certutil.exe -delkey <KeyContainerName>

The -delkey option is supported only with the Windows Server 2003 version of certutil. On Windows 2000, you must add a prefix to the commands. The prefix is the path you have copied the Windows Server 2003 version of certutil to. In this white paper, the %HOMEDRIVE%\W2K3AdmPak path is used.

Transferring the Request to a CA

Once the request file has been generated and validated on the domain controller, it can be transferred to the CA for processing and issuance. Transfer the following files to the CA.

  • <dcname>-req  This file contains the certificate request that was generated on the domain controller.

  • <dcname>-req.bat  This batch file was created by reqdccert.vbs and contains the correct command-line parameters to submit the request to the CA.

At this point, you can log off of your domain controller.