How to create a CNG HTTPSi cert using a 2008r2 CA

In a previous article we explained how to create a self-signed CNG certificate, suitable for the HTTPS Inspection feature, which can be used to inspect sites using an SHA-256 certificate.

In this article we will explain how to generate a similar certificate using your internal CA based on Windows 2008 R2.

Using a certificate issued by your own CA, rather than a self-signed certificate, has the advantage that you will not have an additional certificate to distribute to the web proxy clients.
Bearing in mind that certificates have a limited validity period and that this eases operation maintenances, since you need only to change only the Subordinate CA certificate on TMG.

Arguably it can be said that if you set a validity period long enough, as some tenth of years, this would not be an issue.
But the truth is that what is considered secure today, might be easily compromised in a couple of years and for that reason, having an easy way to replace your certificates also improves your overall security.
The ability to quickly move to a larger key length or better hash algorithm at any time is the key to an always up to date and secure PKI infrastructure.

Now let's go ahead and create the certificate.
Begin by opening the Certificate Authority administration console, right click on Certificate Templates then Manage.

clip_image001

First step is duplicating the “Subordinate Certification Authority” template.

clip_image003

In Compatibility settings select Windows Server 2008:

clip_image005

Type a display name for the template:

clip_image007

Put the checkbox on “CA certificate manager approval” if you prefer to. If you do you will have to approve the request once submitted.

clip_image009

In the Extensions tab select Key usage then Edit:

clip_image011

Put the checkbox on “Certificate signing” only

clip_image013

Ensure the local Administrator, or your administrative user/group, has Enroll permissions:

clip_image015

Right click on Certificate Templates, New, Certificate Template to Issue:

clip_image017

Select then newly created template then click OK:

clip_image019

The new template will then appear as available:

clip_image021

Then open MMC, add the Certificates snap-in for the Local computer.

Open the Personal container, right click on Certificates, All Tasks, Advanced Operations, Create Custom request:

clip_image023

Select Active Directory Enrollment Policy then click Next:

clip_image025

Select the template then click Next:

clip_image027

Click on Details then Properties:

clip_image029

Enter a Common name then click Add:

clip_image031

Enter a friendly name for the certificate:

clip_image032

In the Private key tab ensure the CSP “Microsoft Software Key Storage Provider” is listed:

clip_image033

Ensure “Mark private key exportable is selected”:

clip_image034

In Select Hash Algorithm select “sha256”:

clip_image035

Then click OK, you will be asked to save the request to a file:

clip_image036

Open an elevated command prompt and execute the command:

certreq -submit -config "<ServerName\CAName>" "<CertificateRequest.req>" "<CertificateResponse.cer>"

The last parameter is required if you have not requested an approval before issuing the certificate.

If no approval is required a .cer will be retrieved, otherwise you will have to refer to the RequestID that will be displayed:

clip_image037

If the approval is required, once the request has been approved in the CA console, enter the following command to retrieve the .cer file:

certreq -retrieve -config "<ServerName\CAName>" <RequestID> "<CertificateResponse.cer>"

Then complete the request with the following command:

certreq -accept -config "<ServerName\CAName>" "<CertificateResponse.cer>"

clip_image038

At this point you will find the new certificate in the Personal store of the local computer and you can export it:

clip_image040

Ensure you export the private key:

clip_image041

Do not select any of the PFX options:

clip_image042

Provide the PFX password when requested and save the file.

Then export the certificate again, this time without the private key:

clip_image043

Click Next then select the DER format:

clip_image044

Click Next then save the .CER file.

Notice that the certificate you have just generated might be signed using the SHA1 Hash algorithm, although we have requested a certificate using SHA256 Hash Algorithm. This happens due to the fact that in some operating systems the Subordinate Certification Authority template forces the key hashing algorithm to be SHA1. This however does not prevent TMG from issuing (signing) certificates with SHA256 hash algorithms.

Also note that Microsoft is phasing out weaker certificates such as SHA1 certificates and certificates with keys under 1024 bits in length. So expect at some point in time this to change.

So don’t be surprised and go ahead with the next steps.

Copy the PFX and the CER files to the TMG box, open the HTTPS Inspection configuration and import the certificate form the PFX file:

clip_image045

Then save and apply the configuration

On the TMG server open an MMC console and add the Certificates snap-in for the local computer.
Then import the .cer file in the Intermediate certificate store.
You will need to restart the TMG server.

clip_image047

Importing the certificate in the Intermediate store is necessary for the TMG server to send the intermediate certificate in the certificate chain so that the client is able to build the trust chain.

This is further explained bellow.

Now you can try from a client browsing a site using a CNG certificate, such as Twitter.
You will see the certificate being signed by the new certificate from your CA:

clip_image048

Notice that this certificate is signed using SHA256:

clip_image049

Regarding the building of the certificate chain

Since the Subordinate CA Certificate (“TMG HTTPS Inspection CNG Ent.CA” in this case) is not published anywhere the clients can’t, on its own find the certificate SubCA certificate.

For a normal certificate issuing CA you would be able to publish the SubCA Certificate and publish to either a LDAP or HTTP location and the clients would be able to look it up, by downloading the certificate from the AIA Extension in the certificate.

In the case of TMG issued certificates, for HTTP inspection, these don’t have an AIA extension.

clip_image051

TMG will send both the certificate for the URL being accessed on the browser (or other client) and the Subordinate CA, configured in TMG to issue these certificates.

Otherwise the client would end up with a certificate that do not built up to a trusted root, having a "gap" in the chain. So as you can see bellow TMG will send the two certificates on “Server Hello” handshake.

clip_image053

The certificate generated, on the fly by TMG, for the HTTPS site you are visiting, will appear as being issued by an intermediate CA represented by the certificate you generated.

That is why it is essential to add the SubCA to the “Intermediate Certification Authorities” store for the “Local Computer”. Otherwise the TMG issued certificates would need to have the AIA sections which would require the intermediate certificate (the one you have just generated) to be published to a AIA location. This would require further configuration on your environment, so TMG provides some help in the Chain validation process and sends the intermediate CA in the "Certificate" section of the SSL handshake as we can see in the “Server Hello” handshake on the network capture above.

Your “Subordinate CA” (TMG HTTPS Inspection CNG Ent.CA) will then have an AIA Extension and from there up to the Root CA. As you can see from the image

clip_image054

This will then allow to build up a valid certificate chain ending up in your Internal CA and starting in the leaf certificate issued by TMG for HTTP Inspection. The bellow picture shows the expected Certificate chain.

clip_image055

 

Author:
Gianni Bragante
Support Engineer – Microsoft Forefront Edge Security Team

Luis Sousa
Support Engineer - Microsoft PKI/AD Team

Reviewer:
Philipp Sand
Sr. Support Escalation Engineer – Microsoft Forefront Edge Security Team