Archive

Archive for the ‘certificate’ Category

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

August 29th, 2014 No comments

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 "<ServerNameCAName>" "<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 "<ServerNameCAName>" <RequestID> "<CertificateResponse.cer>"

Then complete the request with the following command:

certreq -accept -config "<ServerNameCAName>" "<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

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

August 29th, 2014 No comments

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

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

August 29th, 2014 No comments

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 "<ServerNameCAName>" "<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 "<ServerNameCAName>" <RequestID> "<CertificateResponse.cer>"

Then complete the request with the following command:

certreq -accept -config "<ServerNameCAName>" "<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

Group Protected PFX

October 8th, 2012 No comments

A new feature is available in Windows Server 2012 and Windows 8 that allows you to protect exported PFX files (those in PKCS#12) to Active Directory Domain Services (AD DS) accounts. The feature is available only if you have a Windows Server 2012 domain controller deployed in your network. The TechNet Wiki article Certificate PFX Export and Import using AD DS Account Protection describes the feature further.

ExportWizard

Group Protected PFX

October 8th, 2012 No comments

A new feature is available in Windows Server 2012 and Windows 8 that allows you to protect exported PFX files (those in PKCS#12) to Active Directory Domain Services (AD DS) accounts. The feature is available only if you have a Windows Server 2012 domain controller deployed in your network. The TechNet Wiki article Certificate PFX Export and Import using AD DS Account Protection describes the feature further.

ExportWizard

Group Protected PFX

October 8th, 2012 No comments

A new feature is available in Windows Server 2012 and Windows 8 that allows you to protect exported PFX files (those in PKCS#12) to Active Directory Domain Services (AD DS) accounts. The feature is available only if you have a Windows Server 2012 domain controller deployed in your network. The TechNet Wiki article Certificate PFX Export and Import using AD DS Account Protection describes the feature further.

ExportWizard

Blocking RSA keys less than 1024 bits (part 3)

August 14th, 2012 No comments

Microsoft released a security advisory, KB article, and software update for all supported versions of Windows that blocks RSA certificates with keys less than 1024 bits. The software update was released to the Download Center.

The update is available now to allow organizations to assess the impact of this update and to reissue certificates with larger key sizes, if necessary, before the update is sent out through Windows Update. The update is planned to be sent out through Windows Update in October 9, 2012.

Blocking RSA keys less than 1024 bits (part 3)

August 14th, 2012 No comments

Microsoft released a security advisory, KB article, and software update for all supported versions of Windows that blocks RSA certificates with keys less than 1024 bits. The software update was released to the Download Center.

The update is available now to allow organizations to assess the impact of this update and to reissue certificates with larger key sizes, if necessary, before the update is sent out through Windows Update. The update is planned to be sent out through Windows Update in October 9, 2012.

Blocking RSA keys less than 1024 bits (part 3)

August 14th, 2012 No comments

Microsoft released a security advisory, KB article, and software update for all supported versions of Windows that blocks RSA certificates with keys less than 1024 bits. The software update was released to the Download Center.

The update is available now to allow organizations to assess the impact of this update and to reissue certificates with larger key sizes, if necessary, before the update is sent out through Windows Update. The update is planned to be sent out through Windows Update in October 9, 2012.

RSA keys under 1024 bits are blocked

Public key based cryptographic algorithms strength is determined based on the time taken to derive the private key using brute force methods. The algorithm is deemed to be strong enough when the time required to derive private key is prohibitive enough using the computing power at disposal. The threat landscape continues to evolve.  As such, we are further hardening our criteria for the RSA algorithm with key length less than 1024 bits.
To further reduce the risk of unauthorized exposure of sensitive information, Microsoft has created a software update that will be released in August 2012 for the following operating systems: Windows XP, Windows Server 2003, Windows Server 2003 R2, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. This update will block the use of cryptographic keys that are less than 1024 bits.
Some issues that you may encounter after applying this update may include:

  • Error messages when browsing to web sites that have SSL certificates with keys that are less than 1024 bits
  • Problems enrolling for certificates when a certificate request attempts to utilize a key that is less than 1024 bits
  • Creating or consuming email (S/MIME) messages that utilize less than 1024 bit keys for signatures or encryption
  • Installing Active X controls that were signed with less than 1024 bit signatures
  • Installing applications that were signed with less than 1024 bit signatures (unless they were signed prior to January 1, 2010, which will not be blocked by default).

To prepare for this update, you should determine whether your organization is currently using keys less than 1024 bits. If it is, then you should take steps to update your cryptographic settings such that keys under 1024 bits are not in use. 

Certificate Chain Build Block of Keys under 1024 Bits

The Crypto API builds a certificate trust chain and validates that chain using time validity, certificate revocation, and certificate policies (such as intended purposes). Once the update is applied, during chain building there is an additional check to ensure that no certificate in the chain has key length less than 1024 bits). Chain building is done using the CertGetCertificateChain function. If a key chain building issue is encountered with such a certificate, then the errors produced are as follows:
Event 11, CAPI2

• CERT_TRUST_IS_NOT_SIGNATURE_VALID
• CERT_TRUST_HAS_WEAK_SIGNATURE

Working CSPs that Default to Allow Minimum 512 Bit Keys

There are three cryptographic service providers (CSPs) that default
to allow minimum 512 bit keys in Windows Server 2008 R2:

  1. Microsoft Base Cryptographic Provider v1.0 (RSA)
  2. Microsoft Base DSS and Diffie-Hellman
    Cryptographic Provider (DH)
  3. Microsoft DH SChannel Cryptographic Provider
    (DH)

When working with V2 certificate templates, if you do not specify the key size, then the default CSP with default key size will be used to generate the key. If the default CSP is one of the above 3 CSPs on the client box, then the generated key will be under 1024 bits. The CA which has been updated with weak key protection will reject such request. As a result, we recommended that you do the following:

  1. Configure the template to specify the cryptographic providers that you want to be utilized by selecting Requests must use on of the following
    providers
    .
  2. Configure the Minimum key size to 1024 bit or larger.

When using certreq, ensure that you specify a 1024 bit or larger key in the INF file. For additional information, see Best Practice for Configuring Certificate Template Cryptography.

Discovering Usage of Keys under 1024 Bits in Certificate Templates

You can run the following query on your Certification Authorities (CAs) in order to discover certificate templates that are utilizing
keys under 1024 bits:

Certutil -dstemplate | findstr “[ msPKI-Minimal-Key-Size”| findstr /v “1024 2048 4096”

Note: The command should be run in each forest in your organization.

If you run this query, templates that utilize keys that are smaller than 1024 bits will be shown with their key size. The following figure illustrates that two of the built-in templates SmartcardLogon and SmartcardUser templates have default key lengths that have minimum key sizes of 512 bits. You may also discover other templates that were duplicated with minimum key sizes of less than 1024 bits.

For each template you discover that allow less than 1024 bit keys, you should determine whether it is available to issue certificates as shown in the Certificate Templates section of the Certification Authority console.

For these templates, you should consider increasing the Minimum key size to a setting of at least 1024 (assuming the devices to which these certificates are to be issued support a larger key size).

You should use Reenroll All Certificate Holders to cause the client computers to reenroll and request a larger key size (assuming certificate autoenrollment is enabled).

If you have issued certificates using the built-in Smartcard Logon or Smartcard User templates, you will not be able to adjust the minimum key size of the template directly. Instead, you will have to duplicate the template, increase the key size on the duplicated template, and then supersede the original template with the duplicated template.

After you have superseded the template, you should use Reenroll All Certificate Holders to cause the client computers to reenroll and request a larger key size.

Discovering usage of RSA keys under 1024 Bits in Cryptographic Operations

You can utilize CAPI2 logging starting with Windows Vista or Windows Server 2008 computers to help identify keys under 1024 bits. You can then allow the computers to perform their normal operations and check the log after a period of time to help identify such keys. You can then use that information to track down the sources of the certificates and make the necessary updates.

To accomplish this, you must first enable verbose diagnostic logging. To enable verbose mode logging:

  1. Open the Registry Editor (regedit.exe).
  2. Navigate to the following registry key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicescrypt32
  3. Add a DWORD (32-bit) value DiagLevel with value of 0x00000005
  4. Add a QWORD (64-bit) value DiagMatchAnyMask with value of 0x00ffffff

Once you do this, you can then enable CAPI2 operational logging in the Event Viewer. The CAPI2 Operational log is located under Applications and Service Logs, Microsoft, Windows, and CAPI2 in the Event Viewer. To enable logging, right-click the Operational log and select Enable Log.

Once you’ve collected the log, you can use the following filter to reduce the number of entries that you have to search through in order to find certificate operations with keys under 1024 bits. The following filter looks for keys of 512 bits.

<QueryList>

 
<Query Id=”0″
Path=”Microsoft-Windows-CAPI2/Operational”>

   
<Select Path=”Microsoft-Windows-CAPI2/Operational”>Event[UserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyLength=’512‘]]]]] and
UserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyName=’RSA’]]]]]]</Select>

 
</Query>

</QueryList>

You can also query multiple key lengths with a single query. For example, the following filter queries for both 384 bit and 512 bit keys.

<QueryList>

 
<Query Id=”0″
Path=”Microsoft-Windows-CAPI2/Operational”>

   
<Select Path=”Microsoft-Windows-CAPI2/Operational”>Event[UserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyLength=’384‘]]]]] and
UserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyName=’RSA’]]]]]]
or
Event[UserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyLength=’512‘]]]]] and
UserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyName=’RSA’]]]]]]</Select>

 
</Query>

</QueryList>

Discovering issued RSA certificates with keys less than 1024 bits

Ingolfur Arnar Stangeland came up with a certutil command to show whether a CA has issued RSA certificates with keys less than 1024 bits. He published the instructions in his blog post “How to identify if your ADCS has issued any certificates with public keys <1024 bits (in preparation for KB2661254)” http://blogs.technet.com/b/instan/archive/2012/08/03/how-to-identify-if-your-adcs-has-issued-any-certificates-with-public-keys-lt-1024-bits-in-preparation-for-kb2661254.aspx

Additional resources

Security advisory http://technet.microsoft.com/security/advisory/2661254.

KB 2661254: http://support.microsoft.com/kb/2661254

Additional blog posts:

http://blogs.technet.com/b/pki/archive/2012/07/13/blocking-rsa-keys-less-than-1024-bits-part-2.aspx

http://blogs.technet.com/b/pki/archive/2012/08/14/blocking-rsa-keys-less-than-1024-bits-part-3.aspx

Categories: 1024, AD CS, certificate, certificates, key size Tags:

RSA keys under 1024 bits are blocked

Public key based cryptographic algorithms strength is determined based on the time taken to derive the private key using brute force methods. The algorithm is deemed to be strong enough when the time required to derive private key is prohibitive enough using the computing power at disposal. The threat landscape continues to evolve.  As such, we are further hardening our criteria for the RSA algorithm with key length less than 1024 bits.
To further reduce the risk of unauthorized exposure of sensitive information, Microsoft has created a software update that will be released in August 2012 for the following operating systems: Windows XP, Windows Server 2003, Windows Server 2003 R2, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. This update will block the use of cryptographic keys that are less than 1024 bits.
Some issues that you may encounter after applying this update may include:

  • Error messages when browsing to web sites that have SSL certificates with keys that are less than 1024 bits
  • Problems enrolling for certificates when a certificate request attempts to utilize a key that is less than 1024 bits
  • Creating or consuming email (S/MIME) messages that utilize less than 1024 bit keys for signatures or encryption
  • Installing Active X controls that were signed with less than 1024 bit signatures
  • Installing applications that were signed with less than 1024 bit signatures (unless they were signed prior to January 1, 2010, which will not be blocked by default).

To prepare for this update, you should determine whether your organization is currently using keys less than 1024 bits. If it is, then you should take steps to update your cryptographic settings such that keys under 1024 bits are not in use. 

Certificate Chain Build Block of Keys under 1024 Bits

The Crypto API builds a certificate trust chain and validates that chain using time validity, certificate revocation, and certificate policies (such as intended purposes). Once the update is applied, during chain building there is an additional check to ensure that no certificate in the chain has key length less than 1024 bits). Chain building is done using the CertGetCertificateChain function. If a key chain building issue is encountered with such a certificate, then the errors produced are as follows:
Event 11, CAPI2

• CERT_TRUST_IS_NOT_SIGNATURE_VALID
• CERT_TRUST_HAS_WEAK_SIGNATURE

Working CSPs that Default to Allow Minimum 512 Bit Keys

There are three cryptographic service providers (CSPs) that default
to allow minimum 512 bit keys in Windows Server 2008 R2:

  1. Microsoft Base Cryptographic Provider v1.0 (RSA)
  2. Microsoft Base DSS and Diffie-Hellman
    Cryptographic Provider (DH)
  3. Microsoft DH SChannel Cryptographic Provider
    (DH)

When working with V2 certificate templates, if you do not specify the key size, then the default CSP with default key size will be used to generate the key. If the default CSP is one of the above 3 CSPs on the client box, then the generated key will be under 1024 bits. The CA which has been updated with weak key protection will reject such request. As a result, we recommended that you do the following:

  1. Configure the template to specify the cryptographic providers that you want to be utilized by selecting Requests must use on of the following
    providers
    .
  2. Configure the Minimum key size to 1024 bit or larger.

When using certreq, ensure that you specify a 1024 bit or larger key in the INF file. For additional information, see Best Practice for Configuring Certificate Template Cryptography.

Discovering Usage of Keys under 1024 Bits in Certificate Templates

You can run the following query on your Certification Authorities (CAs) in order to discover certificate templates that are utilizing
keys under 1024 bits:

Certutil -dstemplate | findstr “[ msPKI-Minimal-Key-Size”| findstr /v “1024 2048 4096”

Note: The command should be run in each forest in your organization.

If you run this query, templates that utilize keys that are smaller than 1024 bits will be shown with their key size. The following figure illustrates that two of the built-in templates SmartcardLogon and SmartcardUser templates have default key lengths that have minimum key sizes of 512 bits. You may also discover other templates that were duplicated with minimum key sizes of less than 1024 bits.

For each template you discover that allow less than 1024 bit keys, you should determine whether it is available to issue certificates as shown in the Certificate Templates section of the Certification Authority console.

For these templates, you should consider increasing the Minimum key size to a setting of at least 1024 (assuming the devices to which these certificates are to be issued support a larger key size).

You should use Reenroll All Certificate Holders to cause the client computers to reenroll and request a larger key size (assuming certificate autoenrollment is enabled).

If you have issued certificates using the built-in Smartcard Logon or Smartcard User templates, you will not be able to adjust the minimum key size of the template directly. Instead, you will have to duplicate the template, increase the key size on the duplicated template, and then supersede the original template with the duplicated template.

After you have superseded the template, you should use Reenroll All Certificate Holders to cause the client computers to reenroll and request a larger key size.

Discovering usage of RSA keys under 1024 Bits in Cryptographic Operations

You can utilize CAPI2 logging starting with Windows Vista or Windows Server 2008 computers to help identify keys under 1024 bits. You can then allow the computers to perform their normal operations and check the log after a period of time to help identify such keys. You can then use that information to track down the sources of the certificates and make the necessary updates.

To accomplish this, you must first enable verbose diagnostic logging. To enable verbose mode logging:

  1. Open the Registry Editor (regedit.exe).
  2. Navigate to the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\crypt32
  3. Add a DWORD (32-bit) value DiagLevel with value of 0x00000005
  4. Add a QWORD (64-bit) value DiagMatchAnyMask with value of 0x00ffffff

Once you do this, you can then enable CAPI2 operational logging in the Event Viewer. The CAPI2 Operational log is located under Applications and Service Logs, Microsoft, Windows, and CAPI2 in the Event Viewer. To enable logging, right-click the Operational log and select Enable Log.

Once you’ve collected the log, you can use the following filter to reduce the number of entries that you have to search through in order to find certificate operations with keys under 1024 bits. The following filter looks for keys of 512 bits.

<QueryList>

 
<Query Id=”0″
Path=”Microsoft-Windows-CAPI2/Operational”>

   
<Select Path=”Microsoft-Windows-CAPI2/Operational”>Event[UserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyLength=’512‘]]]]] and
UserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyName=’RSA’]]]]]]</Select>

 
</Query>

</QueryList>

You can also query multiple key lengths with a single query. For example, the following filter queries for both 384 bit and 512 bit keys.

<QueryList>

 
<Query Id=”0″
Path=”Microsoft-Windows-CAPI2/Operational”>

   
<Select Path=”Microsoft-Windows-CAPI2/Operational”>Event[UserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyLength=’384‘]]]]] and
UserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyName=’RSA’]]]]]]
or
Event[UserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyLength=’512‘]]]]] and
UserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyName=’RSA’]]]]]]</Select>

 
</Query>

</QueryList>

Discovering issued RSA certificates with keys less than 1024 bits

Ingolfur Arnar Stangeland came up with a certutil command to show whether a CA has issued RSA certificates with keys less than 1024 bits. He published the instructions in his blog post “How to identify if your ADCS has issued any certificates with public keys <1024 bits (in preparation for KB2661254)” http://blogs.technet.com/b/instan/archive/2012/08/03/how-to-identify-if-your-adcs-has-issued-any-certificates-with-public-keys-lt-1024-bits-in-preparation-for-kb2661254.aspx

Additional resources

Security advisory http://technet.microsoft.com/security/advisory/2661254.

KB 2661254: http://support.microsoft.com/kb/2661254

Additional blog posts:

http://blogs.technet.com/b/pki/archive/2012/07/13/blocking-rsa-keys-less-than-1024-bits-part-2.aspx

http://blogs.technet.com/b/pki/archive/2012/08/14/blocking-rsa-keys-less-than-1024-bits-part-3.aspx

Categories: 1024, AD CS, certificate, certificates, key size Tags:

RSA keys under 1024 bits are blocked

June 12th, 2012 No comments

Public key based cryptographic algorithms strength is determined based on the time taken to derive the private key using brute force methods. The algorithm is deemed to be strong enough when the time required to derive private key is prohibitive enough using the computing power at disposal. The threat landscape continues to evolve.  As such, we are further hardening our criteria for the RSA algorithm with key length less than 1024 bits.
To further reduce the risk of unauthorized exposure of sensitive information, Microsoft has created a software update that will be released in August 2012 for the following operating systems: Windows XP, Windows Server 2003, Windows Server 2003 R2, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. This update will block the use of cryptographic keys that are less than 1024 bits.
Some issues that you may encounter after applying this update may include:

  • Error messages when browsing to web sites that have SSL certificates with keys that are less than 1024 bits
  • Problems enrolling for certificates when a certificate request attempts to utilize a key that is less than 1024 bits
  • Creating or consuming email (S/MIME) messages that utilize less than 1024 bit keys for signatures or encryption
  • Installing Active X controls that were signed with less than 1024 bit signatures
  • Installing applications that were signed with less than 1024 bit signatures (unless they were signed prior to January 1, 2010, which will not be blocked by default).

To prepare for this update, you should determine whether your organization is currently using keys less than 1024 bits. If it is, then you should take steps to update your cryptographic settings such that keys under 1024 bits are not in use. 

Certificate Chain Build Block of Keys under 1024 Bits

The Crypto API builds a certificate trust chain and validates that chain using time validity, certificate revocation, and certificate policies (such as intended purposes). Once the update is applied, during chain building there is an additional check to ensure that no certificate in the chain has key length less than 1024 bits). Chain building is done using the CertGetCertificateChain function. If a key chain building issue is encountered with such a certificate, then the errors produced are as follows:
Event 11, CAPI2

• CERT_TRUST_IS_NOT_SIGNATURE_VALID
• CERT_TRUST_HAS_WEAK_SIGNATURE

Working CSPs that Default to Allow Minimum 512 Bit Keys

There are three cryptographic service providers (CSPs) that default
to allow minimum 512 bit keys in Windows Server 2008 R2:

  1. Microsoft Base Cryptographic Provider v1.0 (RSA)
  2. Microsoft Base DSS and Diffie-Hellman
    Cryptographic Provider (DH)
  3. Microsoft DH SChannel Cryptographic Provider
    (DH)

When working with V2 certificate templates, if you do not specify the key size, then the default CSP with default key size will be used to generate the key. If the default CSP is one of the above 3 CSPs on the client box, then the generated key will be under 1024 bits. The CA which has been updated with weak key protection will reject such request. As a result, we recommended that you do the following:

  1. Configure the template to specify the cryptographic providers that you want to be utilized by selecting Requests must use on of the following
    providers
    .
  2. Configure the Minimum key size to 1024 bit or larger.

When using certreq, ensure that you specify a 1024 bit or larger key in the INF file. For additional information, see Best Practice for Configuring Certificate Template Cryptography.

Discovering Usage of Keys under 1024 Bits in Certificate Templates

You can run the following query on your Certification Authorities (CAs) in order to discover certificate templates that are utilizing
keys under 1024 bits:

Certutil -dstemplate | findstr “[ msPKI-Minimal-Key-Size”| findstr /v “1024 2048 4096”

Note: The command should be run in each forest in your organization.

If you run this query, templates that utilize keys that are smaller than 1024 bits will be shown with their key size. The following figure illustrates that two of the built-in templates SmartcardLogon and SmartcardUser templates have default key lengths that have minimum key sizes of 512 bits. You may also discover other templates that were duplicated with minimum key sizes of less than 1024 bits.

For each template you discover that allow less than 1024 bit keys, you should determine whether it is available to issue certificates as shown in the Certificate Templates section of the Certification Authority console.

For these templates, you should consider increasing the Minimum key size to a setting of at least 1024 (assuming the devices to which these certificates are to be issued support a larger key size).

You should use Reenroll All Certificate Holders to cause the client computers to reenroll and request a larger key size (assuming certificate autoenrollment is enabled).

If you have issued certificates using the built-in Smartcard Logon or Smartcard User templates, you will not be able to adjust the minimum key size of the template directly. Instead, you will have to duplicate the template, increase the key size on the duplicated template, and then supersede the original template with the duplicated template.

After you have superseded the template, you should use Reenroll All Certificate Holders to cause the client computers to reenroll and request a larger key size.

Discovering usage of RSA keys under 1024 Bits in Cryptographic Operations

You can utilize CAPI2 logging starting with Windows Vista or Windows Server 2008 computers to help identify keys under 1024 bits. You can then allow the computers to perform their normal operations and check the log after a period of time to help identify such keys. You can then use that information to track down the sources of the certificates and make the necessary updates.

To accomplish this, you must first enable verbose diagnostic logging. To enable verbose mode logging:

  1. Open the Registry Editor (regedit.exe).
  2. Navigate to the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\crypt32
  3. Add a DWORD (32-bit) value DiagLevel with value of 0x00000005
  4. Add a QWORD (64-bit) value DiagMatchAnyMask with value of 0x00ffffff

Once you do this, you can then enable CAPI2 operational logging in the Event Viewer. The CAPI2 Operational log is located under Applications and Service Logs, Microsoft, Windows, and CAPI2 in the Event Viewer. To enable logging, right-click the Operational log and select Enable Log.

Once you’ve collected the log, you can use the following filter to reduce the number of entries that you have to search through in order to find certificate operations with keys under 1024 bits. The following filter looks for keys of 512 bits.

<QueryList>

 
<Query Id=”0″
Path=”Microsoft-Windows-CAPI2/Operational”>

   
<Select Path=”Microsoft-Windows-CAPI2/Operational”>Event[UserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyLength=’512‘]]]]] and
UserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyName=’RSA’]]]]]]</Select>

 
</Query>

</QueryList>

You can also query multiple key lengths with a single query. For example, the following filter queries for both 384 bit and 512 bit keys.

<QueryList>

 
<Query Id=”0″
Path=”Microsoft-Windows-CAPI2/Operational”>

   
<Select Path=”Microsoft-Windows-CAPI2/Operational”>Event[UserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyLength=’384‘]]]]] and
UserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyName=’RSA’]]]]]]
or
Event[UserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyLength=’512‘]]]]] and
UserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyName=’RSA’]]]]]]</Select>

 
</Query>

</QueryList>

Discovering issued RSA certificates with keys less than 1024 bits

Ingolfur Arnar Stangeland came up with a certutil command to show whether a CA has issued RSA certificates with keys less than 1024 bits. He published the instructions in his blog post “How to identify if your ADCS has issued any certificates with public keys <1024 bits (in preparation for KB2661254)” http://blogs.technet.com/b/instan/archive/2012/08/03/how-to-identify-if-your-adcs-has-issued-any-certificates-with-public-keys-lt-1024-bits-in-preparation-for-kb2661254.aspx

Additional resources

Security advisory http://technet.microsoft.com/security/advisory/2661254.

KB 2661254: http://support.microsoft.com/kb/2661254

Additional blog posts:

http://blogs.technet.com/b/pki/archive/2012/07/13/blocking-rsa-keys-less-than-1024-bits-part-2.aspx

http://blogs.technet.com/b/pki/archive/2012/08/14/blocking-rsa-keys-less-than-1024-bits-part-3.aspx

Categories: 1024, AD CS, certificate, certificates, key size Tags:

How to generate a certificate with subject alternative names (SAN)

October 9th, 2011 No comments

When publishing services like Outlook Anywhere, OWA and Active Sync for exchange in ISA/TMG, we sometimes need certificates with subject alternative names (SAN). This enables us to publish multiple DNS names using one SSL Web Listener. Requesting SAN certificates is something we can perform directly through a Microsoft internal CA. However there are some steps to follow before gathering a new certificate that makes use of SANs.

This article explains how to request a new certificate with a SAN from the Microsoft Management Console on the TMG computer.

The following security best practices apply when adding subject alternate names to certificates:

· In general, the use of user-defined SANs can increase the risk of impersonation attacks because it allows a user to specify arbitrary names in a certificate request. Because user input can be abused by persons with malicious intent, precautions should be taken to mitigate the risks associated with the use of user-defined SANs and protect the integrity of your public key infrastructure (PKI).

· Certificate requests that contain SANs should be held in a pending state until they can be reviewed by a certificate manager. For information about configuring certificate templates to require certificate manager approval, see Issuance Requirements.

· Implement administrative procedures for reviewing pending certificate requests and verifying the requester is authorized to use the requested subject names.

· Implement separation of duties and role-based administration to ensure that individuals who can request certificates with SANs cannot also issue them. See Implement Role-Based Administration.

· Restrict usage of SANs to only those individuals that require it, such as administrators who install Web server certificates. For information about configuring certificate template security, see Issuing Certificates Based on Certificate Templates.

· If you must use SAN attributes because your server that requires a certificate with a SAN is running Windows Server 2003, consider completing certificate enrollment procedures on a computer that is running Windows Server 2008 R2, Windows Server 2008, Windows 7, or Windows Vista.

Hence we definitely suggest to make use of the mmc console to generate your SANs certificates.

Generating a certificate using the certificate console on TMG/ISA

To generate a SANs certificate use the Microsoft Management console on the TMG/ISA server as explained in the following paragraphs.

However before running the mmc certificate console we need to duplicate the template “web server” on the CA and make it visible under mmc-> certificate itself.

To accomplish this step we must open the certification authority as enterprise administrator and under certificate templates, right click on “manage”. We will open the certification template console where we have to duplicate the template “web server”. You have to configure it with the permission to be “visible” under the mmc certificate console, by selecting “enroll” in the security tab for the “authenticated users”. Be careful that the template version must be V2 and NOT V3 (2003 and not 2008), as TMG doesn’t support CNG certificates (http://technet.microsoft.com/de-de/library/ee796231.aspx#dfg9o9i8uuy6tre).

Once we have opened it and we have expanded local computer –> personal, we have to right click and chose “all task” and “request new certificate”.

image

After pressing “next” twice and choosing the template model “web server”, which had been duplicated previously, we select details and we must click on “properties”.

At this stage we have the two fields under the subject tab which are of interest:

Subject name -> type-> CN

Alternative name -> type-> DNS

image

Then press “ok”, “enroll” and if everything goes fine, we should get something like this:

image

At this point the certificate has been correctly created and installed under the certificate store.

However from TMG/ISA there is something to do before enrolling the certificate. By design TMG/ISA blocks DCOM and you’ll see an error similar to this:

image

With certutil from the command line you’ll see something like this:

C:\Windows\system32>certutil -ping -config "WIN2008DC.via.santagiulia\via-WIN2008DC-CA"

Connecting to WIN2008DC.via.santagiulia\via-WIN2008DC-CA …

Server could not be reached: The RPC server is unavailable. 0x800706ba (WIN32: 1722)

In TMG/ISA we need to disable the Strict RPC compliance using “edit system policies” -> “authentication services” -> “enforce strict RPC compliance” and apply it. This is because TMG/ISA blocks DCOM by design and DCOM is required to acquire a certificate.

You can also use the following command from the command line to check the CA availability on any server:

C:\Windows\system32>certutil -ping -config "FQDN\CA_Name"

if everything is fine we should get:

C:\Windows\system32>certutil -ping -config "WIN2008DC.via.santagiulia\via-WIN2008DC-CA"

Connecting to WIN2008DC.via.santagiulia\via-WIN2008DC-CA …

Server "via-WIN2008DC-CA" ICertRequest2 interface is alive

CertUtil: -ping command completed successfully.

That’s all. We have successfully created and imported our new SANs certificate.

Please be aware that you need to make sure that this certificate is installed on each node if you’re running an Array of ISA/TMG server, in order to be able to create a SSL listener on each one of the nodes.

Author
Andrea Vescovo
Support Engineer
Microsoft CSS Forefront Edge Team

Technical Reviewer
Philipp Sand
Support Escalation Engineer
Microsoft CSS Forefront Edge Team

Carsten Kinder
Principal Consultant
Microsoft Consulting Services

Categories: certificate, Publishing Tags: