Archive

Archive for the ‘certificates’ Category

Certificate for WinRT devices and non-domain member devices

December 11th, 2012 No comments

Hi there, I am a test engineer in the Windows team working on certificate enrollment related areas. Today I want to talk about certificates for Windows RT devices

Windows RT devices run on ARM processor, which is different from a typical computer, but it does have a full version of the Windows® operating system. Windows RT devices cannot be Active Directory Domain Services (AD DS) domain members. Otherwise, a Windows RT device is no different than a typical Windows computer from certificate enrollment and certificate management perspective. In another words, when it comes to certificate enrollment and certificate management, Windows RT devices share the same story with typical Windows computers that are not joined to an AD DS domain.

Prior to Windows RT, a typical Windows computer, could have a certificate in both the computer context and user context. Certificates in the computer context are stored in the computer account profile, these certificates are organized into different certificate stores, (My store, Root store, and so on). Each user would also have its own certificate stores in the user profile (with certificate stores similar to those in the computer context). The Windows Store apps used on Windows 8 and Windows RT devices also have their own profile and  owner certificate stores.

This means that Windows 8 and Windows RT devices can place their certificates in the Local Machine/My certificate store, User/My certificate store, or an application specific My certificate store. Further, a Windows Store app could use certificates from the computer Root store for certificate validation (chain building). Also, if a Windows Store app has SharedUserCertificate capability, the App can use certificates from the user context My store. 

Enroll for a computer or user certificate by using a Windows RT device

This section covers enrolling for certificates  using the computer context or user context on Windows RT devices (enrolling for Windows Store Apps is covered later).

As noted above, this is the same as enrollment for certificate on a typical Windows computer.  You can enroll for a certificate by using CA Web pages; you can also import a certificate using PFX file.  A domain member computer would have the additional benefit of certificate auto-enrollment, which automatically enrolls and renew certificates for computers or user. For computers that are not domain joined, you can use Certificate Enrollment Web Services to achieve the same. For more information, see the AskDS blog titled Enabling CEP and CES for enrolling non-domain joined computers for certificates for some detailed steps. 

In this section I will illustrate how you can use Windows PowerShell script to automate the enrollment process, and configured the certificate for automatic renewal, utilizing some Windows 8 features. I will break this into several steps. 

1. Establish trust to the Certificate Enrollment Policy Web Services and Certificate Enrollment Web Services

In order to enroll for a certificate using Certificate Enrollment Policy Web Services and Certificate Enrollment Web Services, you must trust these service’s HTTPS server certificate. You can import the CA root of these service certificates into the computer’s Trusted Root Certification Authorities store, using the following
command:

Import-Certificate -CertStoreLocation
cert:LocalMachineRoot -FilePath  $rootCert

2. Enrollment for a certificate

There are several ways to use Certificate Enrollment Policy Web Services, you can configure the Certificate Enrollment Policy Web Services URL in local Group Policy, or configure the URL during enrollment, or embed the URL in a script  (without having to registering the URL in advance in Group Policy). You can find the details in the documents for  Certificate Enrollment Policy Web Services and Certificate Enrollment Web Services. For this example, a Windows PowerShell cmdlet Certificate Enrollment Policy Web Services and enroll for a certificate, using username/password authentication.  

$upCepUrl = “https://MyCepUrl.com

$pwd = ConvertTo-SecureString “MyPassword” -asplaintext -force

$upCred = New-Object System.Management.Automation.PSCredential $userName, $Pwd

Get-Certificate -CertStoreLocation cert:CurrentUserMy -Url $upCepUrl -Credential $upCred -Template MyUserTemplate

Notes:

  • The Certificate Enrollment Policy Web Services URL (https://MyCepUrl.com) as well as the MyUserTemplate variables shown in the sample script should be replaced with the actual values appropriate for your environment
  • The example script enrolls a certificate for the user context. To enroll a certificate for the computer, change the CertStoreLocation from cert:CurrentUserMy to cert:LocalMachineMy

3. Configure certificate for auto renewal

Enrolling for the certificate is done through a Certificate Enrollment Policy Web Service with Username/Password authentication. The same Certificate Enrollment Policy Web Service instance can be used for autorenewal, but the credential must be saved and the credential must be accurate when the certificate is close to expiration. Maintaining these credentials causes additional administrative workload.

In Windows Server 2012 and Windows 8, a new feature to solve ease credential management maintenance. On the server side, a new feature called key-based renewal. This feature allows you to renew a certificate (as long as you have an existing valid certificate and its private key). Certificate Enrollment Policy Web Service and also Certificate Enrollment Web Service were updated to support this feature. To learn more, see Test Lab Guide: Demonstrating Certificate Key-Based Renewal and Test Lab Guide Mini-Module: Cross-Forest Certificate Enrollment using Certificate Enrollment Web Service.

On the client side, the autoenrollment process was updated to select a certificate to authenticate to Certificate Enrollment Policy Web Service when saved credentials do not exist. The service is designed to select a certificate that will mostly succeed in authentication. In such a case the expectation is that the enrolled certificate will be used for SSL client authentication (when connecting to Certificate Enrollment Policy Web Service and Certificate Enrollment Web Service.  Certificate Enrollment Policy Web Service and Certificate Enrollment Web Service will accept the client certificate even if the certificate does not map to an Active Directory Domain Service (AD DS) account. The Certificate Enrollment Web Service will submit the request to the CA, which in turn will issue a new certificate based on the fact that the client owns the certificate and private key. The script below will enables autoenrollment and then configures the Certificate Enrollment Policy Web Service URL in the registry. These two items are enough for autoenrollment to renew the certificate.  

$certCepUrl = “https://MyKeyBasedRenewalCepUrl.com

Set-CertificateAutoEnrollmentPolicy -EnableAll -context user

$added = Add-CertificateEnrollmentPolicyServer -context User -Url $certCep -Credential $cert -AutoEnrollmentEnabled

 Notes:

  • In the example script, ensure that you replace MyKeyBasedRenewalCepURL with the actual Certificate Enrollment Policy Web Service URL for your environment.
  • To utilize the computer context. You can change the -context parameter to specify machine instead of User.

4. Test the renewal

For a practical deployment, I am sure administrator will want to test the functionality before the actual deployment. Typically, a certificate is valid for months or years before it expires, to test the auto renewal, you can create a short lived certificate, which can be accomplished by one of
these:

  • Before enrollment, set the validity period in the certificate template to be a short time (such as1 hour). This way the enrolled certificate  expire quickly enough for you to test within a short period of time.
  • If you have access to certificate issuer’s private key, you can also re-sign the certificate using certutil -sign. You can change certificate validity times so that the certificate expired at any time you want, this is an example of this command:

    Certutil -f -silent -v -sign originalCert.cer newCert.cer 01/01/2012+365:00

This command will take the original certificate (orginalCert.cer in the example) as input, resign the certficate so that it’s valid from 01/01/2012, and valid for 365 days. If you are testing the cert at the end of year 2012, autoenrollment should renew this certificate.

Another issues is that autoenrollment runs only upon user sign-in or run every 8 hours. After setting up your certificate and everything, you can you can use certutil -pulse (for computer context) or certutil -user -pulse (for user context) to manually trigger autoenrollment. You can check the status and history of the
autoenrollment task from task scheduler, the tasks are at this path: Microsoft -> Windows -> CertificateServicesClient 

Getting certificate for a Windows Store App

To get a certificate into a Windows Store App’s certificate stores, you can use the CertificateEnrollmentManager class. The class provide methods to enroll for a certificate or to import a certificate from a PFX file.

Note: For enrollment, the class does not provide a way to submit request to a CA. The app is expected to submit the certificate request to an external server by using standard commication protocols such as HTTP. You can submit the request to Certificate Enrollment Web Services or to third-party CAs. The user is responsibe for creating the request by using a syntax that the server supports. 

For more information about manage certificate for Windows Store apps, see Working with certificates (Windows Store apps using JavaScript and HTML) (Windows).

 

———— Comments were accidentally disabled for this article, so I am placing a comment that came in for this article in this section ————————

Comment from Vadims Podāns:

The following example PowerShell script lines in this article:

$pwd = ConvertTo-SecureString “MyPassword” -asplaintext -force
$upCred = New-Object System.Management.Automation.PSCredential $userName, $Pwd

can be replaced with a Get-Credential cmdlet call. Just remove previous lines and use the following syntax:

Get-Certificate -CertStoreLocation cert:CurrentUserMy -Url $upCepUrl -Credential (Get-Credential) -Template MyUserTemplate

The command automatically prompts for authentication credentials.

Certificate for WinRT devices and non-domain member devices

December 11th, 2012 No comments

Hi there, I am a test engineer in the Windows team working on certificate enrollment related areas. Today I want to talk about certificates for Windows RT devices

Windows RT devices run on ARM processor, which is different from a typical computer, but it does have a full version of the Windows® operating system. Windows RT devices cannot be Active Directory Domain Services (AD DS) domain members. Otherwise, a Windows RT device is no different than a typical Windows computer from certificate enrollment and certificate management perspective. In another words, when it comes to certificate enrollment and certificate management, Windows RT devices share the same story with typical Windows computers that are not joined to an AD DS domain.

Prior to Windows RT, a typical Windows computer, could have a certificate in both the computer context and user context. Certificates in the computer context are stored in the computer account profile, these certificates are organized into different certificate stores, (My store, Root store, and so on). Each user would also have its own certificate stores in the user profile (with certificate stores similar to those in the computer context). The Windows Store apps used on Windows 8 and Windows RT devices also have their own profile and  owner certificate stores.

This means that Windows 8 and Windows RT devices can place their certificates in the Local Machine/My certificate store, User/My certificate store, or an application specific My certificate store. Further, a Windows Store app could use certificates from the computer Root store for certificate validation (chain building). Also, if a Windows Store app has SharedUserCertificate capability, the App can use certificates from the user context My store. 

Enroll for a computer or user certificate by using a Windows RT device

This section covers enrolling for certificates  using the computer context or user context on Windows RT devices (enrolling for Windows Store Apps is covered later).

As noted above, this is the same as enrollment for certificate on a typical Windows computer.  You can enroll for a certificate by using CA Web pages; you can also import a certificate using PFX file.  A domain member computer would have the additional benefit of certificate auto-enrollment, which automatically enrolls and renew certificates for computers or user. For computers that are not domain joined, you can use Certificate Enrollment Web Services to achieve the same. For more information, see the AskDS blog titled Enabling CEP and CES for enrolling non-domain joined computers for certificates for some detailed steps. 

In this section I will illustrate how you can use Windows PowerShell script to automate the enrollment process, and configured the certificate for automatic renewal, utilizing some Windows 8 features. I will break this into several steps. 

1. Establish trust to the Certificate Enrollment Policy Web Services and Certificate Enrollment Web Services

In order to enroll for a certificate using Certificate Enrollment Policy Web Services and Certificate Enrollment Web Services, you must trust these service’s HTTPS server certificate. You can import the CA root of these service certificates into the computer’s Trusted Root Certification Authorities store, using the following
command:

Import-Certificate -CertStoreLocation
cert:\LocalMachine\Root -FilePath  $rootCert

2. Enrollment for a certificate

There are several ways to use Certificate Enrollment Policy Web Services, you can configure the Certificate Enrollment Policy Web Services URL in local Group Policy, or configure the URL during enrollment, or embed the URL in a script  (without having to registering the URL in advance in Group Policy). You can find the details in the documents for  Certificate Enrollment Policy Web Services and Certificate Enrollment Web Services. For this example, a Windows PowerShell cmdlet Certificate Enrollment Policy Web Services and enroll for a certificate, using username/password authentication.  

$upCepUrl = “https://MyCepUrl.com

$pwd = ConvertTo-SecureString “MyPassword” -asplaintext -force

$upCred = New-Object System.Management.Automation.PSCredential $userName, $Pwd

Get-Certificate -CertStoreLocation cert:\CurrentUser\My -Url $upCepUrl -Credential $upCred -Template MyUserTemplate

Notes:

  • The Certificate Enrollment Policy Web Services URL (https://MyCepUrl.com) as well as the MyUserTemplate variables shown in the sample script should be replaced with the actual values appropriate for your environment
  • The example script enrolls a certificate for the user context. To enroll a certificate for the computer, change the CertStoreLocation from cert:\CurrentUser\My to cert:\LocalMachine\My

3. Configure certificate for auto renewal

Enrolling for the certificate is done through a Certificate Enrollment Policy Web Service with Username/Password authentication. The same Certificate Enrollment Policy Web Service instance can be used for autorenewal, but the credential must be saved and the credential must be accurate when the certificate is close to expiration. Maintaining these credentials causes additional administrative workload.

In Windows Server 2012 and Windows 8, a new feature to solve ease credential management maintenance. On the server side, a new feature called key-based renewal. This feature allows you to renew a certificate (as long as you have an existing valid certificate and its private key). Certificate Enrollment Policy Web Service and also Certificate Enrollment Web Service were updated to support this feature. To learn more, see Test Lab Guide: Demonstrating Certificate Key-Based Renewal and Test Lab Guide Mini-Module: Cross-Forest Certificate Enrollment using Certificate Enrollment Web Service.

On the client side, the autoenrollment process was updated to select a certificate to authenticate to Certificate Enrollment Policy Web Service when saved credentials do not exist. The service is designed to select a certificate that will mostly succeed in authentication. In such a case the expectation is that the enrolled certificate will be used for SSL client authentication (when connecting to Certificate Enrollment Policy Web Service and Certificate Enrollment Web Service.  Certificate Enrollment Policy Web Service and Certificate Enrollment Web Service will accept the client certificate even if the certificate does not map to an Active Directory Domain Service (AD DS) account. The Certificate Enrollment Web Service will submit the request to the CA, which in turn will issue a new certificate based on the fact that the client owns the certificate and private key. The script below will enables autoenrollment and then configures the Certificate Enrollment Policy Web Service URL in the registry. These two items are enough for autoenrollment to renew the certificate.  

$certCepUrl = “https://MyKeyBasedRenewalCepUrl.com

Set-CertificateAutoEnrollmentPolicy -EnableAll -context user

$added = Add-CertificateEnrollmentPolicyServer -context User -Url $certCep -Credential $cert -AutoEnrollmentEnabled

 Notes:

  • In the example script, ensure that you replace MyKeyBasedRenewalCepURL with the actual Certificate Enrollment Policy Web Service URL for your environment.
  • To utilize the computer context. You can change the -context parameter to specify machine instead of User.

4. Test the renewal

For a practical deployment, I am sure administrator will want to test the functionality before the actual deployment. Typically, a certificate is valid for months or years before it expires, to test the auto renewal, you can create a short lived certificate, which can be accomplished by one of
these:

  • Before enrollment, set the validity period in the certificate template to be a short time (such as1 hour). This way the enrolled certificate  expire quickly enough for you to test within a short period of time.
  • If you have access to certificate issuer’s private key, you can also re-sign the certificate using certutil -sign. You can change certificate validity times so that the certificate expired at any time you want, this is an example of this command:

    Certutil -f -silent -v -sign originalCert.cer newCert.cer 01/01/2012+365:00

This command will take the original certificate (orginalCert.cer in the example) as input, resign the certficate so that it’s valid from 01/01/2012, and valid for 365 days. If you are testing the cert at the end of year 2012, autoenrollment should renew this certificate.

Another issues is that autoenrollment runs only upon user sign-in or run every 8 hours. After setting up your certificate and everything, you can you can use certutil -pulse (for computer context) or certutil -user -pulse (for user context) to manually trigger autoenrollment. You can check the status and history of the
autoenrollment task from task scheduler, the tasks are at this path: Microsoft -> Windows -> CertificateServicesClient 

Getting certificate for a Windows Store App

To get a certificate into a Windows Store App’s certificate stores, you can use the CertificateEnrollmentManager class. The class provide methods to enroll for a certificate or to import a certificate from a PFX file.

Note: For enrollment, the class does not provide a way to submit request to a CA. The app is expected to submit the certificate request to an external server by using standard commication protocols such as HTTP. You can submit the request to Certificate Enrollment Web Services or to third-party CAs. The user is responsibe for creating the request by using a syntax that the server supports. 

For more information about manage certificate for Windows Store apps, see Working with certificates (Windows Store apps using JavaScript and HTML) (Windows).

 

———— Comments were accidentally disabled for this article, so I am placing a comment that came in for this article in this section ————————

Comment from Vadims Podāns:

The following example PowerShell script lines in this article:

$pwd = ConvertTo-SecureString “MyPassword” -asplaintext -force
$upCred = New-Object System.Management.Automation.PSCredential $userName, $Pwd

can be replaced with a Get-Credential cmdlet call. Just remove previous lines and use the following syntax:

Get-Certificate -CertStoreLocation cert:\CurrentUser\My -Url $upCepUrl -Credential (Get-Credential) -Template MyUserTemplate

The command automatically prompts for authentication credentials.

Certificate for WinRT devices and non-domain member devices

December 11th, 2012 No comments

Hi there, I am a test engineer in the Windows team working on certificate enrollment related areas. Today I want to talk about certificates for Windows RT devices

Windows RT devices run on ARM processor, which is different from a typical computer, but it does have a full version of the Windows® operating system. Windows RT devices cannot be Active Directory Domain Services (AD DS) domain members. Otherwise, a Windows RT device is no different than a typical Windows computer from certificate enrollment and certificate management perspective. In another words, when it comes to certificate enrollment and certificate management, Windows RT devices share the same story with typical Windows computers that are not joined to an AD DS domain.

Prior to Windows RT, a typical Windows computer, could have a certificate in both the computer context and user context. Certificates in the computer context are stored in the computer account profile, these certificates are organized into different certificate stores, (My store, Root store, and so on). Each user would also have its own certificate stores in the user profile (with certificate stores similar to those in the computer context). The Windows Store apps used on Windows 8 and Windows RT devices also have their own profile and  owner certificate stores.

This means that Windows 8 and Windows RT devices can place their certificates in the Local Machine/My certificate store, User/My certificate store, or an application specific My certificate store. Further, a Windows Store app could use certificates from the computer Root store for certificate validation (chain building). Also, if a Windows Store app has SharedUserCertificate capability, the App can use certificates from the user context My store. 

Enroll for a computer or user certificate by using a Windows RT device

This section covers enrolling for certificates  using the computer context or user context on Windows RT devices (enrolling for Windows Store Apps is covered later).

As noted above, this is the same as enrollment for certificate on a typical Windows computer.  You can enroll for a certificate by using CA Web pages; you can also import a certificate using PFX file.  A domain member computer would have the additional benefit of certificate auto-enrollment, which automatically enrolls and renew certificates for computers or user. For computers that are not domain joined, you can use Certificate Enrollment Web Services to achieve the same. For more information, see the AskDS blog titled Enabling CEP and CES for enrolling non-domain joined computers for certificates for some detailed steps. 

In this section I will illustrate how you can use Windows PowerShell script to automate the enrollment process, and configured the certificate for automatic renewal, utilizing some Windows 8 features. I will break this into several steps. 

1. Establish trust to the Certificate Enrollment Policy Web Services and Certificate Enrollment Web Services

In order to enroll for a certificate using Certificate Enrollment Policy Web Services and Certificate Enrollment Web Services, you must trust these service’s HTTPS server certificate. You can import the CA root of these service certificates into the computer’s Trusted Root Certification Authorities store, using the following
command:

Import-Certificate -CertStoreLocation
cert:\LocalMachine\Root -FilePath  $rootCert

2. Enrollment for a certificate

There are several ways to use Certificate Enrollment Policy Web Services, you can configure the Certificate Enrollment Policy Web Services URL in local Group Policy, or configure the URL during enrollment, or embed the URL in a script  (without having to registering the URL in advance in Group Policy). You can find the details in the documents for  Certificate Enrollment Policy Web Services and Certificate Enrollment Web Services. For this example, a Windows PowerShell cmdlet Certificate Enrollment Policy Web Services and enroll for a certificate, using username/password authentication.  

$upCepUrl = “https://MyCepUrl.com

$pwd = ConvertTo-SecureString “MyPassword” -asplaintext -force

$upCred = New-Object System.Management.Automation.PSCredential $userName, $Pwd

Get-Certificate -CertStoreLocation cert:\CurrentUser\My -Url $upCepUrl -Credential $upCred -Template MyUserTemplate

Notes:

  • The Certificate Enrollment Policy Web Services URL (https://MyCepUrl.com) as well as the MyUserTemplate variables shown in the sample script should be replaced with the actual values appropriate for your environment
  • The example script enrolls a certificate for the user context. To enroll a certificate for the computer, change the CertStoreLocation from cert:\CurrentUser\My to cert:\LocalMachine\My

3. Configure certificate for auto renewal

Enrolling for the certificate is done through a Certificate Enrollment Policy Web Service with Username/Password authentication. The same Certificate Enrollment Policy Web Service instance can be used for autorenewal, but the credential must be saved and the credential must be accurate when the certificate is close to expiration. Maintaining these credentials causes additional administrative workload.

In Windows Server 2012 and Windows 8, a new feature to solve ease credential management maintenance. On the server side, a new feature called key-based renewal. This feature allows you to renew a certificate (as long as you have an existing valid certificate and its private key). Certificate Enrollment Policy Web Service and also Certificate Enrollment Web Service were updated to support this feature. To learn more, see Test Lab Guide: Demonstrating Certificate Key-Based Renewal and Test Lab Guide Mini-Module: Cross-Forest Certificate Enrollment using Certificate Enrollment Web Service.

On the client side, the autoenrollment process was updated to select a certificate to authenticate to Certificate Enrollment Policy Web Service when saved credentials do not exist. The service is designed to select a certificate that will mostly succeed in authentication. In such a case the expectation is that the enrolled certificate will be used for SSL client authentication (when connecting to Certificate Enrollment Policy Web Service and Certificate Enrollment Web Service.  Certificate Enrollment Policy Web Service and Certificate Enrollment Web Service will accept the client certificate even if the certificate does not map to an Active Directory Domain Service (AD DS) account. The Certificate Enrollment Web Service will submit the request to the CA, which in turn will issue a new certificate based on the fact that the client owns the certificate and private key. The script below will enables autoenrollment and then configures the Certificate Enrollment Policy Web Service URL in the registry. These two items are enough for autoenrollment to renew the certificate.  

$certCepUrl = “https://MyKeyBasedRenewalCepUrl.com

Set-CertificateAutoEnrollmentPolicy -EnableAll -context user

$added = Add-CertificateEnrollmentPolicyServer -context User -Url $certCep -Credential $cert -AutoEnrollmentEnabled

 Notes:

  • In the example script, ensure that you replace MyKeyBasedRenewalCepURL with the actual Certificate Enrollment Policy Web Service URL for your environment.
  • To utilize the computer context. You can change the -context parameter to specify machine instead of User.

4. Test the renewal

For a practical deployment, I am sure administrator will want to test the functionality before the actual deployment. Typically, a certificate is valid for months or years before it expires, to test the auto renewal, you can create a short lived certificate, which can be accomplished by one of
these:

  • Before enrollment, set the validity period in the certificate template to be a short time (such as1 hour). This way the enrolled certificate  expire quickly enough for you to test within a short period of time.
  • If you have access to certificate issuer’s private key, you can also re-sign the certificate using certutil -sign. You can change certificate validity times so that the certificate expired at any time you want, this is an example of this command:

    Certutil -f -silent -v -sign originalCert.cer newCert.cer 01/01/2012+365:00

This command will take the original certificate (orginalCert.cer in the example) as input, resign the certficate so that it’s valid from 01/01/2012, and valid for 365 days. If you are testing the cert at the end of year 2012, autoenrollment should renew this certificate.

Another issues is that autoenrollment runs only upon user sign-in or run every 8 hours. After setting up your certificate and everything, you can you can use certutil -pulse (for computer context) or certutil -user -pulse (for user context) to manually trigger autoenrollment. You can check the status and history of the
autoenrollment task from task scheduler, the tasks are at this path: Microsoft -> Windows -> CertificateServicesClient 

Getting certificate for a Windows Store App

To get a certificate into a Windows Store App’s certificate stores, you can use the CertificateEnrollmentManager class. The class provide methods to enroll for a certificate or to import a certificate from a PFX file.

Note: For enrollment, the class does not provide a way to submit request to a CA. The app is expected to submit the certificate request to an external server by using standard commication protocols such as HTTP. You can submit the request to Certificate Enrollment Web Services or to third-party CAs. The user is responsibe for creating the request by using a syntax that the server supports. 

For more information about manage certificate for Windows Store apps, see Working with certificates (Windows Store apps using JavaScript and HTML) (Windows).

 

———— Comments were accidentally disabled for this article, so I am placing a comment that came in for this article in this section ————————

Comment from Vadims Podāns:

The following example PowerShell script lines in this article:

$pwd = ConvertTo-SecureString “MyPassword” -asplaintext -force
$upCred = New-Object System.Management.Automation.PSCredential $userName, $Pwd

can be replaced with a Get-Credential cmdlet call. Just remove previous lines and use the following syntax:

Get-Certificate -CertStoreLocation cert:\CurrentUser\My -Url $upCepUrl -Credential (Get-Credential) -Template MyUserTemplate

The command automatically prompts for authentication credentials.

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 2)

On August 14, 2012, Microsoft will issue a critical non-security update (KB 2661254) for Windows XP, Windows Server 2003, Windows Server 2003 R2, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. The update will block the use of cryptographic keys that are less than 1024 bits. This update was first announced in the blog titled RSA keys under 1024 bits are blocked. This blog post is a reminder that the update is coming and provides a bit more information on how to control the update when deployed.

Note: The modification (opt-out settings) discussed in this article will apply throughout the operating system. You cannot configure these modifications to be applicable to a specific application, custom certificate, or scenario. You can configure these modifications before the update is applied and when the update is applied, they will take effect. The update will require a restart.

You can modify a registry setting using the certutil command to modify the size of the keys that are blocked. For example, if you wanted to allow 512 bit keys, but block all keys less than 512 bits, you could run the following command:

Certutil -setreg chainminRSAPubKeyBitLength 512

Note: All certutil commands shown in this article require local Administrator privileges because they are modifiying the registry. You can disregard the message that reads “The CertSvc service may need to be restarted for changes to take effect.” That is not required for these commands as they do not affect the certificate service (CertSvc).

If only the root certificate in a chain is 512 bits, but all the rest of the keys below are 1024 bits or higher, you could run the following command to indicate that you will allow a 512 bit root certificate, but want to block all keys less than 1024 bits below the root certificate.

Certutil -setreg chainEnableWeakSignatureFlags 2

Note: The above command also works with self-signed certificates with RSA keys less than 1024.

The certutil commands shown in this posting will not work on Windows XP, Windows Server 2003, or Windows Server 2003 R2. You will have to modify the registry directly using regedit.exe or reg command. Registry path: HKEY_LOCAL_MACHINESOFTWAREMicrosoftCryptographyOIDEncodingType 0CertDllCreateCertificateChainEngineConfig. The following table and figure illustrate registry the settings shown in the previous two examples:

Name Type Decimal data
EnableWeakSignatureFlags REG_DWORD 2
minRSAPubKeyBitLength REG_DWORD 512

If you have Authenticode signatures that were signed with keys less than 1024 bits prior to January 1, 2010, 12:00:00 AM UTC/GMT, they will not be blocked by default. If necessary, you can use the WeakRsaPubKeyTime setting to allow for the configuration of the date and time for which to consider older signatures valid. If you have reason to set a different date and time for the WeakRsaPubKeyTime, you can use certutil to set a different date and time. For example, if you wanted to set the date to August 29, 2010, you could use the following command:

certutil -setreg chainWeakRsaPubKeyTime @08/29/2010

If you have a need to set a specific time, such as 6:00 PM UTC/GMT on July 4, 2011, then add the number of days and hours in the format +[dd:hh] to the command. Since 6:00 PM is 18 hours after midnight on July 4, 2011, you would run the following command:

certutil -setreg chainWeakRsaPubKeyTime @07/04/2011+00:18

To enter WeakRsaPubKeyTime and date on Windows XP, Windows Server 2003, or Windows Server 2003 R2, use a REG_BINARY value for WeakRsaPubKeyTime. You can figure out the hex value using certutil on Windows Vista, Windows Server 2008, or more recent Windows operating system and then view the value in the registry or export the value to a REG file for viewing. The following table shows REG_BINARY hex value equivalents for WeakRsaPubKeyTime

Date/Time Hex value
August 29, 2010 at midnight UTCGMT 00 d8 f0 cb 47 47 cb 01
July 4, 2011 at 6 PM UTCGMT 00 e8 64 dd ae 3a cc 01

Additional resources

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

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

Additional blog posts:

RSA keys under 1024 bits are blocked

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

Blocking RSA Keys less than 1024 bits (part 2)

July 13th, 2012 No comments

On August 14, 2012, Microsoft will issue a critical non-security update (KB 2661254) for Windows XP, Windows Server 2003, Windows Server 2003 R2, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. The update will block the use of cryptographic keys that are less than 1024 bits. This update was first announced in the blog titled RSA keys under 1024 bits are blocked. This blog post is a reminder that the update is coming and provides a bit more information on how to control the update when deployed.

Note: The modification (opt-out settings) discussed in this article will apply throughout the operating system. You cannot configure these modifications to be applicable to a specific application, custom certificate, or scenario. You can configure these modifications before the update is applied and when the update is applied, they will take effect. The update will require a restart.

You can modify a registry setting using the certutil command to modify the size of the keys that are blocked. For example, if you wanted to allow 512 bit keys, but block all keys less than 512 bits, you could run the following command:

Certutil -setreg chain\minRSAPubKeyBitLength 512

Note: All certutil commands shown in this article require local Administrator privileges because they are modifiying the registry. You can disregard the message that reads “The CertSvc service may need to be restarted for changes to take effect.” That is not required for these commands as they do not affect the certificate service (CertSvc).

If only the root certificate in a chain is 512 bits, but all the rest of the keys below are 1024 bits or higher, you could run the following command to indicate that you will allow a 512 bit root certificate, but want to block all keys less than 1024 bits below the root certificate.

Certutil -setreg chain\EnableWeakSignatureFlags 2

Note: The above command also works with self-signed certificates with RSA keys less than 1024.

The certutil commands shown in this posting will not work on Windows XP, Windows Server 2003, or Windows Server 2003 R2. You will have to modify the registry directly using regedit.exe or reg command. Registry path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config. The following table and figure illustrate registry the settings shown in the previous two examples:

Name Type Decimal data
EnableWeakSignatureFlags REG_DWORD 2
minRSAPubKeyBitLength REG_DWORD 512

If you have Authenticode signatures that were signed with keys less than 1024 bits prior to January 1, 2010, 12:00:00 AM UTC/GMT, they will not be blocked by default. If necessary, you can use the WeakRsaPubKeyTime setting to allow for the configuration of the date and time for which to consider older signatures valid. If you have reason to set a different date and time for the WeakRsaPubKeyTime, you can use certutil to set a different date and time. For example, if you wanted to set the date to August 29, 2010, you could use the following command:

certutil -setreg chain\WeakRsaPubKeyTime @08/29/2010

If you have a need to set a specific time, such as 6:00 PM UTC/GMT on July 4, 2011, then add the number of days and hours in the format +[dd:hh] to the command. Since 6:00 PM is 18 hours after midnight on July 4, 2011, you would run the following command:

certutil -setreg chain\WeakRsaPubKeyTime @07/04/2011+00:18

To enter WeakRsaPubKeyTime and date on Windows XP, Windows Server 2003, or Windows Server 2003 R2, use a REG_BINARY value for WeakRsaPubKeyTime. You can figure out the hex value using certutil on Windows Vista, Windows Server 2008, or more recent Windows operating system and then view the value in the registry or export the value to a REG file for viewing. The following table shows REG_BINARY hex value equivalents for WeakRsaPubKeyTime

Date/Time Hex value
August 29, 2010 at midnight UTC\GMT 00 d8 f0 cb 47 47 cb 01
July 4, 2011 at 6 PM UTC\GMT 00 e8 64 dd ae 3a cc 01

Additional resources

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

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

Additional blog posts:

RSA keys under 1024 bits are blocked

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

Blocking RSA Keys less than 1024 bits (part 2)

On August 14, 2012, Microsoft will issue a critical non-security update (KB 2661254) for Windows XP, Windows Server 2003, Windows Server 2003 R2, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. The update will block the use of cryptographic keys that are less than 1024 bits. This update was first announced in the blog titled RSA keys under 1024 bits are blocked. This blog post is a reminder that the update is coming and provides a bit more information on how to control the update when deployed.

Note: The modification (opt-out settings) discussed in this article will apply throughout the operating system. You cannot configure these modifications to be applicable to a specific application, custom certificate, or scenario. You can configure these modifications before the update is applied and when the update is applied, they will take effect. The update will require a restart.

You can modify a registry setting using the certutil command to modify the size of the keys that are blocked. For example, if you wanted to allow 512 bit keys, but block all keys less than 512 bits, you could run the following command:

Certutil -setreg chain\minRSAPubKeyBitLength 512

Note: All certutil commands shown in this article require local Administrator privileges because they are modifiying the registry. You can disregard the message that reads “The CertSvc service may need to be restarted for changes to take effect.” That is not required for these commands as they do not affect the certificate service (CertSvc).

If only the root certificate in a chain is 512 bits, but all the rest of the keys below are 1024 bits or higher, you could run the following command to indicate that you will allow a 512 bit root certificate, but want to block all keys less than 1024 bits below the root certificate.

Certutil -setreg chain\EnableWeakSignatureFlags 2

Note: The above command also works with self-signed certificates with RSA keys less than 1024.

The certutil commands shown in this posting will not work on Windows XP, Windows Server 2003, or Windows Server 2003 R2. You will have to modify the registry directly using regedit.exe or reg command. Registry path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config. The following table and figure illustrate registry the settings shown in the previous two examples:

Name Type Decimal data
EnableWeakSignatureFlags REG_DWORD 2
minRSAPubKeyBitLength REG_DWORD 512

If you have Authenticode signatures that were signed with keys less than 1024 bits prior to January 1, 2010, 12:00:00 AM UTC/GMT, they will not be blocked by default. If necessary, you can use the WeakRsaPubKeyTime setting to allow for the configuration of the date and time for which to consider older signatures valid. If you have reason to set a different date and time for the WeakRsaPubKeyTime, you can use certutil to set a different date and time. For example, if you wanted to set the date to August 29, 2010, you could use the following command:

certutil -setreg chain\WeakRsaPubKeyTime @08/29/2010

If you have a need to set a specific time, such as 6:00 PM UTC/GMT on July 4, 2011, then add the number of days and hours in the format +[dd:hh] to the command. Since 6:00 PM is 18 hours after midnight on July 4, 2011, you would run the following command:

certutil -setreg chain\WeakRsaPubKeyTime @07/04/2011+00:18

To enter WeakRsaPubKeyTime and date on Windows XP, Windows Server 2003, or Windows Server 2003 R2, use a REG_BINARY value for WeakRsaPubKeyTime. You can figure out the hex value using certutil on Windows Vista, Windows Server 2008, or more recent Windows operating system and then view the value in the registry or export the value to a REG file for viewing. The following table shows REG_BINARY hex value equivalents for WeakRsaPubKeyTime

Date/Time Hex value
August 29, 2010 at midnight UTC\GMT 00 d8 f0 cb 47 47 cb 01
July 4, 2011 at 6 PM UTC\GMT 00 e8 64 dd ae 3a cc 01

Additional resources

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

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

Additional blog posts:

RSA keys under 1024 bits are blocked

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

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:

Announcing the automated updater of untrustworthy certificates and keys

There are a number of known untrusted certificates and compromised keys that have been issued by standard trusted root certification authorities. To help customers avoid interacting with these untrusted or compromised certificates and keys, an Automatic Updater of revoked certificates is now available for Windows Vista Service Pack 2, Windows Server 2008 Service Pack 2, Windows 7, and Windows Server 2008 R2 computers. Learn more and download the updater through Microsoft KB 2677070.

In the past, customers would have had to make changes to the Untrusted Certificate Store by initiating updates through Windows Update or by using a manual method. For example, the updates published in KB 2718704, which describes an update to move unauthorized certificates to the untrusted store, had to be initiated manually. This new feature provides dynamic updates for revocation information so that Windows clients can be updated with untrusted certificates at most within a day of the information being published (no user interaction required). This new automatic updater will enable Certificate Authorities to report information about their revoked CA certificates to Microsoft and have them publicly untrusted in a much faster manner as compared to propagating this information by using CRLs.

Announcing the automated updater of untrustworthy certificates and keys

There are a number of known untrusted certificates and compromised keys that have been issued by standard trusted root certification authorities. To help customers avoid interacting with these untrusted or compromised certificates and keys, an Automatic Updater of revoked certificates is now available for Windows Vista Service Pack 2, Windows Server 2008 Service Pack 2, Windows 7, and Windows Server 2008 R2 computers. Learn more and download the updater through Microsoft KB 2677070.

In the past, customers would have had to make changes to the Untrusted Certificate Store by initiating updates through Windows Update or by using a manual method. For example, the updates published in KB 2718704, which describes an update to move unauthorized certificates to the untrusted store, had to be initiated manually. This new feature provides dynamic updates for revocation information so that Windows clients can be updated with untrusted certificates at most within a day of the information being published (no user interaction required). This new automatic updater will enable Certificate Authorities to report information about their revoked CA certificates to Microsoft and have them publicly untrusted in a much faster manner as compared to propagating this information by using CRLs.

Announcing the automated updater of untrustworthy certificates and keys

June 12th, 2012 No comments

There are a number of known untrusted certificates and compromised keys that have been issued by standard trusted root certification authorities. To help customers avoid interacting with these untrusted or compromised certificates and keys, an Automatic Updater of revoked certificates is now available for Windows Vista Service Pack 2, Windows Server 2008 Service Pack 2, Windows 7, and Windows Server 2008 R2 computers. Learn more and download the updater through Microsoft KB 2677070.

In the past, customers would have had to make changes to the Untrusted Certificate Store by initiating updates through Windows Update or by using a manual method. For example, the updates published in KB 2718704, which describes an update to move unauthorized certificates to the untrusted store, had to be initiated manually. This new feature provides dynamic updates for revocation information so that Windows clients can be updated with untrusted certificates at most within a day of the information being published (no user interaction required). This new automatic updater will enable Certificate Authorities to report information about their revoked CA certificates to Microsoft and have them publicly untrusted in a much faster manner as compared to propagating this information by using CRLs.

Request File Can’t be Located during CA Certificate Renewal

May 29th, 2012 No comments

During my work with a customer renewing their Issuing CA’s certificate based on the steps documented in this article, I discovered that the Request file generated couldn’t be located in the default location of %systemDrive% . The Issuing CA didn’t log any errors in the Event Log, nor did it post any error messages. I also searched for all files with the extension *.req on all drives, and still couldn’t find the file.

After some more research, I discovered that my customer changed the default location of the RequestFileName Registry Key during their installation to a drive that no longer exists on the CA. The location configured was a:%1_%3%4.req. I followed these steps to fix this issue:

  1. Start the Registry Editor
  2. Navigate to HKLMSystemCurrentControlSetServicesCertsvcConfiguration<CASanitizedName>
  3. Locate the Registry String RequestFileName
  4. Change the value from a:%1_%3%4.req to C:%1_%3%4.req
  5. Stop and Start the Certification Active Directory Certificate Services service

I was then able to create the Request File and submit it to the Offline Root CA to process it.

 

Request File Can’t be Located during CA Certificate Renewal

May 29th, 2012 No comments

During my work with a customer renewing their Issuing CA’s certificate based on the steps documented in this article, I discovered that the Request file generated couldn’t be located in the default location of %systemDrive% . The Issuing CA didn’t log any errors in the Event Log, nor did it post any error messages. I also searched for all files with the extension *.req on all drives, and still couldn’t find the file.

After some more research, I discovered that my customer changed the default location of the RequestFileName Registry Key during their installation to a drive that no longer exists on the CA. The location configured was a:\%1_%3%4.req. I followed these steps to fix this issue:

  1. Start the Registry Editor
  2. Navigate to HKLM\System\CurrentControlSet\Services\Certsvc\Configuration\<CASanitizedName>
  3. Locate the Registry String RequestFileName
  4. Change the value from a:\%1_%3%4.req to C:\%1_%3%4.req
  5. Stop and Start the Certification Active Directory Certificate Services service

I was then able to create the Request File and submit it to the Offline Root CA to process it.

 

Request File Can’t be Located during CA Certificate Renewal

May 29th, 2012 No comments

During my work with a customer renewing their Issuing CA’s certificate based on the steps documented in this article, I discovered that the Request file generated couldn’t be located in the default location of %systemDrive% . The Issuing CA didn’t log any errors in the Event Log, nor did it post any error messages. I also searched for all files with the extension *.req on all drives, and still couldn’t find the file.

After some more research, I discovered that my customer changed the default location of the RequestFileName Registry Key during their installation to a drive that no longer exists on the CA. The location configured was a:\%1_%3%4.req. I followed these steps to fix this issue:

  1. Start the Registry Editor
  2. Navigate to HKLM\System\CurrentControlSet\Services\Certsvc\Configuration\<CASanitizedName>
  3. Locate the Registry String RequestFileName
  4. Change the value from a:\%1_%3%4.req to C:\%1_%3%4.req
  5. Stop and Start the Certification Active Directory Certificate Services service

I was then able to create the Request File and submit it to the Offline Root CA to process it.

 

Visual Basic for Applications and SHA2

I was recently helping a customer deploy a SHA-256 based PKI.  As part of the retirement of their old PKI, we reissued the code signing certificates used by their developers.  We found that the Visual Studio 2010 developers had no issue with the new code signing certs, but the Visual Basic of Application developers could not select the new SHA-256 certificate.  Working with the good folks in Premier Support, we discovered there was a bug in VBA.

Last week we released a hotfix for Office 2010, KB 2598139, that addressed this bug in Office 2010.  This hotfix corrected the issue with the certificate selection box (Tools | Digital Signature) and the handling of VBA macros signed with SHA2 certificates.

In order to properly use SHA2 code signing certificates, this hotfix would need to be installed on both the developer computers and the end-users computers.  As this is a QFE, the standard warning applies: …this hotfix is intended to correct only the problems that are described in this article. Apply this hotfix only to systems that are experiencing the problems described…  In order to download this hotfix, click the “View and request hotfix downloads” button on the top of the KB article.

-Adam Stasiniewicz

Visual Basic for Applications and SHA2

I was recently helping a customer deploy a SHA-256 based PKI.  As part of the retirement of their old PKI, we reissued the code signing certificates used by their developers.  We found that the Visual Studio 2010 developers had no issue with the new code signing certs, but the Visual Basic of Application developers could not select the new SHA-256 certificate.  Working with the good folks in Premier Support, we discovered there was a bug in VBA.

Last week we released a hotfix for Office 2010, KB 2598139, that addressed this bug in Office 2010.  This hotfix corrected the issue with the certificate selection box (Tools | Digital Signature) and the handling of VBA macros signed with SHA2 certificates.

In order to properly use SHA2 code signing certificates, this hotfix would need to be installed on both the developer computers and the end-users computers.  As this is a QFE, the standard warning applies: …this hotfix is intended to correct only the problems that are described in this article. Apply this hotfix only to systems that are experiencing the problems described…  In order to download this hotfix, click the “View and request hotfix downloads” button on the top of the KB article.

-Adam Stasiniewicz