James Carr here and I would like to discuss creating custom certificate request in Windows Vista. When requesting certificates from a Windows 2000/2003 Enterprise Certification Authority, we will use one of the built-in certificate templates. Certificate Templates are used to tell the CA what information should be included in the issued certificate. For more information about certificate templates, please see the following:

Certificate Templates

http://technet2.microsoft.com/windowsserver/en/library/7d82b420-10ef-4f20-a56f-17ee7ee352d21033.mspx?mfr=true

Although certificate templates are very useful in typical enrollment scenarios, they are not very useful in situations where we have one time enrollment needs or we need to submit certificates to non-windows CA's. In these scenarios we can use a utility called Certreq to generate the request, submit the request, and then retrieve the issued certificate. To generate a certificate request, we must use a template file (note: this is not the same as Certificate Templates discussed above, which are stored in Active Directory). Typically this template file will have an .inf extension. It will include the same information as an Active Directory certificate template but the big difference is the formatting.

Prior to Windows Vista, we didn’t have an easy way to create the template. We basically had to create the template file and then troubleshoot the syntax errors that were generated. However, now we can use the Certificate Enrollment Wizard MMC in Windows Vista to generate the request file. The wizard automates the process of creating the template file and then creating the actual certificate request. We can then submit the request file to a third-party CA or use the Certreq utility to submit the request to a Microsoft CA. Today, I want to cover the steps of generating a certificate request using the “Custom Certificate Request” wizard.

So, let’s get down to business:

1. Bring up Certificate Manager by selecting the “Start” button and in the “Start Search” window type “Certmgr.msc” without the quotes.

2. Expand Personal and right click on Certificates. Next select All Tasks -> Advanced Operations -> Create custom request.

3. On the “Before You Begin” page select “Next”.

4. On the “Custom request” we have some options that we can configure:

• Template – Under template we have the following options.
  
• (No template) CNG Key – Cryptography Next Generation is the long term replacement for CryptoAPI. One of the most exciting features of CNG is that it allows developers to use their own cryptographic algorithms or implementations of standard cryptographic algorithms. So as not to put anyone to sleep, I won’t cover this topic right now. However, for more information on CNG, take a look at the following white paper:

          CNG Features
          http://msdn2.microsoft.com/en-us/library/bb204775.aspx

• (No template) Legacy key – Allows for the complete customization of a certificate request. This will be covered later in the blog.
• Built-In Certificate Template – Each template includes a standard set of extensions that indicate additional subject identification information and/or additional key usage information. I.e. what the key can be used for such as signature or encryption.
• Suppress default extensions (Checkbox) - This setting allows for the suppression of these extensions so that we can specify only our custom extensions.
  
• Request Format – A certificate request consists of a distinguished name, a public key, and optionally a set of additional attributes.
  
• PKCS #10 – The most widely used format for certificate request.
• CMC - Typically used for non-Microsoft CAs. However, it must be used when specifying Key Archival.
• For some light reading please see the following RFCs:

          [RFC2986] PKCS #10 Request Format
          http://www.ietf.org/rfc/rfc2986.txt

          [RFC3852] Housley, R. "Cryptographic Message Syntax (CMS)", RFC
          3852, July 2004, http://www.ietf.org/rfc/rfc3852.txt

• For our purposes we will select “(No template) Legacy key” for “Template” and “CMC” for “Request Format”. Then select “Next”.

5. On the “Certificate Information” page, we need to select the “Details” drop-down arrow and then the “Properties” button.

6. Selecting the “Properties” button will bring up the “Certificate Properties” tab page. We will be configuring a “Client Authentication” certificate. I will provide a brief overview of the purpose of each option.

• General
  
• Friendly Name – A name that refers to the certificate.
• Description – A brief description of the certificate purpose or other relevant information.

• Subject – The holder of the private key of a certificate is referred to as the subject. This can be a user, computer, service, or device. Subject names can be presented in the following formats:
  
• Common Name (CN) – Can refer to the full name of the subject i.e. “CN = John Smith”. Typically we don’t specify just the CN for Active Directory authentication. Whereas the CN has to be unique on a per domain basis, it may not be unique in the enterprise.
• Full DN - This refers to the user’s full distinguish name. I.e. “CN=John Smith,CN=Users,DC=<Domain>,DC=Com”. Whereas the CN may not be unique in the enterprise, the FQDN is always unique.
• Email – The email name can be used in place of the CN or FQDN or as part of either as the subject name. The email name would be in the format of johnsmith@domain.com.
• None – A subject name may not be required in all circumstances. A subject alternate name (SAN) can be used instead.
  
• Alternate Name – The subject alternate name is simply a different name by which we can refer to the subject by.
  
• E-mail name – same as above.
• DNS name – Refers to the FQDN of the subject that requested the certificate. This is mostly used for computer certificates.
• User principal name (UPN) – The user principal name is part of the user’s object in the active directory. The format is the same as the email attribute.
• Service principal name (SPN) - This is part of the computer’s object in the active directory.

          For my example, I’m going to configure the certificate as follows:

          Full DN: CN=John Smith,CN=Users,DC=Domain,DC=Com
          User principle name: johnsmith@domain.com

            Then select the “Add” button and the final output will look as follows:

TAB: EXTENSIONS

• Certificate extensions define specific application policies, issuance policies, certificate subject types, and key usage attributes.
  
• Application Policies – Determine the specific purpose that the certificate can be used for.
• Issuance Policies – Define measures that are used to identify the subject of the certificate.
• Certificate Subject Type – This is the certificate template information.
• Key Usage – Our first extension is Key usage which describes what the certificate can be used for. I.e. encryption, decryption, signing etc. For our purposes, we will select the option “Digital signature” and then the “Add” button.
  
• Note: Check Box: Make these key usages critical – This is an indicator that identifies whether or not the information contained in the extension has to be included in the certificate for it to be valid.
  
• Extended Key Usage (application Policies) – Where as Key Usage determines what the certificate can be used for, Extended Key Usage determines how it can be used. I.e. for Client authentication, server authentication, code signing, etc. For our purposes we will use “Client Authentication” and then select the “Add” button.

• Note: Check Box: Make the Extended Key Usages critical – This is an indicator that identifies whether or not the information contained in the extension has to be included in the certificate for it to be valid.
  
• Basic Constraints – Allows a certificate to designate whether the certificate is issued to a CA or to an end entity, i.e. user, computer, devices, etc. Nothing needs to be configured.
• Include Symmetric algorithm – This option allows for the inclusion of symmetric algorithms used for encryption. For our purposes, nothing needs to be configured.
• Custom extension definition – This allows for the inclusion of custom application policies. The policy can be defined by specifying the object identifiers (OID's). For our purposes, nothing needs to be configured.

TAB: PRIVATE KEY

• Cryptographic Service Provider – A CSP is a program which generates and manages certificate key pairs. There are several built in CSP’s with “Microsoft Strong Cryptographic Provider” being the most popular. This is the CSP that we will use for our blog.
  
• Key Options –
  
• Key size – The larger the key size the longer the encryption/decryption process. But the stronger the key protection.
• Make private key exportable – We may want the key to be exportable if we’re going to need the certificate on multiple machines.
  Allow private key to be archived – This option allows for a copy of the end entities private key to be stored on the CA.
  Strong private key protection – With this option the private key is password protected in the certificate store. Then when access is needed to the private key the user receives a prompt for the password.
  
• For our purposes, set “Key size” to 1024 and select the option “Make private key exportable”.
  
• Key Type – The best way to describe key type is to think in terms of S/MIME. S/MIME provides both a digital signature and encryption services for the delivery of email.
  
• Exchange - Refers to how encryption keys are exchanged. With S/MIME the sender encrypts email with the recipient’s public key and the recipient decrypts the message with their private key.
• Signature – Refers to proving the identity of the sender. The message itself is not encrypted, however, if the message is tampered with while in transit, it invalidates the signature.
• For our purposes we need to prove our identity to a remote server so we will use “Signature”.

TAB: SIGNATURE

• Registration Authority – The RA is used to sign all certificate requests prior to them being submitted to a CA. This is used when requesting certificates on behalf of another entity. For now we will leave this setting as not configured and then select “Ok”.

This brings us back to the “Certificate Enrollment” page where we can now select “Next”.

7. On the “Where do you want to save the offline request?” page, set “File Name” to “C:\Temp\Request.req” and “File Format” to “Base 64” and then select “Finish”.

• We can save the file in one of two encoding formats:
  
• Base 64 – This is an encoding method developed for use with Secure/Multipurpose Internet Mail Extensions (S/MIME), which is a popular, standard method for transferring binary attachments over the Internet. (RFC 3548 - The Base16, Base32, and Base64 Data Encodings)
• Binary – DER (Distinguished Encoding Rules) for ASN.1, as defined in ITU-T Recommendation X.509, might be used by certification authorities that are not on computers running Windows Server 2003, so it is supported for interoperability. DER certificate files use the .cer extension. (RFC 2511 - Internet X.509 Certificate Request Message Format)

To see the contents of the certificate we can go to the “Certificate Enrollment Requests” container:

We can bring up the request by double-clicking on it:

The error message under “Certificate Information” is expected since at this point the certificate is a self-signed certificate and is not included in the “Trusted Root Certification Authorities Store”. The error will go away once we have issued the certificate and verified that the issuer of the certificate has been placed in appropriate store i.e., “Trusted Root Certification Authorities” if the issuer is a root CA or “Intermediate Certification Authorities” if the issuer is a subordinate.

Lastly, we can go to the “Details” tab to verify the Subject Name:

We will also want to verify the “Subject Alternate Name”:

Finally “Enhanced Key Usage”:

Issuing the Certificate

Now that we have the request file, we can submit the certificate to a Certification Authority (CA). For our purposes we will submit the certificate to a Microsoft CA. However, this can be submitted to any third party CA. For our purposes, we can run Certreq, to submit the request. The commands are as follows.

• The cool thing about submitting the request in this way is that we can select the CA that we would like to use. After hitting “Enter” we will see the following dialog:

Select the CA and then select OK. We will then get our issued certificate. The output will look as follows:

Now that we have our certificate, we will need to add the certificate to the appropriate store. A common mistake is to simply import the certificate into the personal store via the MMC. However, this will not re-associate the key pair. Remember that the private key was created when we submitted the certificate request to the CA. Now for the certificate to be valid, we associate the public/private key pair. We can do this by running the following command:

• Please note that for a user certificate we use “–User” for a machine we will use      “-Machine”.

At this point the certificate has been added to the store. We can confirm this by running the following command:

For a Machine Certificate: Certutil -Store MY
For a User Certificate: Certutil –User –Store My

The output will look as follows:

Additional Information:

Appendix 3: Certreq.exe Syntax
http://technet2.microsoft.com/windowsserver/en/library/008acdeb-0650-4063-a9a2-1258b3229d4f1033.mspx?mfr=true

Appendix A: Certificate Request Structure
http://technet2.microsoft.com/windowsserver/en/library/76cbcd89-125f-45f2-a4df-52dc96669b871033.mspx?pf=true

Certificate Templates
http://technet2.microsoft.com/windowsserver/en/library/7d82b420-10ef-4f20-a56f-17ee7ee352d21033.mspx?mfr=true

So as you can see, this is much easier than the old way, where we had to manually build a .inf file and then use Certreq to generate the certificate request. Not only does Vista make this process much easier but it’s also gives administrators complete control on how to customize certificate requests. I hope you’ve enjoyed the blog and please take a look at the links below for some additional information.

Thanks,

- James Carr