Hi there, this is Larry, Developer from US, and Fabian, PFE from Germany, writing about an uncommon scenario that might raise questions sometimes.

When enrolling certificates to clients or users, you might want to have control regarding the initial enrollment of the certificate in order to decide, if the specific device or user really should have a certificate based on a specific template. Therefore you want to implement the following procedure:

1. The initial enrollment (regardless if performed by manual respectively scripted enrollment or autoenrollment) should be issued only with CA certificate manager approval.
2. When this certificate reaches the end of validity period and if there is a valid certificate / private key combination, the certificate renewal should be performed automatically without CA certificate manager approval.

As you can see in the first line “Require the following for enrollment:”, the option “CA certificate manager approval” enables controlled issuance for certificates. The tick box “Require the following for reenrollment” with option “Valid existing certificate” allows reenrollment to occur without requiring CA manager approval.

Generally speaking this is possible, but there are caveats:

Online Templates

If using templates that are configured to obtain the subject information from the Active Directory account object, you may run into the problem that the reenrollment does not occur without manager approval. The renewal request may still be taken under submission and require you to issue them manually as a CA certificate manager:

This may occur if the SAN does not contain either a User principal name (UPN) or E-mail name:

When the CA is processing a renewal request, there is a name match performed against the subject information within the certificate. The naming information in the signing cert (the one being renewed) needs to match that being requested. In performing the name match, however, the CA is only looking for specific items. This name match requires that the original certificate conains either a UPN or E-mail name (or both) within the SAN extension, that matches that defined on the AD account object. In order for this name match to be successfulI, ifthis information is not present within the original certificate the renewal request goes pending:

The workaround for this is simple: Configure your V2 or V3 template to include the UPN or E-mail name within the SAN and renewals will succeed as expected:

In the event that the SAN information within the certificate being renewed, is different than that defined on the AD account object, such as in the case of an account re-name, the renewal request may also go pending. If the signing cert contains only the UPN or E-mail name, then that name must match what is defined on the AD account object. However, if both the UPN and E-mail name are present, only one need match in order for the renewal to be successful without requiring CA manager approval.

The described behavior holds true for both user and computer templates.

Offline Templates

The behavior for offline templates, where the subject information is provided within the certificate request, the behavior is different. When a renewal request for an offline template is evaluated, a similar naming match is performed, however, today only the Subject is evaluated and SAN information is ignored.

Cheers!

PKIVIEW was first introduced in Windows Server 2003 Resource kit. The tool is installed by default when you install the Windows 2008 Active Directory Certificate Services Role, and had been re-branded as "Enterprise PKI". The tool is implemented as a snap-in for the Microsoft Management Console.

Enterprise PKI gathers information through Active Directory about the CA certificates and certificate revocation lists (CRLs) from each CA in the enterprise. Then it validates the certificates and CRLs to ensure that they are working correctly. If they are not working correctly or if they are about to fail, it provides a detailed warning or some error information.

Enterprise PKI displays the status of Windows Server 2003, 2008 and 2008 R2 certification authorities that are registered in an Active Directory forest. You can use Enterprise PKI to discover all PKI components, including subordinate and root CAs that are associated with an enterprise CA. The tool can also manage important PKI containers, such as root CA trust and NTAuth stores, that are also contained in the configuration partition of an Active Directory forest.

Enterprise PKI is very useful when verifying the installation of an ADCS environment, or when a quick check is needed for the health of the distribution points and managed containers in Active Directory.

Launching Enterprise PKI

At a server running Windows 2008 or 2008 R2 ADCS service, launch Server Manager, expand Roles, Expand Active Directory Certificate Services and then click Enterprise PKI

The same console can be displayed, by running PKIVIEW.msc from the Search or Run menus

Enterprise PKI can also be launched from a Windows Server 2008, Windows Server 2008 R2, Windows Vista or Windows 7 computer by installing the Remote Server Administration Tools-Active Directory Certificate Services Tools from the Features set.

Enterprise PKI in Windows 2008 ADCS determines the AIA and CRL locations of the offline CA by examining certificates issued by the offline CA. The AIA and CDP distribution points for the online CAs are gathered by contacting the online CAs directly. This is different than the PKIVIEW tool behavior in Windows 2003 PKI, which relied on a CA Exchange certificate with a validity period of 1 week to gather the CDP and AIA distribution points of an issuing CA.

Running Enterprise PKI in Windows 2008 will still create the CA Exchange certificate, although as stated before, it is not used by the tool.

Understanding Distribution Points Health in Enterprise PKI

Enterprise PKI evaluates every URL included in the AIA and CDP extensions of the certificates in the CA hierarchy. The tool attempts to connect to each referenced URL and reports whether the certificate or CRL is reachable as well as whether the current version is reaching expiration.

Some of the most common mistakes encountered in PKI deployments are missing certificates or CRL files. When launching Enterprise PKI all the certification authorities in the hierarchy should be examined in the left hand pane.

The Right hand pane will include the CA's certificate and the status of its publication points. Consider the following scenarios:

• If a publication point is configured correctly, the status column will report a value of OK.
• If the publication point is configured incorrectly or if the CA certificate or CRL is not copied correctly to the publication point, the status column reports a status of Unable to Download.

To troubleshoot Unable to Download publication points, right click the publication point and click Copy URL. Paste the URL in a browser to verify if it can't be downloaded. A 404 "File not found" error in a browser indicated the file can't be downloaded, or the file is missing

In general, this error can be attributed either to:

1. A missing file (in my case above, it was the certificate file of the issuing CA). Copy the file to the distribution point and refresh Enterprise PKI.
2. The HTTP URL is accessible through a Proxy. You should consider removing the proxy requirment for the computer security context
3. There may be an access control list (ACL) blocking access to the file
4. When dealing with Delta CRLs, the web site might block the download of the file due to double escaping. This issue can easily be solved by following the steps in How to avoid Delta CRL download errors on Windows Server 2008 with IIS7

• Finally, if the CA certificate or CRL is near expiration, the status column will report a value of Expiring

There are several ways to troubleshoot this issue:

1. Renew the CA's certificate if it is about to expire and publish it to the AIA distribution points
2. CDP is about to expire, examine which CDP in the chain is about to expire, issue a new CRL and publish it to the distribution points
3. This might also be a superficial message, when you know your issuing CA's CDP publication frequency is about to issue a new CRL, however the display in Enterprise PKI is showing it as Expiring. Adjust the Options in Enterprise PKI as follows:

• The expiring certificate indicator: You can specify how many days before expiration of a certificate that the PKI Health Tool will indicate that a certificate is expiring. Consider using a much larger number than the default of 14 days. In fact, if you plan to issue certificates with a one-year validity period, you should use a notification of 365 days
• The base CRL expiration indicator: The base CRL indicator should be set to a value that reflects the base CRL publication interval of your issuing CA. If you publish the base CRL at a weekly interval, consider keeping the default expiration interval of two days. If you publish the base CRL on a daily interval, consider a value of eight hours
• The delta CRL expiration indicator Like the base CRL setting, you must choose a delta CRL interval that reflects your delta CRL publication. If you publish a delta CRL every day, the default of every four hours may be the right value for you. If you publish the delta CRL every eight hours, consider a value of two hours for expiration notification.

Examining and Understanding Active Directory Certificate Stores

Enterprise PKI can examine each of the Active Directory certificate and CRL stores by using the Manage AD Containers dialog box by right clicking Enterprise PKI, and then clicking Manage AD Containers. All the containers are stored in the configuration partition of the Active Directory Forest where the CA hierarchy is installed.

Certification Authorities Container:

Contains all the Root Certification Authorities in the Active Directory Forest. This container is accessed through the autoenrollment policies for users and computers and distributes the Root CAs to the local Trusted Root Certification Authorities store.

The Certification Authorities container is stored in CN=Certification Authorities, CN=Public Key Services, Configuration, CN=Services, DC=ForestRootdomain. The container can be accessed using any LDAP capable tool, such as ADSIEDIT, LDP.EXE, etc....

Enterprise PKI tool allows viewing or removing Trusted Root Certification Authorities to this container, but will not allow adding new Root Certification Authorities. Use Certutil -f -dspublish RootCA.cer RootCA command to add a new Root Certification Authority to this container,

Enrollment Services Container:

Contains all enterprise issuing certification authorities in an Active Directory Forest. The container is CN=Enrollment Services, CN=Public Key Services, Configuration, CN=Services, DC=ForestRootdomain. The container can be accessed using any LDAP capable tool, such as ADSIEDIT, LDP.EXE, etc....

Enterprise PKI tool allows viewing or removing Trusted Root Certification Authorities to this container, but will not allow adding new or existing enterprise certification authorities. The only method to add a new enterprise certification authority to the Enrollment Services Container is by using the Active Directory Certificate Services Role in Server Manager

NTAuthCertificates:

The NT Authority certificate object contains all entries for all CAs that can issue certificates used for smart card authentication and for Remote Authentication Dial-In User Service (RADIUS) authentication. The NTAuthCertificates object is stored in CN=NTAuthCertificates,CN=Public Key Services, Configuration, CN=Services, DC=ForestRootdomain. it can be accessed using any LDAP capable tool, such as ADSIEDIT, LDP.EXE.

Enterprise PKI tool allows adding, removing and viewing NTAuth certificates; in addition Certutil can be used to publish an NTAuth certificate if needed.

AIA Container:

Contains all CA certificates for all CAs in the CA hierarchy. The container is stored in CN=AIA, CN=Public Key Services,CN=Configuration, CN=Services, DC=ForestRootdomain. It can be accessed using any LDAP capable tool, such as ADSIEDIT, LDP.EXE.

Enterprise PKI tool allows viewing and removing certificate files from the AIA container, but will not allow adding new entries of new or existing certificates to the AIA container. A new entry can be added to the container using the Certutil -f -dspublish CertificateFile.cer NetBiosNameofCAServer.

CDP Container

Contains all base and delta CRLs for each CA in the CA hierarchy that publishes revocation information to Active Directory. This value is configured in the extensions tab of the LDAP extension.

For each CA publishing revocation information into Active Directory, a separate container is created, containing the base and delta CRLs -if any for that CA. The container for each CA will have an object referencing the CA's sanitized name of type cRLCistributionPoint. The actual container per CA is stored in CN=NetBiosNameofCA,CN=CDP, CN=Public Key Services,CN=Configuration, CN=Services, DC=ForestRootdomain.

Enterprise PKI tool allows viewing, removing and saving certificate revocation list files from the CA's respective container, but will not allow adding new entries of new or existing CRLs. An entry can be added to the container using Certutil -f -dspublish CertificateFile.crl NetBiosNameofCAServer or by issuing a new revocation list at the enterprise CA.

KRA Container:

Contains all Key Recovery Agent (KRA) certificates published to Active Directory Domain Services (AD DS) that are available for key archival operations on enterprise CAs. The actual container is CN=KRA, CN=Public Key Services,CN=Configuration, CN=Services, DC=ForestRootdomain. Each enterprise certification authority will have an entry of type ms-PKI-Private-Key-Recovery-Agent. Enterprise PKI tool allows viewing and removing certificate files from the KRA container, but will not allow adding new entries for new or existing key recovery agents. A new entry can be added to the certificate attribute of the enterprise certification authority using the Recovery Agents tab in the CA properties

Conclusion:

Enterprise PKI provides a view of the status of your network's PKI environment. Having a view of multiple CAs and their current health states enables administrators to manage CA hierarchies and troubleshoot possible CA errors easily and effectively. Specifically, Enterprise PKI indicates the validity or accessibility of authority information access (AIA) locations and certificate revocation list (CRL) distribution points.

Amer Kamal

Senior Premier Field Engineer

An active member of our community developed a very handy tool to verify - or let's actually say monitor - the validity of SSL server certificates.

After downloading and extracting the the ZIP-file the tool is quite self explanatory. Press CTRL+A or click Add Server Entry on the Server List menu. Once you have entered the web address and SSL port, the entry appears in the list of servers.

To perform the verification, just click the Scan button on the toolbar. The validity information is added to the table.

If you'd need to regularly verify the time validity of SSL certificates, save the server list for re-use.

Since my last post about SHA2 and Windows I’ve received numerous questions from customers and partners around three particular scenarios. This post will try to address those questions.

Windows XP/2003 Enrollment in SHA2 Signed Certificates

As covered in the previous post, Windows XP Service Pack 3 clients with KB 968730 can enroll SHA2 signed certificates. But looking at the Certificate Templates MMC for a version 2 template, it is not very clear how to configure SHA2. Version 3 templates include an option about hashing algorithms, but Windows XP can’t enroll in version 3 templates (Vista or newer is needed for that). So several customers have asked how to configure XP and 2003 clients to enroll in SHA2 certificates.

The answer is actually very simple. Once a CA is configured with a SHA2 at install, all certificates it issues will use the same hash. The “request hash” setting on Version 3 templates refers to the hash used only in the generation of Certificate Signing Requests (CSR). The CSR is only used during the certificate enrollment process, and a new hash is generated and attached to the final certificate by the CA.

Migrating to new PKI Hierarchy

Several customers have expressed a desire to migrate from their old SHA1 PKI hierarchy to a new hierarchy based completely on SHA2. While a full write-up of what is required would take several blog posts, I just wanted to cover a few points that are sometimes overlooked.

1. Keep in mind the process which Windows uses to build certificate chains. A very nice write-up of the process was posted previously to this blog. That being said, it is strongly recommended that clients not have to rely on AIA paths to build certificate chains. Rather, the new PKI’s hierarchy should be deployed in advance using Group Policy or “certutil -dspublish”. By placing the CA certificates locally on the clients, the administrator can both influence the path clients choose when they encounter cross certification and will ensure that outages of AIA path servers don’t affect a client’s ability to build a chain.
2. On a similar note, ensure that any new CAs that are issuing end entity certificates are listed in the NTAuthCertificates object. The process to add them is detailed here and here.
3. Some applications do not support SHA2. Before using SHA2 signed certificates with a specific application, it is recommended that all PKI dependent components of that application be tested. For example, if SHA2 will be used for S/MIME; then every email client, email server, relay, spam filter, security device, etc belonging to both one’s own organization and those of external organizations (which exchange S/MIME messages with one’s organization) would need to be validated that they can process S/MIME with SHA2. For this reason, both old and new PKI hierarchy may need to operate while applications are upgraded/migrated.

Clarification on Support for SHA2 and Windows XP/2003

There was some concern with the pervious blog post about exactly what scenarios Microsoft officially supports and does not. To be clear, the table at the bottom of the post was intended to share test results, rather than an official support statement (this is why the word “works” not “supported” was used in the table). Our official support statement is contained within KB 968730:

Windows XP SP3 implements and supports the SHA2 hashing algorithms (SHA256, SHA384, and SHA512) in the X.509 certificate validation. The changes in the certificate validation are meant to enable the scenario of the SSL/TLS authentication. Other scenarios that involve certificate validation may not work if you use certificates that are secured by using the SHA2 algorithms if the protocols and the applications do not support the SHA2 hashing algorithms. For example, the S/MIME signed e-mail verification and the Authenticode signature verification do not support the SHA2 hashing algorithms on a computer that is running Windows XP SP3.

That being said, Windows XP and Server 2003 are getting very close to the end of their support lifecycle. At the time of writing, only XP SP3 and 2003 SP2 are supported and only under the terms of Extended Support. Windows XP extended support will end on 4/8/2014. After 4/8/2014 customers will no longer be able to receive support from Microsoft and no new security hotfixes (including those for critical vulnerabilities) will be released for XP/2003. Customers are strongly encouraged to migrate systems to Windows Vista/2008 and newer.

I hope that clears up any questions.

-Adam Stasiniewicz

UPDATE (2/8): Based on some recent questions, additional information has been posted about SHA2 and Windows.

Introduction

We’ve recently received a couple of requests from customers around the functionality of SHA-256 when running on Windows XP and 2003. This has been more important recently, as NIST has recommended the migration off of SHA-1 by end of the year. More details about the NIST recommendation can be found in SP 800-78-2 and SP 800-57. Hopefully this blog post can help clear up the confusion surrounding scenarios that work and the ones that don’t.

Windows XP Support

Prior to Windows XP Service Pack 3, there was no SHA2 functionality within Windows XP. With the release of Service Pack 3 some limited functionality was added to the crypto module rsaenh.dll. This includes the following SHA2 hashes: SHA-256, SHA-384, SHA-512. SHA-224 was not included.

Windows Server 2003 Support

Windows Server 2003 Service Pack 2 does not ship with support for SHA2. This limitation can become an important concern when processing smart card logons and for mutual TLS authentications to web servers. As unlike other technologies, smart card logon and mutual TLS both use strict revocation checking; so should either the certificate itself or the revocation information (CRL/OCSP) use SHA2, the logon would fail.

KB 938397

Though support SHA2 is not included in Windows Server 2003 Service Pack 2, it is available for download. KB 938397 will bring Windows Server 2003 to the same level of functionality as Windows XP with Service Pack 3. KB 938397 is not available via Windows Update; it needs to be requested via the “View and request hotfix downloads” link on the support page. Note, KB 938397 is also offered for Windows Server 2003 Service Pack 1.

KB 968730

With the release of Windows Server 2008 it was found that Windows XP Service Pack 3 and Windows Server 2003 Service Pack 2 with KB 938397 were unable to request certificates from a Windows Server 2008 (and 2008 R2) certificate authority (CA) who’s certificate was signed with a SHA2 hash. KB 968730 was release to address this issue. Incidentally, KB 968730 completely supersedes KB 938397; so if a Windows Server 2003 Service Pack 2 system would need to both enroll from a SHA2 certificate authority and process SHA2 certificates, only KB 968730 would need to be installed. As before, KB 968730 is not available via Windows Update; it needs to be requested via the “View and request hotfix downloads” link on the support page. Note, KB 968730 is not offered for Windows Server 2003 Service Pack 1.

Windows Vista, 7, Server 2008, and Server 2008 R2

Starting with Windows Vista and Server 2008, the Cryptography Next Generation (CNG) Suite B algorithms (including SHA2) are included in the operating system. It is worth noting that even though the algorithms are available, it is up to the individual applications to implement support.

Outlook and S/MIME

Besides logon, another very popular use for smart cards is S/MIME. But before diving into Outlook and S/MIME, the following warning should be given: Regardless of the functionality Windows and Outlook provide; in order for mail to be delivered between two users, there are any number of spam filters, relays, mailboxes, etc between sender and recipient. Each of these can be made by a wide range of vendors; running on a wide range of platforms. So before deploying SHA2, testing should be done against one’s own email infrastructure, in addition to the email infrastructure of external organizations from whom S/MIME signed mail needs to be exchanged with.

All those warnings aside, the basic functionality for Outlook is a follows. Outlook 2003, 2007, and 2010 running on Windows XP Service Pack 3 can sign and validate certificates when that certificate itself is SHA2 signed. Outlook 2003, 2007, and 2010 running on Windows XP Service Pack 3 cannot validate email messages when the message itself is SHA2 signed (regardless of the certificate used). Outlook 2003, 2007, and 2010 running on Windows XP Service Pack 3 cannot sign a message with SHA2; only SHA-1 and MD5 are available.

In order to validate SHA2 messages, Windows Vista with Outlook 2003 (or newer) is needed. In order to both sign and validate SHA2 messages, Windows Vista or 7 with Outlook 2007 or 2010 is needed.

Recommendations

For organizations looking to deploy SHA2 or organizations that interact with 3^rd parties that will soon begin using SHA2, the following is recommended.

• If Windows XP is used in the environment, Service Pack 3 should be deployed. In addition to SHA2 functionality, Service Pack 3 is currently the only Windows XP service pack that is supported.
• If Windows XP systems would need to enroll in certificates from a SHA2 certificate authority, KB 968730 should be deployed.
• If Windows Server 2003 is used in the environment, Service Pack (1 or 2) and KB 938397 should be deployed.
• If Windows Server 2003 would need to enroll in certificates from a SHA2 certificate authority, Service Pack 2 and KB 968730 should be deployed. If planning on deploying KB 968730, installing KB 938397 is not necessary.
• If S/MIME using SHA2 signing for the message body is needed, workstations should be upgraded to at least Windows Vista running Office 2003.

Summary Chart

-Adam Stasiniewicz

UPDATE (2/8): Based on some recent questions, additional information has been posted about SHA2 and Windows.