Retired Microsoft Blog disclaimer

This directory is a mirror of retired "Windows PKI Team" TechNet blog and is provided as is. All posting authorship and copyrights belong to respective authors.

Posts on this page:

Original URL: https://blogs.technet.microsoft.com/pki/2012/12/27/query-for-advanced-ca-configuration-options/
Post name: Query for Advanced CA Configuration Options
Original author: Amerk [MSFT]
Posting date: 2012-12-27T08:23:46+00:00


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 verboseswitch (-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

Original URL: https://blogs.technet.microsoft.com/pki/2012/12/20/viewing-expired-certificate-revocation-list-crl/
Post name: Viewing Expired Certificate Revocation List (CRL)
Original author: Amerk [MSFT]
Posting date: 2012-12-20T07:00:00+00:00


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

Original URL: https://blogs.technet.microsoft.com/pki/2012/12/10/certificate-for-winrt-devices-and-non-domain-member-devices/
Post name: Certificate for WinRT devices and non-domain member devices
Original author: Chunhua Chen
Posting date: 2012-12-10T23:46:00+00:00


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 (ADDS) 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 ADDS 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). TheWindows 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 theAskDS blogtitled 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 DirectoryDomain Service (ADDS) 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 StoreApp's certificate stores, you can use the CertificateEnrollmentManagerclass. 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 Podans:

The following example PowerShellscript linesin 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.

Original URL: https://blogs.technet.microsoft.com/pki/2012/10/08/group-protected-pfx/
Post name: Group Protected PFX
Original author: Kurt L Hudson MSFT
Posting date: 2012-10-08T05:41:00+00:00


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.

Original URL: https://blogs.technet.microsoft.com/pki/2012/08/14/blocking-rsa-keys-less-than-1024-bits-part-3/
Post name: Blocking RSA keys less than 1024 bits (part 3)
Original author: Kurt L Hudson MSFT
Posting date: 2012-08-14T14:00:04+00:00


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

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