Archive

Archive for the ‘AD CS’ Category

Windows Server 2012 Active Directory Certificate Services System State Backup and Restore

March 22nd, 2013 No comments

Windows Server 2012 System State Backup allows an administrator to back-up several Operating System components including those required for a successful restore of a Certification Authority. Any certification authority backup should include the private key, certificate database, logs and the certification authority’s registry configuration.

Windows Server Backup Feature should be installed on the certification authority to take a System State Backup. It has been enhanced in Windows Server 2012 to allow the administrator to take a System State Backup using the feature’s Graphical User Interface (GUI), and the command line. Furthermore, System State Backup in Windows Server 2012 allows the administrator to back-up the certification authority’s Private Key without the need to install any hotfixes.

Note: Windows Server 2008 and 2008 R2 required installing a hotfix to back-up the private key using System State Backup

Steps Required to Back-up the Certification Authority Using System State Backup

 There are two easy steps to prepare the certification authority for a System State Backup.

1.      Install Windows Server Backup Feature

2.      Schedule a System State Backup

Install Windows Server Backup Feature

 Windows Server Backup is not enabled by default on Windows Server 2012. The feature needs to be installed before taking or scheduling a System State Backup.

1.      Log on to the certification authority and select Manage in Server Manager

2.      Click Add Roles and Features

3.      Click Next in Before you begin screen

4.      Select Role-based or feature-based installation and then click Next

5.      Select the local server in Select destination server screen

6.      Click Next  in Select server roles screen

7.      Select Windows Server Backup in Select features  screen and then click Next

8.      Select Install in Confirm installation selections screen

9.      Click Close

Note: The Winddows Server Backup feature can be installed using Install-WidnowsFeature –name Windows-Server-Backup cmdlet

Schedule a System State Backup

 Windows Server Backup allows administrators to back-up the system to a non-critical volume only, setting a registry key as described in KB944530 provides a workaround to this limitation, but it is not recommended to run in production because it might cause a critical volume to fill up quickly. In general, make sure you have a volume, or disk or network share designated to a certification authority’s backup other than your c: drive.

Using the Graphical User Interface (GUI)

1.   Log on the certification authority and select Tools in Server Manager

2.   Click Windows Server Backup

3.   Select Local Backup

4.    Click Backup Sched

5.    Click Next in Getting Started screen

6.    Click Custom – I want to choose custom volumes, file for backup and then click Next

7.    Click Add Items in Select Items for Backup screen

8.    Select System State and then click OK

9.    Click Next in Select Items for Backup screen

10.  Choose the backup run time frequency in Specify Backup Time and then click Next

11.  Select the backup destination in Specify Destination and then click Next

Note: The rest of this document assumes having a dedicated volume to back-up the certification authority to. The wording might be slightly different is you chose a network share for your backup location.

12.  Click Add in Select Destination, select the dedicated volume and then select OK

13.  Click Next

14.  Review the scheduled backup settings in the Confirmation screen and then click Finish

Using the Command Line

Windows Server Backup can be configured using the command line. The command line tool Wbadmin has many verbs that can identify backups, volumes, disks, create jobs and many more. The disk identifier has to be known before scheduling any backup job.

The disk identifier is retrieved by running Wbadmin get disks

 

Note the Volumes label in the screen shot. The scheduled backup should target non-System Reserved volumes. The volume that has the Disk Identifier {eb9c44d8-0000-0000-0000-000000000000} is the clear choice for the backup files.

The next step is creating a scheduled task to take a System State Backup to the volume specified. This is also achieved using the Wbadmin command line tool with the enable backup verb. For example, run the following command to set up a backup job to run daily at 10:00 PM and include System State Backup

Wbadmin enable backup –addtargret: {eb9c44d8-0000-0000-0000-000000000000} –schedule:22:00 –SystemState

 

Note: If you prefer to take a one time System State Backup, then run Wbadmin Start SystemStateBackup –backuptarget:<non-critical volume DriveLetter> 

Using PowerShell

 Setting a schedule System State Backup might seem intimidating at first. The tasks involve creating a backup policy, a backup directory, a schedule, and then trying all of that to the policy. Let us go through them one at a time

 The first command stores the result of the New-WBPolicy cmdlet in the variable named $Policy

  PS C:\> $Policy = New-WBPolicySetting the volume as the System State Backup Path

This command creates a WBBackupTarget object that uses a volume with drive letter E: as the backup storage location. You can add multiple volumes for storage to the WBPolicy object that contains the backup policy.

 PS C:\> $volumeBackupLocation = New-WBBackupTarget -VolumePath E:
 
This command adds the system state to the backup policy in the $Policy variable.
 
 PS c:\> Add-WBSystemState -Policy $Policy 
 This command adds the backup location – volume E - to the backup policy in the $Policy variable
 
 PS C:\> Add-WBBackupTarget -Policy $Policy -Target $volumeBackupLocation
 

This command sets the backup schedule configured in the $Policy variable to run daily at 10 PM

 
 PS C:\> Set-WBSchedule -Policy $Policy –Schedule 22:00:00
 

This is the last command, where it sets the backup schedule based on the$Policyvariable

 

 PS C:\> Set-wbpolicy –policy $Policy

  

Steps Required to Restore the Certification Authority from System State Backup

 The steps listed in this section detail three different approaches to restore the certification authority using Windows Server Backup Graphical User Interface (GUI), Windows Server Backup Command Line, and Windows Server Backup PowerShell.

General Steps Required to Restore the Certification Authority

The general steps to restore the certification authority are the preliminary steps required before attempting any other restore activity. These steps are:

1. Install Windows Server 2012 Standard or Datacenter Edition depending on the certification authority’s previously installed operating system version.

2. Join the server to the same domain or workgroup

3. Access to System State backup media

4. Install Windows Server Backup Feature

Restore the Certification Authority Using Windows Server Backup GUI

1. Select Tools in Server Manager

2. Select Windows Server Backup

3. Select Local Backup

4. In Actions menu, select Recover

5. In Getting Started window Select This Server (local Servername) and then select Next

 

 

5. In Select Backup Date window, choose the backup to restore from and then click Next

 

6. In Select Recovery Type window, select System State and then then click Next

 

 

7. In Select Location for System State Recovery window, select Original Location and then click Next

 

8. Review your selections in the Confirmation window, make sure Automatically reboot the server to complete the recovery process is selected and then click Recover

 

9. Click Yes in the screen warning you about the ability to cancel, or pause System State backup once the recovery operation is started

 

10. At this point, System State recovery will restore the certification authority, and automatically reboot the server

 

11. Press Enter to continue after you log on the server after it reboots to confirm System State recovery

 

 

Restore the Certification Authority Using Windows Server Backup Command Line

1. Start the Command Prompt (Admin)

2. List the backup history by running wbadmin get versions and note the version identifier of the latest backup. The backup’s Can recover value should clearly indicate System State is included in the backup.

 

3. Start System State recovery by typing wbadmin start Systemstaterecvoery –version:<version identifier value> -backuptarget:<Backuplocation>

For example, the version identifier from my latest backup is 03/14/2013-04:03 and stored on C: , hence the command is wbadmin start systemstaterecovery –version:03/14/2013-04:03 –backuptarget:c:

 

4. Type Y and the then hit Enter to start System State recovery

 

5. Type Y and then hit Enter to confirm. System State recovery will start restoring files

 

 6. Type Y and then hit Enter to restart the system to complete the System State restore

 

Restore the Certification Authority Using Windows Server Backup PowerShell Cmdlets

1. Start PowerShell as an Administrator

2. Set the $Backup variable using Get-WBBackupset cmdlet

             PS C:\ $Backup = Get-Wbbackupset

3.  Start the system state recovery from the backup set in $Backup.

             PS C:\ Start-WbSystemStateRecovery –backupset $Backup

 4. Type Y when prompted to restore System State to the original location

  

 5. Type Y to confirm the required system restart

Amer F. Kamal

Sr. Premier Field Engineer

 

 

Windows Server 2012 Active Directory Certificate Services System State Backup and Restore

March 22nd, 2013 No comments

Windows Server 2012 System State Backup allows an administrator to back-up several Operating System components including those required for a successful restore of a Certification Authority. Any certification authority backup should include the private key, certificate database, logs and the certification authority’s registry configuration.

Windows Server Backup Feature should be installed on the certification authority to take a System State Backup. It has been enhanced in Windows Server 2012 to allow the administrator to take a System State Backup using the feature’s Graphical User Interface (GUI), and the command line. Furthermore, System State Backup in Windows Server 2012 allows the administrator to back-up the certification authority’s Private Key without the need to install any hotfixes.

Note: Windows Server 2008 and 2008 R2 required installing a hotfix to back-up the private key using System State Backup

Steps Required to Back-up the Certification Authority Using System State Backup

 There are two easy steps to prepare the certification authority for a System State Backup.

1.      Install Windows Server Backup Feature

2.      Schedule a System State Backup

Install Windows Server Backup Feature

 Windows Server Backup is not enabled by default on Windows Server 2012. The feature needs to be installed before taking or scheduling a System State Backup.

1.      Log on to the certification authority and select Manage in Server Manager

2.      Click Add Roles and Features

3.      Click Next in Before you begin screen

4.      Select Role-based or feature-based installation and then click Next

5.      Select the local server in Select destination server screen

6.      Click Next  in Select server roles screen

7.      Select Windows Server Backup in Select features  screen and then click Next

8.      Select Install in Confirm installation selections screen

9.      Click Close

Note: The Winddows Server Backup feature can be installed using Install-WidnowsFeature –name Windows-Server-Backup cmdlet

Schedule a System State Backup

 Windows Server Backup allows administrators to back-up the system to a non-critical volume only, setting a registry key as described in KB944530 provides a workaround to this limitation, but it is not recommended to run in production because it might cause a critical volume to fill up quickly. In general, make sure you have a volume, or disk or network share designated to a certification authority’s backup other than your c: drive.

Using the Graphical User Interface (GUI)

1.   Log on the certification authority and select Tools in Server Manager

2.   Click Windows Server Backup

3.   Select Local Backup

4.    Click Backup Sched

5.    Click Next in Getting Started screen

6.    Click Custom – I want to choose custom volumes, file for backup and then click Next

7.    Click Add Items in Select Items for Backup screen

8.    Select System State and then click OK

9.    Click Next in Select Items for Backup screen

10.  Choose the backup run time frequency in Specify Backup Time and then click Next

11.  Select the backup destination in Specify Destination and then click Next

Note: The rest of this document assumes having a dedicated volume to back-up the certification authority to. The wording might be slightly different is you chose a network share for your backup location.

12.  Click Add in Select Destination, select the dedicated volume and then select OK

13.  Click Next

14.  Review the scheduled backup settings in the Confirmation screen and then click Finish

Using the Command Line

Windows Server Backup can be configured using the command line. The command line tool Wbadmin has many verbs that can identify backups, volumes, disks, create jobs and many more. The disk identifier has to be known before scheduling any backup job.

The disk identifier is retrieved by running Wbadmin get disks

 

Note the Volumes label in the screen shot. The scheduled backup should target non-System Reserved volumes. The volume that has the Disk Identifier {eb9c44d8-0000-0000-0000-000000000000} is the clear choice for the backup files.

The next step is creating a scheduled task to take a System State Backup to the volume specified. This is also achieved using the Wbadmin command line tool with the enable backup verb. For example, run the following command to set up a backup job to run daily at 10:00 PM and include System State Backup

Wbadmin enable backup –addtargret: {eb9c44d8-0000-0000-0000-000000000000} –schedule:22:00 –SystemState

 

Note: If you prefer to take a one time System State Backup, then run Wbadmin Start SystemStateBackup –backuptarget:<non-critical volume DriveLetter> 

Using PowerShell

 Setting a schedule System State Backup might seem intimidating at first. The tasks involve creating a backup policy, a backup directory, a schedule, and then trying all of that to the policy. Let us go through them one at a time

 The first command stores the result of the New-WBPolicy cmdlet in the variable named $Policy

  PS C:\> $Policy = New-WBPolicySetting the volume as the System State Backup Path

This command creates a WBBackupTarget object that uses a volume with drive letter E: as the backup storage location. You can add multiple volumes for storage to the WBPolicy object that contains the backup policy.

 PS C:\> $volumeBackupLocation = New-WBBackupTarget -VolumePath E:
 
This command adds the system state to the backup policy in the $Policy variable.
 
 PS c:\> Add-WBSystemState -Policy $Policy 
 This command adds the backup location – volume E - to the backup policy in the $Policy variable
 
 PS C:\> Add-WBBackupTarget -Policy $Policy -Target $volumeBackupLocation
 

This command sets the backup schedule configured in the $Policy variable to run daily at 10 PM

 
 PS C:\> Set-WBSchedule -Policy $Policy –Schedule 22:00:00
 

This is the last command, where it sets the backup schedule based on the$Policyvariable

 

 PS C:\> Set-wbpolicy –policy $Policy

  

Steps Required to Restore the Certification Authority from System State Backup

 The steps listed in this section detail three different approaches to restore the certification authority using Windows Server Backup Graphical User Interface (GUI), Windows Server Backup Command Line, and Windows Server Backup PowerShell.

General Steps Required to Restore the Certification Authority

The general steps to restore the certification authority are the preliminary steps required before attempting any other restore activity. These steps are:

1. Install Windows Server 2012 Standard or Datacenter Edition depending on the certification authority’s previously installed operating system version.

2. Join the server to the same domain or workgroup

3. Access to System State backup media

4. Install Windows Server Backup Feature

Restore the Certification Authority Using Windows Server Backup GUI

1. Select Tools in Server Manager

2. Select Windows Server Backup

3. Select Local Backup

4. In Actions menu, select Recover

5. In Getting Started window Select This Server (local Servername) and then select Next

 

 

5. In Select Backup Date window, choose the backup to restore from and then click Next

 

6. In Select Recovery Type window, select System State and then then click Next

 

 

7. In Select Location for System State Recovery window, select Original Location and then click Next

 

8. Review your selections in the Confirmation window, make sure Automatically reboot the server to complete the recovery process is selected and then click Recover

 

9. Click Yes in the screen warning you about the ability to cancel, or pause System State backup once the recovery operation is started

 

10. At this point, System State recovery will restore the certification authority, and automatically reboot the server

 

11. Press Enter to continue after you log on the server after it reboots to confirm System State recovery

 

 

Restore the Certification Authority Using Windows Server Backup Command Line

1. Start the Command Prompt (Admin)

2. List the backup history by running wbadmin get versions and note the version identifier of the latest backup. The backup’s Can recover value should clearly indicate System State is included in the backup.

 

3. Start System State recovery by typing wbadmin start Systemstaterecvoery –version:<version identifier value> -backuptarget:<Backuplocation>

For example, the version identifier from my latest backup is 03/14/2013-04:03 and stored on C: , hence the command is wbadmin start systemstaterecovery –version:03/14/2013-04:03 –backuptarget:c:

 

4. Type Y and the then hit Enter to start System State recovery

 

5. Type Y and then hit Enter to confirm. System State recovery will start restoring files

 

 6. Type Y and then hit Enter to restart the system to complete the System State restore

 

Restore the Certification Authority Using Windows Server Backup PowerShell Cmdlets

1. Start PowerShell as an Administrator

2. Set the $Backup variable using Get-WBBackupset cmdlet

             PS C:\ $Backup = Get-Wbbackupset

3.  Start the system state recovery from the backup set in $Backup.

             PS C:\ Start-WbSystemStateRecovery –backupset $Backup

 4. Type Y when prompted to restore System State to the original location

  

 5. Type Y to confirm the required system restart

Amer F. Kamal

Sr. Premier Field Engineer

 

 

Windows Server 2012 Active Directory Certificate Services System State Backup and Restore

March 22nd, 2013 No comments

Windows Server 2012 System State Backup allows an administrator to back-up several Operating System components including those required for a successful restore of a Certification Authority. Any certification authority backup should include the private key, certificate database, logs and the certification authority’s registry configuration.

Windows Server Backup Feature should be installed on the certification authority to take a System State Backup. It has been enhanced in Windows Server 2012 to allow the administrator to take a System State Backup using the feature’s Graphical User Interface (GUI), and the command line. Furthermore, System State Backup in Windows Server 2012 allows the administrator to back-up the certification authority’s Private Key without the need to install any hotfixes.

Note: Windows Server 2008 and 2008 R2 required installing a hotfix to back-up the private key using System State Backup

Steps Required to Back-up the Certification Authority Using System State Backup

 There are two easy steps to prepare the certification authority for a System State Backup.

1.      Install Windows Server Backup Feature

2.      Schedule a System State Backup

Install Windows Server Backup Feature

 Windows Server Backup is not enabled by default on Windows Server 2012. The feature needs to be installed before taking or scheduling a System State Backup.

1.      Log on to the certification authority and select Manage in Server Manager

2.      Click Add Roles and Features

3.      Click Next in Before you begin screen

4.      Select Role-based or feature-based installation and then click Next

5.      Select the local server in Select destination server screen

6.      Click Next  in Select server roles screen

7.      Select Windows Server Backup in Select features  screen and then click Next

8.      Select Install in Confirm installation selections screen

9.      Click Close

Note: The Winddows Server Backup feature can be installed using Install-WidnowsFeature –name Windows-Server-Backup cmdlet

Schedule a System State Backup

 Windows Server Backup allows administrators to back-up the system to a non-critical volume only, setting a registry key as described in KB944530 provides a workaround to this limitation, but it is not recommended to run in production because it might cause a critical volume to fill up quickly. In general, make sure you have a volume, or disk or network share designated to a certification authority’s backup other than your c: drive.

Using the Graphical User Interface (GUI)

1.   Log on the certification authority and select Tools in Server Manager

2.   Click Windows Server Backup

3.   Select Local Backup

4.    Click Backup Sched

5.    Click Next in Getting Started screen

6.    Click Custom – I want to choose custom volumes, file for backup and then click Next

7.    Click Add Items in Select Items for Backup screen

8.    Select System State and then click OK

9.    Click Next in Select Items for Backup screen

10.  Choose the backup run time frequency in Specify Backup Time and then click Next

11.  Select the backup destination in Specify Destination and then click Next

Note: The rest of this document assumes having a dedicated volume to back-up the certification authority to. The wording might be slightly different is you chose a network share for your backup location.

12.  Click Add in Select Destination, select the dedicated volume and then select OK

13.  Click Next

14.  Review the scheduled backup settings in the Confirmation screen and then click Finish

Using the Command Line

Windows Server Backup can be configured using the command line. The command line tool Wbadmin has many verbs that can identify backups, volumes, disks, create jobs and many more. The disk identifier has to be known before scheduling any backup job.

The disk identifier is retrieved by running Wbadmin get disks

 

Note the Volumes label in the screen shot. The scheduled backup should target non-System Reserved volumes. The volume that has the Disk Identifier {eb9c44d8-0000-0000-0000-000000000000} is the clear choice for the backup files.

The next step is creating a scheduled task to take a System State Backup to the volume specified. This is also achieved using the Wbadmin command line tool with the enable backup verb. For example, run the following command to set up a backup job to run daily at 10:00 PM and include System State Backup

Wbadmin enable backup –addtargret: {eb9c44d8-0000-0000-0000-000000000000} –schedule:22:00 –SystemState

 

Note: If you prefer to take a one time System State Backup, then run Wbadmin Start SystemStateBackup –backuptarget:<non-critical volume DriveLetter> 

Using PowerShell

 Setting a schedule System State Backup might seem intimidating at first. The tasks involve creating a backup policy, a backup directory, a schedule, and then trying all of that to the policy. Let us go through them one at a time

 The first command stores the result of the New-WBPolicy cmdlet in the variable named $Policy

  PS C:> $Policy = New-WBPolicySetting the volume as the System State Backup Path

This command creates a WBBackupTarget object that uses a volume with drive letter E: as the backup storage location. You can add multiple volumes for storage to the WBPolicy object that contains the backup policy.

 PS C:> $volumeBackupLocation = New-WBBackupTarget -VolumePath E:
 
This command adds the system state to the backup policy in the $Policy variable.
 
 PS c:> Add-WBSystemState -Policy $Policy 
 This command adds the backup location – volume E - to the backup policy in the $Policy variable
 
 PS C:> Add-WBBackupTarget -Policy $Policy -Target $volumeBackupLocation
 

This command sets the backup schedule configured in the $Policy variable to run daily at 10 PM

 
 PS C:> Set-WBSchedule -Policy $Policy –Schedule 22:00:00
 

This is the last command, where it sets the backup schedule based on the$Policyvariable

 

 PS C:> Set-wbpolicy –policy $Policy

  

Steps Required to Restore the Certification Authority from System State Backup

 The steps listed in this section detail three different approaches to restore the certification authority using Windows Server Backup Graphical User Interface (GUI), Windows Server Backup Command Line, and Windows Server Backup PowerShell.

General Steps Required to Restore the Certification Authority

The general steps to restore the certification authority are the preliminary steps required before attempting any other restore activity. These steps are:

1. Install Windows Server 2012 Standard or Datacenter Edition depending on the certification authority’s previously installed operating system version.

2. Join the server to the same domain or workgroup

3. Access to System State backup media

4. Install Windows Server Backup Feature

Restore the Certification Authority Using Windows Server Backup GUI

1. Select Tools in Server Manager

2. Select Windows Server Backup

3. Select Local Backup

4. In Actions menu, select Recover

5. In Getting Started window Select This Server (local Servername) and then select Next

 

 

5. In Select Backup Date window, choose the backup to restore from and then click Next

 

6. In Select Recovery Type window, select System State and then then click Next

 

 

7. In Select Location for System State Recovery window, select Original Location and then click Next

 

8. Review your selections in the Confirmation window, make sure Automatically reboot the server to complete the recovery process is selected and then click Recover

 

9. Click Yes in the screen warning you about the ability to cancel, or pause System State backup once the recovery operation is started

 

10. At this point, System State recovery will restore the certification authority, and automatically reboot the server

 

11. Press Enter to continue after you log on the server after it reboots to confirm System State recovery

 

 

Restore the Certification Authority Using Windows Server Backup Command Line

1. Start the Command Prompt (Admin)

2. List the backup history by running wbadmin get versions and note the version identifier of the latest backup. The backup’s Can recover value should clearly indicate System State is included in the backup.

 

3. Start System State recovery by typing wbadmin start Systemstaterecvoery –version:<version identifier value> -backuptarget:<Backuplocation>

For example, the version identifier from my latest backup is 03/14/2013-04:03 and stored on C: , hence the command is wbadmin start systemstaterecovery –version:03/14/2013-04:03 –backuptarget:c:

 

4. Type Y and the then hit Enter to start System State recovery

 

5. Type Y and then hit Enter to confirm. System State recovery will start restoring files

 

 6. Type Y and then hit Enter to restart the system to complete the System State restore

 

Restore the Certification Authority Using Windows Server Backup PowerShell Cmdlets

1. Start PowerShell as an Administrator

2. Set the $Backup variable using Get-WBBackupset cmdlet

             PS C: $Backup = Get-Wbbackupset

3.  Start the system state recovery from the backup set in $Backup.

             PS C: Start-WbSystemStateRecovery –backupset $Backup

 4. Type Y when prompted to restore System State to the original location

  

 5. Type Y to confirm the required system restart

Amer F. Kamal

Sr. Premier Field Engineer

 

 

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

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:

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

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: