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.

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

In Compatibility settings select Windows Server 2008:

Type a display name for the template:

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

In the Extensions tab select Key usage then Edit:

Put the checkbox on “Certificate signing” only

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

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

Select then newly created template then click OK:

The new template will then appear as available:

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:

Select Active Directory Enrollment Policy then click Next:

Select the template then click Next:

Click on Details then Properties:

Enter a Common name then click Add:

Enter a friendly name for the certificate:

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

Ensure “Mark private key exportable is selected”:

In Select Hash Algorithm select “sha256”:

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

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:

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>"

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

Ensure you export the private key:

Do not select any of the PFX options:

Provide the PFX password when requested and save the file.

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

Click Next then select the DER format:

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:

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.

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:

Notice that this certificate is signed using SHA256:

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.

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.

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

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.

 

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

Comments

• Anonymous
  January 01, 2003
  The comment has been removed
  • Anonymous
    November 03, 2016
    I had the exactly same problem. I cannot create a V3 Tempalte with my 2012R2 CA.Would be greate to get an answer!
  • Anonymous
    November 13, 2016
    The comment has been removed
    • Anonymous
      November 15, 2016
      Finally found solution - you need new CA/SubCA based on 2008/2008R2.
• Anonymous
  September 05, 2014
  218 Microsoft Team blogs searched, 48 blogs have new articles. 97 new articles found searching from 25
• Anonymous
  October 12, 2014
  Article does not mention whether the instruction is valid for a 2008 SP2 CA as well -- all the steps work the same, and the certs are created. Before I import the certs into TMG it would be nice to know if there are any gotchas to u sing a 2008 SP2 CA ... I guess it wasn't tested?