Windows PKI blog

Windows PowerShell CRL Copy v2 posted to the gallery

Kurt L Hudson MSFT — Thu, 09 May 2013 01:43:25 GMT

Paul Fox has uploaded a revision of his former Windows PowerShell CRL Copy script. The new script is posted at the TechNet Gallery as Windows PowerShell Copy 2. The Windows PowerShell script monitors the remaining lifetime of a CRL, publishes a CRL to a UNC and\or NTFS location and sends notifications via SMTP and the Event Log.

PKI Library (PKI Documentation and Reference Library Updated)

Kurt L Hudson MSFT — Fri, 22 Mar 2013 08:32:00 GMT

Tonight I spent a couple of hours reorganizing the PKI Documentation and Reference Library. I also created a vanity short URL to it http://aka.ms/pkilibrary. Finding all our different information on AD CS and PKI can be challenging, so this reorganization will hopefully help you.

If you see articles missing, broken links, or have suggestions - you can contact me about it. Better yet, login and fix the issue yourself. :-)

Thank you!

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

Amerk [MSFT] — Fri, 22 Mar 2013 05:14:00 GMT

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

Certutil and Certreq

Kurt L Hudson MSFT — Sat, 09 Mar 2013 01:03:00 GMT

I have consolidated and updated two command line utilities recently:

Certreq

Certutil

I took all the older links that I could find and pointed them to the locations above and then pointed out to the examples that we have already. Feel free to give me feedback on these consolidated documents. Thanks!

Query for Advanced CA Configuration Options

Amerk [MSFT] — Thu, 27 Dec 2012 16:23:46 GMT

It is very common to check the configuration of any certification authority using certutil –getreg command. The command will allow a CA administrator to view the configured settings at a glance.

But what if you need to configure advanced settings on your CA? How can you find a setting required for your compliance audit?

Well, this is simple! You can still use the common certutil –getreg command but now, add the verbose switch (-v). The command’s output will be similar to the screenshot below

As you probably noticed, all supported symbol names are displayed. The ones indented and in parentheses are supported bits that could be set, but currently are not. Any symbol without parentheses is configured on your CA. The symbolic names may be of some help to identify each bit’s purpose. You can perform a quick research on TechNet or MSDN to further understand and deploy each bit.

Amer F. Kamal

Senior Premier Field Engineer

Viewing Expired Certificate Revocation List (CRL)

Amerk [MSFT] — Thu, 20 Dec 2012 15:00:00 GMT

Many customers must perform a regulatory audit annually to comply with industry standards and business trends. Recently I was contacted by one of my customers, who was not able to view all of Certificate Revocation Lists (CRLs) issued by their Enterprise Certification Authority. The customer mentioned they were able to view these CRLs on a Windows Server 2003 Certification Authorities but cannot view them on Windows Server 2008 R2 Enterprise Certification Authorities.

Windows Server 2008 and Windows Server 2012 Certification Authorities by default delete expired CRLs when a new one is issued. This option can be reversed to preserve expired CRLs, but has to be implemented before your audit. To preserve expired CRLs run the following commands:

certutil –setreg CA\CRLFlags -CRLF_DELETE_EXPIRED_CRLS

net stop certsvc

net start certsvc

Furthermore, you can view CRLs by running this command:

certutil -view -out "CRLThisPublish,CRLNumber,CRLCount" CRL

The Certification Authority Console by default will not display Certificate Revocation List (CRL)history as noted in the screenshot below.

You can change this behavior by running certsvc.msc /e from

Amer F Kamal

Senior Premier Field Engineer

Certificate for WinRT devices and non-domain member devices

Chunhua Chen — Tue, 11 Dec 2012 07:46:00 GMT

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

Kurt L Hudson MSFT — Mon, 08 Oct 2012 12:41:00 GMT

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.

Blocking RSA keys less than 1024 bits (part 3)

Kurt L Hudson MSFT — Tue, 14 Aug 2012 21:00:04 GMT

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

The security advisory is located at http://technet.microsoft.com/security/advisory/2661254.
The KB article is available at http://support.microsoft.com/kb/2661254.

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

Blocking RSA Keys less than 1024 bits (part 2)

Kurt L Hudson MSFT — Fri, 13 Jul 2012 21:14:00 GMT

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