To adjust the CRL and AIA distribution point there are at least three choices to do it. The most familiar way to change the distribution point might be through the CA MMC user interface. The second way is to directly change the registry key CACertPublicationURLs or CRLPublicationURLs with regedit.exe. Alternatively, you can use certutil -setreg to change these keys in the registry.

While having full editing control over the multi-valued registry key, you may miss an edit button in the UI to conveniently change an existing entry without retyping the full URL.

Only very few people are aware that you can use a copy/paste trick to overcome the missing edit button. Here are the steps to copy an existing CRL or AIA entry and create a new one:

1. Open the Certification Authority MMC snap-in.
2. Open the CA properties.
3. Go to the Extensions tab.
4. Select the entry that you want to copy from the list of available CRL or AIA entries.
5. Press <CTRL>+<C> to copy the entry into the clip-board.
6. Click the Add… button and press <CTRL>+<V>. The paste operation is certainly not limited to the Add Location window. Once the URL has been copied into the clipboard it can be pasted everywhere.
7. Change the distribution point as appropriate.

When you launch the certificate templates MMC snap-in (certtmpl.msc) for the first time, the certificate templates are installed automatically in the background. Installing the templates is independent of the availability of an enterprise CA. Enterprise Administrator permissions are required to successfully install the templates.

That's nice and convenient but what happens if you accidentally deleted the template objects from Active Directory? The templates can be viewed and also deleted (with appropriate permissions) through the Active Directory Sites and Services MMC snap-in (dssites.msc) or any other LDAP client can be used.

So, what to do if the templates or the OID container have disappeared? With a single command-line, you can get them back. As prerequisite to install the certificate templates you must have create child access to the template container in Active Directory which is the default setting for an enterprise administrator.

If you are running Windows Server 2003, use the following command with enterprise administrator permissions:

regsvr32 /i:i /n certcli.dll

If you have Windows Vista or Windows Server 2008 already in place, certutil.exe understands a new verb to re-install the templates. Certutil is included in all Windows Vista SKUs by default.

certutil -installdefaulttemplates

After performing one of the above commands you must restart the CA service.

The following two knowledgebase articles describe scenarios where re-installation of certificate templates can make sense:

• You receive an error message, and event ID 53 is logged when a client computer requests a certificate from a Windows Server 2003 SP1-based CA (http://support.microsoft.com/kb/932457).
• Event ID 77 is logged in the Application log when the CertSvc service starts on a CA server that is running Windows Server 2003 with Service Pack 1 (http://support.microsoft.com/kb/931354).

By default, Windows is caching Certificate Revocation Lists (CRL) and CA certificates to quickly verify certificate chains. The downside of this behavior is that a newer CRL is not picked up by the client until the locally cached CRL has expired.

Windows versions before Windows Vista do not support deletion or a forced update of the CRL cache.

You can view what is in your current CRL cache with the following command:

certutil -URLcache CRL

On Windows Vista, CAPI 2.0 has support to set a expiry date for the CRL and OCSP cache. You can use certutil to set a date and time when all cache entries become invalid. The following commands require administrative permission on the system.

To see when the cache was invalidated the last time, perform this command:

certutil –getreg chain\ChainCacheResyncFiletime

Note: If the ChainCacheResyncFiletime was never set manually before, the registry key does not exist and the following error message is shown:

CertUtil: -getreg command FAILED: 0x80070002 (WIN32: 2)

CertUtil: The system cannot find the file specified.

The error can be ignored because default CRL caching takes place in this case.

If the @now parameter is used, all cached entries are invalidated immediately.

certutil -setreg chain\ChainCacheResyncFiletime @now

To disable temporarily the cache until after now plus 3 days and 6 hours, use this command. Setting the registry value to a future date implies that no cache entries will be used until after the date specified. The value of such a configuration is questionable.

certutil –setreg chain\ChainCacheResyncFiletime @now+3:6

To delete a registry value:

certutil –delreg chain\ChainCacheResyncFiletime

The validity time of a certificate revocation list (CRL) is critical for every public key infrastructure. By default, most applications verify the validity of certificates against a CRL.

Two CRL types exist: base CRLs and delta CRLs. In case where no delta CRL is used, certificates are treated as invalid if the base CRL is not available or expired. If a delta CRL is in use, the delta and base CRL must be available and valid to succeed with certificate verification.

The information provided in this article applies for both, the base CRL and the delta CRL generation.

When you look at a CRL, there is information about the Next update, the Next CRL Publish and the Effective date of the CRL. The term Effective date is used in the Windows certificate dialog while certutil.exe and the RFC name this field thisupdate.

• Effective Date (aka thisupdate) - The date that a CRL became effective. The effective time, by default, is set to 10 minutes prior to the current date and time to allow for clock synchronization issues.
• Next CLR Publish - This non-critical CRL extension indicates the date and time when a Windows CA will publish a new CRL. When a Windows computer uses a CRL for certificate verification it also examines the Next CRL Publish extension. If the Next CRL Publish date is already in the past, it connects to the CRL distribution points (referenced in the certificate) and attempts a download of a newer CRL. Note: If CRL is locally cached, and under certain conditions, download of new CRL might be skipped, even if Next CRL Publish date is already in the past. For more information, please see http://technet.microsoft.com/en-us/library/ee619723(v=ws.10).aspx.The time after the Next CRL Publish and before the Next Update is a buffer time to allow Windows computers retrieval of a CRL before the CRL has actually expired.
• Next Update - The date and time that a Windows client considers as the expiration date of the CRL. From an operational viewpoint, this is the most critical information. If this date passes, Windows computers will invalidate certificates that are checked against this CRL.

For more information about relation between the above three fields, see http://technet.microsoft.com/en-us/library/ee619723(v=ws.10).aspx.

Now we know the CRL attributes that control the CRL validity. The question is how these dates are calculated by a Windows CA. Read on to find out!

Under the Certification Services configuration hive in the registry two values control the overlap period for the base CRL and two registry values define the overlap period for delta CRL creation:

HLKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA Name>:

CRLOverlapPeriod=REG_SZ:Hours|Minutes
CRLOverlapUnits=REG_DWORD:0x0
CRLDeltaOverlapPeriod=REG_SZ:Hours|Minutes
CRLDeltaOverlapUnits=REG_DWORD:0x0

You can verify the settings for the above registry keys on your CA computer with the following commands:

certutil -getreg CA\CRLOv*

certutil -getreg CA\CRLDeltaOv*

If the registry values are set and valid, the overlap period for a base or delta CRL is initially calculated by the CA as:

OverlapPeriod = CRLOverlapUnits * CRLPeriod

If an invalid or no value is present under the CRLOverlapUnits registry key, the OverlapPeriod for a base CRL is initially calculated as 10 percent of the CRLPeriod and CRLPeriodUnits registry values:

OverlapPeriod = (CRLPeriodUnits * CRLPeriod) / 10

If the OverlapPeriod for a Delta CRL is calculated, the entire period of time specified as CRLDeltaPeriod and CRLDeltaPeriodUnits of the delta CRL is used.

OverlapPeriod = (CRLDeltaPeriodUnits * CRLDeltaPeriod)

As a next step, the smaller value of either the so far calculated OverlapPeriod or 12 hours is taken.

OverlapPeriod = min(OverlapPeriod, 12 hours)

If no CRLPeriodUnits or CRLDeltaPeriodUnits have been set, the OverlapPeriod is 0 at this point. As a next step, the ClockSkewMinutes parameter from the registry is taken into account. The ClockSkewMinutes are primarily used to mitigate time differences between a client computer and the CA. To further calculate the OverlapPeriod, the ClockSkewMinutes is multiplied by 1.5 and then compared with the calculated OverlapPeriod. The greater of both values wins.

OverlapPeriod = max(OverlapPeriod, 1.5 * ClockSkewMinutes)

In case the Overlap period is calculated for a base CRL, it cannot be longer than CRLPeriodUnits * CRLPeriod. Therefore the smaller value wins.

OverlapPeriod = min(OverlapPeriod, CRLPeriodUnits * CRLPeriod)

Is the Overlap time calculated for a delta delta CRL, the OverlapPeriod can not be longer than CRLDeltaPeriodUnits * CRLDeltaPeriod.

OverlapPeriod = min(OverlapPeriod, CRLDeltaPeriodUnits * CRLDeltaPeriod)

Finally, the ClockSkewMinutes are added to the calculated OverlapPeriod.

OverlapPeriod = OverlapPeriod + ClockSkewMinutes

The calculation of the OverlapPeriod is done so far. The the actual calculation of the CRL values can start a next step:

The Effective Date must not be earlier than the CA certificate became valid. This is because the CRL carries the CA certificate's signature.

Effective Date = max(Current Time - ClockSkewMinutes, NotBefore_date_from_the_CA_certificate)

The Next CRL Publish for a base CRL is calculated as the sum of current time plus CRLPeriod:

Next CRL Publish = Current Time + (CRLPeriodUnits * CRLPeriod)

The Next CRL Publish for a delta CRL is calculated as the sum of current time plus CRLDeltaPeriod:

Next CRL Publish = Current Time + (CRLDeltaPeriodUnits * CRLDeltaPeriod)

The Next Update is for a base CRL is calculated with the following formula:

NextUpdate = min(Current Time + (CRLPeriodUnits * CRLPeriod) + OverlapPeriod + ClockSkewMinutes, NotAfter_date_from_the_CA_certificate)

The Next Update is for a delta CRL is calculated with the following formula:

NextUpdate = min(Current Time + (CRLDeltaPeriodUnits * CRLDeltaPeriod) + OverlapPeriod + ClockSkewMinutes, NotAfter_date_from_the_CA_certificate)

Since you have understood the algorithm now, you may want to examine the CRL on your system and see what the dates are set to. If you open the certificate management MMC snap-in from a command-line, you can see a list of all CRLs that have been generated by the CA so far. At a command-prompt, perform the following command:

certsrv.msc /e

With the /e switch, an additional container is shown in the snap-in that lists all CRLs at a glance.

Technically, it is possible to install an enterprise CA on a Windows Server Standard edition. With this configuration, enterprise features of the certification authority are intentionally not available.

To enable the CA enterprise features, it is required to upgrade a Windows Server from Standard to Enterprise edition. To keep the existing enterprise CA configuration, it is recommended to just perform a Windows inplace upgrade. If you do this on a Windows Server 2008 you will recognize that only V1 certificate templates are available for assigning after the upgrade was performed.

To fix the problem, close the Certificate Services MMC snap-in and run the following commands with administrator permissions at a command-line on the CA computer:

certutil -setreg ca\setupstatus +512

net stop certsvc

net start certsvc

When you re-open the Certificate Services MMC snap-in, you are able to assign V1, V2 and V3 certificate templates to the certification authority.

[February 3, 2009 update] An official Microsoft Knowledgebase article is published under http://support.microsoft.com/kb/967332.

When a PKCS#10 request for a CA certificate is generated, a pre-defined set of certificate attributes is included. This blog entry explains how to eliminate attributes that would go into the CA certificate request by default.

Imagine that you are setting up a new subordinate CA where the parent CA is a non Windows CA. The parent CA may not support or accept certificate attributes like the certificate templatename. To exclude an attribute from the CA certificate request you must create a capolicy.inf file in the %WINDIR% directory before creating or renewing a CA certificate. The capolicy.inf file lists the OIDs of the certificate extensions to be excluded in the Extensions section. See the Microsoft Knowledgebase for a list of Object IDs associated with Microsoft cryptography.

The following sample caplicy.inf file would exclude the CA version and the certificate template name from the CA certificate request.

[Version]
Signature= "$Windows NT$"

[Extensions]
1.3.6.1.4.1.311.21.1 =
1.3.6.1.4.1.311.21.7 =

Note: Certificate attributes should only be removed from a certificate request if there is real demand for it. Never do it just for cosmetics!

When working with a capolicy.inf file you should be aware of the behavior described in the Microsoft Knowledgebase article Custom extensions in the CAPolicy.inf file do not take effect after you renew the root CA certificate by using a new key. The article applies for Root and Subordinate CAs running on Windows Server 2003 SP1 or Windows Server 2003 SP2.

Today I want to comment on the quite popular Microsoft Knowledgebase article How to decommission a Windows enterprise certification authority and how to remove all related objects from Windows Server 2003 and from Windows 2000 Server. I am referring to version 6.0 of the article with a review date of November 18th, 2008. You should be aware that the article has documentation bugs that need to be fixed. Until we are publishing a corrected version, you should consider the following information when applying the steps from the article.

1. In Step 6 L, the article asks you to delete all certificate templates. This is misleading information because it is only appropriate when you have already deleted ALL CAs in the Active Directory Forest. If there are still enterprise CAs in operation, certificate templates must not be deleted.
2. The article does not point out to identify all of the CA objects in Active Directory (under the KRA container, for example), so some may be left around. To clean up after a CA that left objects around in Active Directory, run the following commands to see what AD objects remain:
   
   certutil –ds {CACommonName}
   certutil –ds {CAMachineNetBiosName}
   
   For example, if the common name of the CACommonName is called CorpCA01 and the CAMachineNetBiosName is CACorpServer you would perform the following commands:
   
   certutil –ds CorpCA01
   certutil –ds CACorpServer
   
   Once you look over the list of DNs displayed, and are satisfied they are all related to the abandoned CA, you can change -ds to -dsDel and repeat the commands to delete the CA's objects with enterprise administrator permissions.
   
3. In Step 6 M, the article says to delete the NTAuthCertificates object. This is wrong information because this object should never be deleted - only CA certificates should be deleted from its cACertificate attribute. Use the following command to see the full ldap path to your NtAuthCertificates object in your Active Directory.

certutil -ds -v NtAuthCertificates

With enterprise administrator permissions you can use the following command to delete certificates from within the NTAuthCertificates store:

certutil –viewdelstore "ldap:///CN=NtAuthCertificates,CN=Public Key Services,...,DC=...,DC=com?base?cACertificate"

The -viewdelstore verb invokes the certificate selection U/I on the set of certificates in the specified attribute. You can view cert details, and cancel out of the selection dialog to make no change. If you select a certificate, it will be deleted when the U/I closes and the command completes execution.

To clean up the NTAuthCertificates you can also use the PKIview MMC snap-in. It is part of the Windows Server 2003 Resource Kit Tools and the Microsoft Remote Server Administration Tools in Windows Server 2008 and Windows Vista.

Until Windows Server 2008 shipped, every Domain Controller had a readable and writable copy of the Active Directory schema, domain naming context and configuration naming context. This statement changed when we introduced the Read Only Domain Controller (RODC) role with Windows Server 2008. The RODC creates several new configuration scenarios for Active Directory integrated applications.

With this blog post I want to explain a situation where a Windows Server 2003 Enterprise CA setup fails with error Element not found. 0x80070490. The setup error occurs when the intended Windows Server 2003 CA computer maintains a secure channel with a Windows Server 2008 RODC. In this case, the CA setup code cannot write new objects into the Active Directory configuration naming context. In Windows Server 2008 the CA setup code was updated to always make a connection to a writable Domain Controller in the beginning and then stick with that Domain Controller for all the operations done during setup.

To work around the Windows Server 2003 CA setup limitation, you could use the nltest.exe command from the Windows Support tools. To do so, make sure that a writable domain controller exists in the site that the Windows Server 2003 CA computer belongs to. If no writable domain controller is configured for the site, you must work with your Active Directory Enterprise administrator to change the site configuration so that a writable domain controller becomes available in the CA’s site.

To fix the problem, open a command prompt on the intended Windows Server 2003 CA to execute the following commands with local administrator permissions.

As a first step, query the DNS for a list of writable domain controllers in the domain. In this sample I use contoso.com as domain name.

nltest /dnsgetdc:contoso.com /WRITABLE

Next, reset the secure channel that is currently used between the Windows Server 2003 and the RODC.

nltest /sc_reset

Finally, verify if the secure channel is now set up with a writable domain controller.

nltest /sc_query:contoso.com

If the intended CA computer is now connected to a writable domain controller, restart the CA setup.

A few days ago I worked in a test environment that also consists of a PKI. I used the Microsoft Terminal Services Client (mstsc.msc) for a while to connect to various machines in the test environment. One day, I helped a coworker troubleshooting a certificate problem in the test environment. From his machine, I connected via Microsoft Terminal Services Client to one of the test servers. While connected to the test server, I opened the Certificates MMC snap-in (certmgr.msc) and looked to the current user’s personal certificate store. Besides test certificates I also saw certificates with my personal name in the subject attribute. What was going on here, I thought? Where do these certificates come from? Time to investigate!

Investigation

I opened one of the certificates with my name in it to find out more details. The certificate definitely belonged to me. Even worse, the General tab of the certificate details told me that I have a private key for this certificate (“You have a private key that corresponds to this certificate.”). I copied the serial number of that certificate from the Details tab and opened a command prompt. What certificate service provider was used to issue that certificate?

The following command told me the answer:

certutil -v -silent -user -store My "05 05 1c 00 22 7f 3c dd fa 98" | find "Provider ="
Provider = Microsoft Base Smart Card Crypto Provider

I looked down to the notebook and noticed that no smartcard was sitting in the reader. That made me even wonder more. What has finally happened here?

Analysis

1. When I connected to the test environment from my personal notebook, my smartcard was in the reader while I was using a Terminal Services session.
2. I didn’t use a custom RDP file when I started the Microsoft Terminal Services Client (mstsc.msc), so the settings from %USERPROFILE%\documents\Default.rdp configuration file have been applied.
3. Under the Options >>> button on the Local Resources tab under the More … button, Smart cards was check-marked. That setting caused the Microsoft Terminal Services Client to map my smartcard into the remote desktop session.
   
4. On the remote test server, the Certificate Propagation service (CertPropSvc) was running.

The combination of those 4 conditions caused my personal certificates to appear in the user profile of the remote desktop session. The Microsoft Terminal Services Client maps the smart card reader as a device into the remote desktop session. If a smartcard is available in the reader, the certificates become accessible within the remote desktop session. The Certificate Propagation Service (CertPropSvc) reads certificates (not the private keys!) from a smartcard and puts them into the current user’s certificate store. This is exactly what has happened here.

The reason why the Certificate Propagation Service is doing so, is related to certificate autoenrollment. When autoenrollment is triggered as part of the regular group policy interval (default is every 8 hours with a timescew of +/-90 minutes) it examines certificates in the personal store and determines if certificate enrollment, renewal or archival is required. To enable autoenrollment for certificates on smartcards, it is required that these certificates are registered in the personal store. Otherwise, autoenrollment would have to know on which devices (smartcards, tokens, …) certificates have ever been stored. For every certificate that is associated with a private key on the local system, an entry for the certificate service provider (CSP) exists in the key properties. Once autoenrollment has access to a certificate and the CSP, it is able to manage a certificate that is stored on a device.

A question remains, regarding the statement “You have a private key that corresponds to this certificate.” on the General page of the certificate details dialog. Why is that? How could the system tell me that there is a private key while my smart card is not inserted into the reader? Here is the answer: When the Certificate Propagation Service reads a certificate from the card, it is a true statement that you have a private key for the certificate. The private key is available on the smartcard and therefore, in the certificate’s key property (which is stored in the certificate store) it is noted that a private key is there. However, the key property which links a certificate with a key is only written once when a certificate is copied into the certificate store. There is no later update mechanism that continuously verifies the key property. So in my case, the key property was created when the Certificate Propagation Service read the certificate from my mapped smart card and at that time, the private key was available to the system. However, if the smart card with the key on it is removed from the system, the key property is not updated.

To summarize, the Certificate Propagation Service just copied my certificates into the certificate store while the private key was available on the smart card. The security of my private keys was not at risk at any time. Only the certificates – which can bee treated as public information anyways - have been disclosed.

Prevention and cleanup

What have I done to avoid distribution of my certificates when working with remote desktop sessions? The simplest thing is to manually uncheck the Smart card mapping in the Microsoft Terminal Services Client. This can also be done with group policies. Since all four conditions from above have to be true, disabling the Smart card mapping is effective. Additionally I stopped the Certificate Propagation Service with a group policy on all servers in the test environment. This optional configuration step avoids unintended certificate distribution in case a unmanaged workstation still has enabled Smart card mapping.

Finally, I used the following command to manually remove the certificates from a user profile:

certutil –user –delstore My "Firstname Lastname"

In my case, manual cleanup was doable because the number of remote profiles was low. An automated solution would be required if a broader certificate store cleanup is required. But that’s another story …

A co-worker posted an interesting blog about configuring the Windows Server 2008 CA Web Enrollment proxy at

http://blogs.technet.com/askds/archive/2009/04/22/how-to-configure-the-windows-server-2008-ca-web-enrollment-proxy.aspx.

Starting with Windows Server 2008 the CA product team introduced a set of COM objects that can be used to control the installation of CAs. Using VBScript you can quickly automate the setup and installation of a CA.Below is a script that is being used by the product team in our testing of Certificate Services. SetupCA.vbs was designed to have the functionality present in the setup UI but in an easy command line that can be used in automation. Most of the functionality of the script is fairly straight forward in just setting properties on the setup object. A couple of features, like the key/cert re-use, take a bit of code to get the setting right.

All of the ICertSrvSetup COM object properties and methods are documented in the MSDN at http://msdn.microsoft.com/en-us/library/bb736371%28VS.85%29.aspx.

The setup script is attached to this post, simply click the link for setupca.vbs and save the file to your local system.

Some example usages of the script:

Install Enterprise Root CA
Cscript setupca.vbs /ie /sn MyRootCA /sk 4096 /sp "RSA#Microsoft Software Key Storage Provider" /sa SHA256

Install Standalone Sub CA
Cscript setupca.vbs /it /sn MySubCA /sr MyParentCAMachine\MyRootCA /sk 384 /sp "ECDSA_P384#Microsoft Software Key Storage Provider" /sa SHA1

Uninstall CA:
Cscript setupca.vbs /uc

Install Web Pages:
Cscript setupca.vbs /iw /sr MyParentCAMachine\MyRootCA

There is also a usage that lists all the parameters if you run the script without any arguments.

UPDATE: Script has been updated to include option for offline requests using new /OR switch. Example:

Install Enterprise Sub CA saving request to a file:

Cscript setupca.vbs /if /sn "My Sub CA" /sp "RSA#Microsoft Software Key Storage Provider" /sk 4096 /or "c:\temp\ca.req"

Jonathan Stephens posted an excellent Blog about this topic; however, it didn’t include the steps. As a result, I decided to type this Blog detailing the steps required. The following assumptions have to be met before proceeding with these steps:

1- There is a new valid Certification Authority configured

2- There is a new distribution point configured for AIA and CDP locations named http://crl.contoso.com/CertData

Steps:

1- Logon to the old Enterprise Certification Authority as an Enterprise Administrator.

2- Identify the AIA and CDP distribution points

1. a.Open the Certification Authority Console
2. b.Right click the Certification Authority name and click Properties
3. c.Click the “Extensions” tab
4. d. Document the distribution points configured for CRL Distribution Point (CDP) – as an example http://<serverDNSnname>/CertEnroll/<CANAME>CRLNameSuffix><DeltaCRLAllowed>.crl which refers to local IIS installed on the server, or http://pki.contoso.com/Certenroll/<CAName><CRLNameSuffix><DeltaCRLAllowed>.crl

Note: Ignore the LDAP and C:\%windir% locations

1. e. In the “Extensions” tab, select Authority Information Access (AIA) from the drop down menu
2. f.  Document the distribution points configured for the AIA extensions – as an example http://<ServerDNSName>/Certenroll/<ServerDNSName>_<CAName><CertificateName>.crt  which refers to the local IIS installed on the server or http://pki.contoso.com/Certenroll/<ServerDNSName>_<CAName><CertificateName>.crt

Note: Ignore the LDAP and C:\%windir% locations

3- Disable Delta CRL and Issue a long Certificate Revocation List (CRL)

1. a. Open the Certification Authority Console
2. b. Right click “Revoked Certificates”, and then click “Properties”
3. c. Uncheck “Publish Delta CRL”
4. d. Change the “CRL publication Interval” to 99 years and then click OK
5. e. Open the command line with elevated privileges
6. f.  Run Certutil –crl  to issue a new Certificate Revocation List (CRL)

4- Copy the old Certification Authority’s certificate (CRT) and certificate revocation list (CRL) files to the server hosting website http://crl.contoso.com/CertData 

1. a. On the old Certification Authority, navigate to %windir%\System32\CertSrv\CertEnroll
2. b. Copy the Certification Authority’s certificate (CRT) and certificate revocation list (CRL) to the directory hosting http://crl.contoso.com/CertData

5- Redirect the Authority Information Access (AIA) and Certificate Revocation List (CRL) distribution points  of the old Certification Authority to http://crl.contoso.com/certdata

1. a. This can be done using an IIS redirect, or a DNS CNAME redirect to redirect Authority information Access (AIA) and Certificate Revocation List (CRL) of the old Certification Authority documented in steps 2.d and 2.f to the new web server http://crl.contoso.com/certdata

6- Document and remove all  certificate templates available on the old Certification Authority to prevent it from issuing new certificates

1. a. Open the command line with elevated privileges
2. b. Run Certutil –catemplates > c:\catemplates.txt  to document all available certificate templates at the old Certification Authority
3. c. Launch the Certification Authority console
4. d. Navigate to “Certificate Templates”
5. e. Highlight all templates in the right pane, right click and then click “Delete”

At this point, the old Certification Authority can’t issue any certificates, and has all of its Authority Information Access (AIA) and Certificate Revocation List (CRL) redirected to a new web site http://crl.contoso.com/CertData The next steps will detail how to document the certificates issued by templates from the old Certification Authority and how to make them available at the new Certification Authority.

7- Identify and document the certificates issued based on certificate templates by sorting the Certification Authority database

1. a. Highlight “Issued Certificates”
2. b. Navigate to the right, and sort by “Certificate Templates”
3. c. Identify the certificates issued by default certificate template types
4. d. Identify the certificates issued by custom certificate templates – any template other than the default certificate templates mentioned earlier

8- Dump the certificates based on the default certificate template types:

1. a. Open the command line with elevated privileges
2. b. Run Certutil -view -restrict "Certificate Template=Template" -out "SerialNumber,NotAfter,DistinguishedName,CommonName" > c:\TemplateType.txt
3. c. Examine the output of c:\TemplateType.txt and document all the certificates needing immediate action – i.e. requiring issuance from the new CA infrastructure if needed such as Web SSL.
4. d. Consult with the application administrator using the certificates to determine the best approach to replace the certificates if needed

Note: Replace Template with the correct template name.

9- Dump the certificates based on the custom certificate template types:

1. a. Open the Certification Authority Console
2. b. Right click “Certificate Templates” and click “Manage”
3. c. Double click the certificate template and click on “Extensions” tab
4. d. Click on “Certificate Template Information”
5. e. Copy the Object Identifier (OID) number – the number will look similar to 1.3.6.1.4.1.311.21.8.12531710.13924440.6111642.16676639.10714343.69.16212521.10022553
6. f. Open the command line with elevated privileges
7. g. Run Certutil -view -restrict "Certificate Template=OIDNumber" -out "SerialNumber,NotAfter,DistinguishedName,CommonName" > c:\CustomTemplateType.txt

Note: Replace OIDNumber with the number identified in step 9.e

1. h. Examine the output of c:\CustomTemplateType.txt and document all the certificates needing immediate action – i.e. requiring issuance from the new CA infrastructure if needed such as custom SSL certificates.
2. i. Consult with the application administrator using the certificates to determine the best approach to replace the certificates if needed

Note: You don’t need to take any action if the certificate was auto-enrolled because the certificate holder will renew the certificate when it expires from the new CA infrastructure.

10- Enable the Certificate Templates needed based on the results of steps 7-9 on the new Certification Authority

1. a. Logon to the new Certification Authority as an Enterprise Administrator
2. b. Right Click “Certificate Templates”, click “New” and then click “Certificate Template to Issue”
3. c. Choose all the certificate templates needed in the “Enable Certificate Templates” window and click “OK”

11- <Optional> At this point you can uninstall the Certification Authority Role on the old Certification Authority

1. a. Backup the old Certification Authority using the steps outlined in Disaster Recovery Procedures for Active Directory Certificate Services (ADCS)
2. b. Uninstall Certificate Services from the old Certification Authority
3. c. Decommission the server unless it is running other applications

12- Once all certificates are issued by the new infrastructure, you can safely remove all the Authority Information Access (AIA) and Certificate Revocation List (CRL) files from you infrastructure by following the steps in How to Decommission a Windows Enterprise Certification Authority and How to Remove All Related Objects and from the web server hosting http://crl.contoso.com

Amer F. Kamal

Senior Premier Field Engineer

For those that missed the big news on the Ask Premier Field Engineering (PFE) Platforms blog, our OCSP responder is now JITC certified.  This certification is important for customers looking to deploy our OCSP responder in US DoD environments.  Jesse Esquivel posted a really excellent explanation, and a lab guide to help folks get started using our OCSP responder.   Check out the post at: http://blogs.technet.com/b/askpfeplat/archive/2014/01/08/microsoft-pki-ocsp-responder-now-jitc-certified-and-lab-setup-guide.aspx

Digital certificates are a key mechanism for establishing identity on the Internet. Trust in these certificates is a result of trusting the issuing entity – the Certification Authority (CA). Unfortunately, as a result of a number of CA related incidents over the past few years, that trust has been somewhat undermined. A number of approaches to address this lessened trust have surfaced in academia and industry, including Public Key Pinning, network notary based solutions such as Perspectives and Convergence, and making the list of issued certificates public by either requiring CAs to operate a simple web service, or supporting  more complex protocols like Certificate Transparency (CT).

Problems with Today's Certificate Trust Model

Today, browsers base trust decisions on the inclusion of roots of trust in a root store. Inclusion in that root store is usually based on factors such as WebTrust for CA or ETSI TS 102 042 audits and adherence to industry guidelines published by the CA Browser Forum for SSL certificates. Each browser vendor may specify additional technical requirements.

Microsoft requires each root CA to provide evidence of a successful audit from a qualified auditor annually. In addition, the root CA is also required to sign a contractual agreement to follow technical requirements such as the use of strong cryptographic algorithms.

In all browsers, trusted roots are effectively treated equally, and for the most part, can issue certificates for any domain name. If one CA is compromised (e.g. DigiNotar) or fails to follow its established operating procedures (TurkTrust, ANSSI), the result is often wrongly issued or fraudulent certificates that may be used in Man-In-The-Middle (MITM) attacks to spoof the identity of web sites. CAs are not infallible and when problems do arise, the CA has a very difficult task detecting all fraudulent or wrongly issued certificates quickly or at all.

Detecting fraudulent certificates (or any fraudulent cryptographic statements in general) used in MITM attacks is difficult because the attacker often erases any evidence of issuance from the compromised CA. Detecting attacks from the victim’s point of view is also difficult because the victim do not have data from the perspective of users not under attack for reference.

As the cost of computing power decreases, the likelihood of attacks against weak cryptographic algorithms has significantly increased. In May 2012, a complex piece of targeted malware known as “Flame” was identified which essentially spoofed the Windows Update channel by exploiting a Microsoft operated CA that was still using MD5 and convinced the victims to download its binaries as a security update from WU. This incident taught us that simply requiring all CAs to stop using weak cryptographic algorithms is not sufficient. We must also monitor the ecosystem closely for compliance and drive the ecosystem to switch to stronger algorithms by announcing timelines to block weak crypto algorithms from MS products far in advance.

Microsoft’s Vision for Improving the Trustworthiness of Certificates

Microsoft believes the best way to improve the security of certificates is to have the capability to detect fraudulent or wrongly issued certificates in the wild quickly.

Like the SmartScreen Filter built into Internet Explorer that is designed to warn users when they attempt to visit a phishing site, we believe monitoring the internet for fraudulent or wrongly issued certificates should be an integral part of the browsing experience. We also believe that any viable solution to improve the security of certificates cannot add more complexity or place more burden on web site operators and end users.

In Internet Explorer 11, we have extended the telemetry collected by the SmartScreen Filter to include the SSL certificates presented by web sites. We are building tools to analyze this information on our servers to build intelligence about certificates issued by every root CA trusted by IE as seen by our users around the world. Our initial goal is to flag potential MITM attacks using publicly trusted certificates that affect thousands of IE11 users. Over time, we will enhance the feature to detect attacks against a smaller number of IE users.

The following are examples of some of the scenarios where we can detect fraudulent or wrongly issued certificates using this data, in addition to detecting CAs to do not meet the technical requirements defined either in the Microsoft Root CA Program, or in the CA Browser Forum guidelines.

1. A website is using a certificate that is capable of being used as a subordinate CA. This would indicate the certificate has been issued wrongly
2. If a website suddenly presents a different certificate only to a certain region where a different CA issued the certificate. This might indicate a possible MITM attack in a specific country or region
3. There was a sudden and significant change in the fields a CA includes in certificates it issues. For example, omission or change in the OCSP responder location. This would indicate a CA was either compromised, or has not followed standard operating procedures

When potential fraudulent or wrongly issued certificates have been identified, we will work with the CA to identify the cause. Depending on the severity and scale of the problem, the CA could revoke the certificate using standards based certificate revocation mechanism. In addition, Microsoft may also use the Disallowed Certificate Trust List mechanism to revoke certificates that affect the security of a broad set of Microsoft customers.

Note that that the detection of homoglyphic attacks (where human is fooled due to visual similarity, such as rnyspace.com and myspace.com) and fraudulent certificates issued as a result of insider attacks are out of scope.

Transparency vs Privacy

Many customers consider internal DNS records to be sensitive information that they do not want to make public. At the same time, they may prefer to purchase certificates from public CAs for servers on their internal network where the server name is under subdomain of a public domain name that is not published in public DNS records. With more businesses permitting employees to bring your own device (BYOD) and use them on internal networks, we believe customers should have the option to purchase certificates from a public CA for internal servers without disclosing internal network information to the public.

We also believe domain registrant should have the option to monitor all certificates issued by all public CAs that contain their domain names, once the domain registrant prove domain registration. Such as service could be similar to the Smart Network Data Service (SNDS) operated by Outlook.com to allow owners of IP address space to help fight against spam. In addition, domain registrants could be notified by email when new certificates with their domain names appear in our database. The domain registrant would have the option to report suspicious certificates to us and notify the CA to revoke the suspicious certificate.

Privacy is a core component of trustworthy computing. Microsoft is committed to helping ensure users’ privacy while providing protection from unsafe websites. Telemetry submitted to the SmartScreen web service for evaluation is transmitted in encrypted format over HTTPS. The data is not stored with a user's IP address or other personally identifiable information. Because user privacy is important in all Microsoft's products and technologies, Microsoft has taken steps to help ensure that no personally identifiable information is retained or used for purposes other than improving online safety; data will not be used to identify, contact, or provide advertising to users. You can read more in our privacy statement.

Conclusion

In conclusion, with IE11, you can feel safer when browsing to your popular email or banking website.  We do this in a seamless manner for both user and trusted CAs perspective via collecting telemetry as part of user browsing activity and performing analysis on our backend servers. New certificate related activities for a domain name could be automatically reported to domain registrants who can decide whether it needs to be revoked or not. In summary, Microsoft is working hard to protect you from fraudulent or wrongly issued certificates with a solution that does not require changes to existing web site operations or the IE user experience.

Acknowledgement

Many thanks to Kelvin Yiu and Anthony Penta for co-authoring this blog post. Also, thanks to Nelly Porter, Kevin Kane, Glenn Pittaway and Magnus Nystrom for their review of this blog post. 

Hey everyone this is Wes Hammond from Premier Field Engineering and I wanted to share with you some info that I have gathered about setting up constraints.

What are Constraints?

Constraints are used to restrict certificate authorities that you DO NOT TRUST that are part of your chain.  They come in the form of rules placed on the certificate authority that permit or restrict the certificates issued by the CA based on the criteria provided in the request.

Where to apply Constraints?

This is a great question.  While Constraints can be defined at any level of a PKI, it’s recommended that they be applied at a subordinate (hopefully a Policy CA) and not a Root CA.  Setting this in subordinate CA allows the PKI to maintain flexibility.   If set at the Root CA, this would require a redeployment of the hierarchy in the event a change in the constraint or policy is desired.

Basic Constraints

Basic Constraints limit the path length for a certificate chain.  This type of constraint limits the number of CAs that exist below the CA (depth) where the constraint is defined.  See the diagram below.

Specifying a basic constraint of 1 at the policy CA ensures that the maximum path length for certificates that chain to the Policy CA is 1 level deep.  If a subordinate certificate is requested from one of the issuing CA’s, the request will fail.

Applying Basic Constraints

Basic Constraints can be applied with 2 different methods.

CAPolicy.inf

Applying Basic Constraints in the CAPolicy.inf allows the CA Manager to specify the constraint during installation or renewal from the CA where the constraint is being set.

Sample:

Policy.inf

The administrator of a parent CA can set basic constraints on a subordinate by applying a policy to the request delivered from the subordinate before it is issued.  The syntax is the same as that in the CAPolicy.inf.

Examples:

Here is an example of a request containing Basic Constraints

Naming Constraints

Naming constraints ensure that a certificate request presented to the Certificate Authority must conform to set of naming rules.  All name forms included in the request must be in the permitted namespace and must not be in the excluded namespace.  See the diagram below:

Types of Naming Constraints

Relative distinguished name

DIRECTORYNAME = “DC=contoso, DC=com”

DNS domain name

DNS = .contoso.com

Universal Resource Identifiers (URI)

URL = http://.contoso.com

E-mail name and User principal name (UPN)

Email = .contoso.com
UPN = .contoso.com

IP address

IP Address constraints limit the IP or IP ranges that can successfully receive certificates.  The IP(s) must include both the IP address and the subnet mask.

More examples of name constraint and their syntax can be found here:
http://technet.microsoft.com/en-us/library/cc737026(v=WS.10).aspx

Applying Naming Constraints

CAPolicy.inf

Applying Name Constraints in the CAPolicy.inf allows the CA Manager to specify the constraint during installation or renewal from the CA where the constraint is being set by using the [extensions] syntax.  Below is an example that contains both permitted and excluded Name Constraints.

Sample:

Policy.inf

The administrator of a parent CA can set Name Constraints on a subordinate by applying a policy to the request delivered from the subordinate before it is issued.  The syntax is the same as that in the CAPolicy.inf.  However, an alternative syntax is also supported such as that seen below.

Examples:

Here is an example of a request that contains Name Constraints.

Application Policy

A typical subordinate CA can issue an end entity certificate for “ANY” purpose.  Applying Application Policy allows restriction on the Enhanced Key Usage for certificates issued by a subordinate.  See the diagram below:

Applying Application Policy

CApolicy.inf

Applying Application Policy in the CAPolicy.inf allows the CA Manager to specify the constraint during installation or renewal from the CA where the constraint is being set.

Sample:

Policy.inf

The administrator of a parent CA can set the Application Policy on a subordinate by applying a policy to the request delivered from the subordinate before it is issued.  The syntax is the same as that in the CAPolicy.inf

Examples:

Here is an example of a request that contains Enhanced Key Usage and/or Application Policy.

Applying Policy.inf to a request

If you would like to apply a policy.inf to a request use the command line below:

Certreq -policy originalrequest.req policy.inf modifiedrequest.req

originalrequest.req – the original request file provided by the subordinate to the parent CA
policy.inf – The policy file containing the settings you want to be applied to the request
modifiedrequest.inf – This is the output file that will contain the original request and has been modified by the policy.  This file will be supplied to the parent CA instead of the originalrequest.req

Hello All, This is Wes Hammond with Premier Field Engineering back with follow up to a previous blog about automatic renewal of web site certificates.  The original blog can be found in the references below.

IIS 8.5 in Windows Server 2012 R2 includes a new option that allows certificates renewed via Auto Enrollment to rebind to a Web Site.

Step By Step Instructions:

1. Open IIS Manager and click on the server node. (the setting is a server only setting) 

2. Double click on Server Certificates

3. On the right navigation pane click on “Enable Automatic Rebind of Renewed Certificate” 

Technical References/Related Articles:

Renew Web Server (SSL) Certificates automatically
http://blogs.technet.com/b/pki/archive/2013/08/27/renew-web-server-ssl-certificates-automatically.aspx

Certificate Rebind in IIS 8.5
http://www.iis.net/learn/get-started/whats-new-in-iis-85/certificate-rebind-in-iis85

CA manager approval required for certificate re-enrollment
http://blogs.technet.com/b/pki/archive/2011/03/08/ca-manager-approval-required-for-certificate-re-enrollment.aspx

Hey Everyone, This is Wes Hammond with Premier Field Engineering back to share what I have learned about protecting digital certificates using the Trusted Platform module in Windows desktops, laptops and servers. This is part one of a three part series that will include the Microsoft Platform Crypto Provider, Virtual Smart Cards, and lastly the Key Attestation feature included in Windows Server 2012 R2 and Windows 8.1. So getting on to part 1: Microsoft Platform Crypto Provider. Let's start off with, why should I use this? The answer is, using a Trusted Platform Module to protect private keys provides higher security assurances. It accomplishes this with the following:

Non-Exportability: The certificate template will only allow the Microsoft Platform Crypto Provider to be selected if the "Allow private key to be exported" option is not checked in the request handling tab. Thus, private keys protected by the TPM are not exportable.

Anti-Hammering: When used in conjunction with passwords or PINs a TPM will lock out if a pin or password is entered incorrectly too many times.

Key Isolation: Private keys protected by the TPM are never exposed to the operating system or malware. All private key operations are handled within the TPM.

For more information see the following related article:

TPM Fundamentals – http://technet.microsoft.com/en-us/library/jj889441.aspx

Assumptions

This article assumes the individual has a basic understanding of Microsoft PKI and its components.

Microsoft CA configuration:

Requirements:

*Note: The Microsoft Platform Crypto Provider only requires Windows 8 and Windows Server 2012. However Windows 8.1 and Windows Server 2012 R2 are required for key attestation which will be covered in part 3 of this series. So for the sake of this exercise I will be leveraging Windows 8.1 and Windows Server 2012 R2 for the client and CA server operating systems

• A domain controller running Windows Server 2003 or later
• An enterprise certificate authority running Windows Server 2012 R2
• A desktop or laptop with a TPM, running Windows 8.1

Certificate Template Configuration:

• Open the Certificate Templates Console – certtmpl.msc
• Duplicate the certificate template of your choice. For this exercise we will use the Workstation Authentication template.
• On the Compatibility tab set the Certificate Authority to Windows Server 2012 R2 and Certificate recipient to Windows 8.1/Windows Server 2012 R2.

  *Note: Windows 8.1 and Windows Server 2012 R2 are only required for key attestation. We will reuse this template in part 3 for this purpose. If your CA and client are Windows 8 and Windows Server 2012 you can still complete this exercise. If this is the case simply choose Windows 8/Windows Server 2012 in the compatibility settings.

• Click on the General Tab and give the template a name.
• Click on the Cryptography tab
• Change the Provider Category to Key Storage Provider
• Select Requests must use one of the following providers:
• Check the box for Microsoft Platform Crypto Provider. *Note: If this provider is not listed check the request handling tab and make sure the" Allow private key to be exported" option is not checked.
• This step is optional: Click on the Request Handling tab
• Check the option to Renew with the same key *Note: This option ensures the renewed certificate maintains the same assurance levels as that of the original request.
• Click Apply and OK.
• Open the Certificate Authority MMC – cert
• Right click on the Certificate Templates container and select new, certificate template to issue.
• Click on the certificate template you created and click OK.

Issue End Entity Certificate

These next steps require a domain account with local administrator rights.

• Log onto the desktop or laptop Windows 8.1
• Open the local computer certificate store – certlm.msc
• Right click the Personal container and select All Tasks, Request New Certificate
• Click Next on the Before You Begin screen
• Click Next on the Select Certificate Enrollment Policy screen
• Check the box for your new certificate template and click Enroll
• Select Finish

To verify the certificate use the following command

Certutil -csp "Microsoft Platform Crypto Provider" -key

Related Links

TPM Platform Crypto-Provider Toolkit
http://research.microsoft.com/en-us/downloads/74c45746-24ad-4cb7-ba4b-0c6df2f92d5d/default.aspx

Hey Everyone, I am back with part 2 of this 3 part series on TPM protected certificates.  The topics covered in this are related to Virtual Smart Cards, their benefits, and lastly their limitations.  I will also cover how to create a Virtual Smart Cards.  Management of certificates contained on the virtual smart card are similar to those of a traditional smart card are not covered in this article.

Virtual Smart Cards function very similarly to conventional Smart Cards.  The difference is the private key is protected by the TPM and not the smart card media.  The Virtual smart card emulates a smart card and reader so the device presents itself to operating system and applications as a traditional smart card.  As for the storage of the private key, this is handled similarly to that of a key protected by the Microsoft Platform Crypto Provider.  The private key is encrypted and stored on the file system.

Virtual Smart Cards offer the following similarities with traditional Smart Cards.

Non-Exportability:  Since the private key is encrypted by the TPM is cannot be used on any other device.

Anti-Hammering:  The TPM will lockout if a pin is entered incorrectly too many times.  This behavior is manufacturer specific.

Key Isolation: Private keys protected by the TPM are never exposed to the operating system or malware.  All private key operations are handled within the TPM.

For more information see the following related article:

TPM Fundamentals – http://technet.microsoft.com/en-us/library/jj889441.aspx

Lab Configuration

Assumptions

This article assumes the individual has a basic understanding of Microsoft PKI and its components.

Prerequisites

•A domain controller running Windows Server 2003 or later*
•An enterprise certificate authority running Windows Server 2012 R2
•A desktop or laptop with a configured TPM, running Windows 8.1

*In order to process Smart Card logons.  Domain Controllers must obtain a certificate based on the Domain Controller Authentication certificate template.

Virtual Smart Card Creation

In this section we will create a virtual smart card on the Windows 8.1 laptop or laptop.  Creating a virtual smartcard is not a difficult task however there are a few ways of doing it.  The easiest method is using the command line utility TPMVSCMGR.EXE.

To create a virtual smartcard from the command line use the following command.  Note: You must have admin rights on the host and the command line must be (run as admin).

Tpmvscmgr.exe create /name “TestVirtualSC” /pin prompt /adminkey default /generate

You should be prompted to enter a pin, enter a pin of your choosing then re-enter it to confirm.

Before we go further let’s take note of what this will actually do.

Create: This is pretty self-explanatory.  We are creating a virtual smartcard here.

/name: This is the name that will be given to the device you will see in Device Manager (see below)

/pin: This is the pin that unlocks the virtual smart card.  Similar to physical smartcard but protected by the TPM anti-hammering feature.

/adminkey: the admin key that you are assigning to the virtual smart card.  Admin keys are used for management purposes.

After the virtual smartcard creation it can be treated just like a traditional smart card by using the “Microsoft Base Smart Card Crypto Provider” or “Microsoft Smart Card Key Storage Provider”.

Smart Card Logon Certificate Template

In this section we will create the certificate template to be used for smartcard logon.  This template will be configured to leverage the “Microsoft Smart Card Key Storage Provider”.  So unless a physical or Virtual Smart Card is present the user will not be able to enroll for this type of certificate.  Before we get started I want to note a few things.

1. Creating this template will require Enterprise Admin rights unless you have delegated access to the templates by using one of the steps defined in this article: http://technet.microsoft.com/en-us/library/cc725621(v=WS.10).aspx

2. The template settings defined here should not be used in a production environment.  Obtaining a certificate that can be used for smart card logon should not be easy.  Processes should be put into place to ensure these types of certificates are procured in a secure manner (Issuance Policies), especially if they are to be used for non-repudiation.  See the last section in this document “Further Considerations” for more info.

Now that this stuff is out of the way…

From the Enterprise Certificate Authority.

• Open the Certificate Templates Console – certtmpl.msc,

• Duplicate the Smartcard Logon certificate templates

• On the Compatibility tab set the Certificate Authority to Windows Server 2012 and Certificate recipient to Windows 8.1/Windows Server 2012 R2

  *Note: Windows 8.1 and Windows Server 2012 R2 are only required for key attestation.  We will reuse this template in part 3 for this purpose.  If your CA and client are Windows 8 and Windows Server 2012 you can still complete this exercise.  If this is the case simply choose Windows 8/Windows Server 2012 in the compatibility settings.

•  Click on the General Tab and give the template a name.

• Click on the Cryptography tab

  • Change the Provider Category to Key Storage Provider

  • Select Requests must use one of the following providers:

    • Check the box for Microsoft Smart Card Key Storage Provider.

• Click Apply and OK.

• Open the Certificate Authority MMC – certsrv.msc

• Right click on the Certificate Templates container and select new, certificate template to issue.

• Click on the certificate template you created and click OK.

Enrolling for a Smart Card Logon Certificate

After your Virtual Smart Card and Smart Card Logon Template has been created now we are ready to enroll for a certificate.

• Open CertMgr.msc

• Right click on the Personal container -> all tasks -> Request New Certificate

• Certificate Enrollment Wizard

  • On the “Before You Begin” page click Next

  • On the Select “Certificate Enrollment Policy” page Active Directory Enrollment Policy is the default.  Click Next

  • Choose the certificate template you created by filling the checkbox to its left and click Enroll

  • Click Finish

That’s it.  We now have a Virtual Smart Card and a certificate for Smart Card Logon.  We are ready to use it to log in.

Logging In/User Experience

 Before I get started on the next section.  Sorry for the low res pictures

Now what we have everything we need to log in.  What will your users see?  Users will see the familiar interface but there will be a new link below: Sign-in options

Clicking on Sign-in options reveals the following.

 The first is the icon that looks like a key, this is the username/password option.  Do I need to explain this any further?  I hope not.

This is the one we are interested in.  The icon that looks like an IC or chip.  Clicking on this changes the box above to state “Security Device” and the place you would typically put your password says PIN now.  Hmmm…… where did I see that PIN before, oh yeah when we created the Virtual Smart Card.  I hope you remember what you set it to.  Enter the PIN you used when you created the Virtual Smart Card.  Viola!  Smart Card Logon.

Changing Virtual Smart Card PIN

In this last section I will show you how to change a PIN for a Virtual Smart Card.

While logged in using the Virtual Smart Card press Ctrl+Alt+Del and select the option to “Change a password”.  Enter the old PIN, the new PIN then confirm.  That’s it.

Further Considerations

Issuance Policy/Enrollment Requirements

It is important to give consideration as to why you are implementing Virtual Smart Cards.  Most organizations choose to issue Smart Cards or Virtual Smart Cards to strengthen security.  Smart card logon achieves this by requiring the user to have their physical smart card and the associated PIN in order to logon.  Virtual Smart Cards are very similar.  The user must have the TPM enabled device, and know the PIN. 

Additional considerations should be given for enrollment for a virtual smart card.  Much as that of traditional Smart Cards a username and password should not be the only factor to obtain one.  Your organization may determine that someone needs to enroll in person and/or provide positive ID, fill out forms or other requirements.

Shared Devices/Computers

It is possible to have more than one Virtual Smart Card on a device.  If you do have a requirement to have more than one the interface presents similar to what you see here:

User 1: Bob

User 2: Wes

I hope you all enjoyed this post on Virtual Smart Cards and I hope it assists you in your evaluation of this security related feature.  Again, this is part 2 of a 3 part series regarding protecting certificate private keys using Trusted Platform Modules.  I’ll be back really soon with part 3, Key Attestation in Windows Server 2012 R2 and Windows 8.1.

Technical Resources:

Understanding and Evaluating Virtual Smart Cards – http://technet.microsoft.com/en-us/library/dn578507.aspx

TPM Platform Crypto-Provider Toolkit – http://research.microsoft.com/en-us/downloads/74c45746-24ad-4cb7-ba4b-0c6df2f92d5d/default.aspx

Hey Everyone, I am back with the last part of this 3 of this series on TPM protected certificates.  The last topic for this series is on Key Attestation.  Recently I have had a few people ask me about the Key Attestation tab in Windows Server 2012 R2.  Another person informed me they tried to set it up, and it didn’t work.  That’s not cool.  I hadn’t used the feature before so I decided to take a dive into it and maybe I could help y’all out.  Here is what I found.  First, what is this for?  Key Attestation is an assurance mechanism.  It validates the private key in a certificate key pair are protected via a TPM.  If you don’t know what the big deal is about protecting keys via TPM please see part 1 and part 2 of this series.  Depending on how the key is being protected, the CA can also insert Issuance Policy OID’s into a certificate based on what attestation method was used.

The 3 methods used for Key Attestation are:

User Credentials: (Low Assurance) Issuance Policy/Certificate Policy OID: 1.3.6.1.4.1.311.21.32 – The user provides an EKPub to the enterprise CA.  The enterprise CA performs no further validation.

Endorsement Certificate: (Medium Assurance) Issuance Policy/Certificate Policy OID 1.3.6.1.4.1.311.21.31 – The TPM has a manufacturer supplied certificate embedded.  The Enterprise CA validates the EKCert chain.  All CA’s in the chain must be trusted.  This method also means that ALL TPM’s from the manufacturer’s chain are trusted.

Endorsement Key: (High Assurance) Issuance Policy/Certificate Policy OID: 1.3.6.1.4.1.311.21.30 – The Enterprise CA validates each EKPub provided against an administrator defined list of allowed EKPub.  The list is contained in a directory that includes files named for each EKPub SHA-256 hash.

Assumptions

This article assumes the individual has a basic understanding of Microsoft PKI and its components.

Microsoft Lab Configuration

Requirements:

1. A domain controller running Windows Server 2003 or later
2. An enterprise certificate authority running Windows Server 2012 R2
3. A desktop or laptop with a enabled and configured TPM, running Windows 8.1
4. You have completed the labs from part 1 of this series.  (We will be leveraging certificate templates you created from part 1)

Configuring and Testing User Credential Attestation:

This option only requests the client send an EKPub to the Enterprise CA.  There is no further validation other than the user’s domain credentials (low assurance).

Step 1: Certificate Template Configuration

In this section we will modify the template we configured in Part 1 of this 3 part series to perform key attestation and insert issuance policies.

1. Open the Certificate Template Console (certtmpl.msc)

2. Modify the Workstation Authentication Template you created in Part 1 of this series

3. Verify the following:

   • Compatibility Tab

     • Certificate Authority: Windows Server 2012 R2

     • Certificate Recipient: Windows 8.1/Windows Server 2012 R2

   • Cryptography Tab

     • Provider Category: Key Storage Provider

     • Requests must be from one of the following providers: Check only Microsoft Platform Crypto Provider

4. New Settings:

   • Request Handling

     • Renew with the same key: cleared/unchecked

   • Key Attestation Tab

     • Key Attestation: Required

   • Attestation Type

     • User Credentials

   • Issuance Policies for key attested certificates

     • Include issuance polices for enforced attestation types

Result: Certificates requested from the template should resemble the following

Configuring and Testing Endorsement Certificate Attestation:

This option makes use of the certificate some manufacturers burn into their TPM’s.  Notice I said some, not all manufacturers are doing this.  The next fun thing about this one is, depending on the manufacturer you have to go chase them down to get copies of the public keys for all the CA’s in their chain and import those certificates into special containers on your CA.  The good thing about this is, after you do it all of the TPM enabled devices that chain to those certificates are trusted for attestation.

Let’s get started on setting this up.

Step 1: Who made my TPM and do I have an EKCert?

From the Windows 8.1 device that has a TPM.

1. Open PowerShell as an Admin.
2. Run the following cmdlet: Get-TPMEndorsementKeyInfoyou should get an output similar to that seen below.  Sorry I had to block out a bunch of stuff but you should get the point.  From here we can see the certificate information for the EKCert (if you have one)

3. Now the fun part.  Visit the manufacturer’s site and pray they publish these certificates there and you can find them.  If not, you will have contact them and ask nicely.  Mine was the latter.

Step 2: Importing the Manufacturer Certificates to be used with Attestation

Now that the manufacturer has given us the public keys we can go ahead and import them into special containers in the local machine store so they can be used for attestation purposes.

Some of this is from the TechNet Article: TPM Key Attestation.  So a big thanks to the folks that wrote this.

The following commands will create the EKCert containers for the manufacturer’s certificates.

These commands will create the following certificate containers in the local machine store:

After you create the containers you will need to import the manufacturer’s certificates to the proper containers.

Now we can configure your certificate template for Endorsement Certificate attestation.

Step 3: Certificate Template Configuration

1. Open the Certificate Template Console (certtmpl.msc)

2. Modify the Workstation Authentication Template you created in Part 1 of this series

3. Verify the following:

   • Compatibility Tab

     • Certificate Authority: Windows Server 2012 R2

     • Certificate Recipient: Windows 8.1/Windows Server 2012 R2

   • Request Handling

     • Renew with the same key: cleared/unchecked

   • Cryptography Tab

     • Provider Category: Key Storage Provider

     • Requests must be from one of the following providers: Check only Microsoft Platform Crypto Provider

4. New Settings:

   • Key Attestation Tab

     • Key Attestation: Required

   • Attestation Type

     • Endorsement Certificate

   • Issuance Policies for key attested certificates

     • Include issuance polices for enforced attestation types

Result: Certificates requested from the template should resemble the following

Configuring and Testing Endorsement Key Attestation:

This process takes the most administrative effort and thus provides the highest level of assurance.  With this method our goal is to populate a folder, either locally or network, with empty files.  The names of the files are the sha256 hash of the TPM endorsement keys for the devices in your organization you want to perform attestation.

Step 1: Identifying the TPM Hash

For this we are going to use a sample PowerShell script that I made using the one in the Technet article for a reference (with a few tweaks of courseJ).

Step 2: Adding the EKPub Hash Folder to the Issuing CA

Now that we have an EKPub hash file in the folder we need to have the CA recognize this folder as a repository. Remember, the CA machine account needs to have read permissions on this folder so if it’s local that’s no big deal.  But since mine is on a network share I needed to configure this on the NTFS and share permissions.

1. We are going to run this command to add the folder as an Endorsement Key List Directory, there is currently no method to do this through the GUI

   certutil.exe -setreg CA\EndorsementKeyListDirectories +\\con-lab-dc01\EKPub$

   Alternatively you can run certutil.exe -setreg CA\EndorsementKeyListDirectories -\\con-lab-dc01\EKPub$ to remove a directory

2. Now we need to restart the CA services for the change to take effect.  You can choose your favorite method I am going to use the command line.

   net stop certsvc & net start certsvc

Step 3: Certificate Template Configuration

1. Open the Certificate Template Console (certtmpl.msc)

2. Modify the Workstation Authentication Template you created in Part 1 of this series

3. Verify the following:

   • Compatibility Tab

     • Certificate Authority: Windows Server 2012 R2

     • Certificate Recipient: Windows 8.1/Windows Server 2012 R2

   • Cryptography Tab

     • Provider Category: Key Storage Provider

     • Requests must be from one of the following providers: Check only Microsoft Platform Crypto Provider

4. New Settings:

   • Request Handling

     • Renew with the same key: cleared/unchecked

   • Key Attestation Tab

     • Key Attestation: Required

   • Attestation Type

     • Endorsement Key

   • Issuance Policies for key attested certificates

     • Include issuance polices for enforced attestation types

Result: Certificates requested from the template should resemble the following

Technical Resources:

Processing Rules for Key Attestation Based on a Trusted Endorsement Key
http://msdn.microsoft.com/en-us/library/dn410471.aspx

Get-TPMEndorsementKeyInfo
http://technet.microsoft.com/en-us/library/dn449037.aspx

TPM Key Attestation
http://technet.microsoft.com/en-us/library/dn581921.aspx

TPM System Fundamentals Testing Prerequisites
http://msdn.microsoft.com/en-us/library/windows/hardware/dn247549.aspx

TPM Attestation Test
http://msdn.microsoft.com/en-us/library/windows/hardware/hh998296.aspx

Links to part 1 and 2 of this 3 part series are below:

Part 1: Microsoft Platform Crypto Provider
Part 2: Virtual Smart Cards

Setting up NDES using a Group Managed Service Account (gMSA)

Hallo everybody, this is Andy and Dagmar from Austrian Premier Field Engineering (PFE) describing how to implement NDES using a gMSA (instead of a normal domain user account).

When creating a lab on how to implement NDES (Network Device Enrollment Service) on Windows Server 2012 R2, we decided to go for gMSA to be more secure and to get rid of monolithic service accounts that could be misused. Unfortunately it turned out that it was not as straight forward as we expected and we decided to write down the steps and publish them.

Why all the effort? NDES works like a charm when installed with default settings… The answer is short and simple: Security. NDES acts as a registration authority for a CA thereby leveraging the Simple Certificate Enrollment Protocol (SCEP). Because of the way this protocol was designed, the CA has to fully trust the NDES regarding the verification of incoming certificate requests. The result of this design is that the NDES owns an extremely powerful type of certificate (Exchange Enrollment Agent (Offline request) by default) which allows NDES to request certificates with almost any subject from the CA. Therefore, putting as much effort as possible into securing NDES absolutely makes sense.

Be aware that the whole process of securing NDES should comprise a bunch of measures (e.g. enrolling the NDES certificates to a HSM) and that using a gMSA to run it, is only one of the recommended hardening steps. Please refer to this whitepaper focusing on NDES security: http://www.microsoft.com/en-us/download/details.aspx?id=46406&WT.mc_id=Blog_Intune_General_PCIT

Group Managed Service Accounts

(Standalone) Managed Service Accounts were introduced in Windows Server 2008 R2 and are managed domain accounts that provide automatic password management and simplified SPN management, including delegation of management to other administrators but limited to only one server. Group Managed Service accounts were introduced with Windows Server 2012 and provide the same functionality within the domain but also extend their availability to multiple servers.

From the security as well as from the manageability perspective, gMSA are the preferred way to configure services wherever it is supported to use them. For more details regarding gMSA, please refer to https://technet.microsoft.com/en-us/library/hh831782.aspx

NDES Accounts

When setting up NDES you have to decide in which security context the NDES application pool should run. From the NDES wiki (see http://social.technet.microsoft.com/wiki/contents/articles/9063.network-device-enrollment-service-ndes-in-active-directory-certificate-services-ad-cs.aspx#Permissions_Required_for_the_Network_Device_Enrollment_Servicefor more details) we learn that the NDES app pool account needs to fulfill the following requirements:

• Must be a member of the local IIS_IUSRS group.
• Must have request permission on the configured CA.
• Must be a domain user account and have Read and Enroll permissions on the configured templates.
• Must have SPN set in Active Directory.

All these requirements can be fulfilled by a gMSA, we simply need to configure the SCEP app pool to run in the security context of the gMSA, perform some additional steps and that’s it. But oooops, it wasn’t so simple then…

Configuration Steps

Many of the steps below are described in more detail in the NDES wiki. We are repeating them here in a summarized way in order to provide a complete guide of all steps required. Wherever gMSA specific steps are required, we describe them in detail.

Let’s assume the following parameters for our lab environment:

• NDES service account: NDESgMSA
• NDES server: ADCSWeb02.fabrikam.com
• Certification authority: CA02
• Web Server certificate (with proper subject and/or SANs set) enrolled to the NDES server

Prerequisites

• Forest prepared for gMSA usage (KDS Root Key created – https://technet.microsoft.com/en-us/library/jj128430.aspx)
• NDES Administrator account (out of scope of this post, see NDES wiki for details)
• NDES Device Administrator account (out of scope of this post, see NDES wiki for details)

Create and configure gMSA

1. Type the following command to create a new gMSA:

New-ADServiceAccount -name NDESgMSA -DNSHostName NDESgMSA.fabrikam.com -PrincipalsAllowedToRetrieveManagedPassword ADCSWEB02$

2. Then configure the gMSA on the NDES host machine:
a. To load the AD PowerShell RSAT feature, type: Add-WindowsFeature RSAT-AD-PowerShell
b. To install the gMSA on ADCSWEB02 type: Install-ADServiceAccount NDESgMSA
c. To verify if the gMSA has been configured properly, type: Test-ADServiceAccount NDESgMSA

Note: The answer has to be true, otherwise it does not make any sense to continue.

3. Next, add the NDESgMSA account to the IIS_IUSRSgroup on the NDES host machine.

Configure CA Security Settings and Templates

Note: we are assuming for easiness that you are going to use the default templates. We recommend using custom (version 2) templates in production as stated at http://social.technet.microsoft.com/wiki/contents/articles/9063.network-device-enrollment-service-ndes-in-active-directory-certificate-services-ad-cs.aspx#Setting_Up_New_Templates_for_the_Service_Certificates.

1. Grant Read and Enroll permissions on Exchange Enrollment Agent (Offline Request) template to NDESAdmin.
2. Grant Read and Enroll permissions on CEP Encryption template to NDESAdmin.
3. Grant Read and Enroll permissions on IPSec (Offline Request) template to NDESgMSA and DeviceAdmin.
4. Publish all three templates on the Certification Authority.

Install NDES

Unfortunately, the setup wizard does not provide support for running the NDES application pool in the security context of a gMSA. That’s why we are processing the installation using more or less the default settings.

1. On the NDES host machine, add the Network Device Enrollment Service as a role service for the Certification Authority role.
2. Once the installation has completed, click Configure Active Directory Certificate Services to continue with the configuration of NDEs.
3. On the Credentials screen, ensure that the NDES Admin account (which was created as part of the prerequisites) is selected.
4. On the Role Service page, select Network Device Enrollment Service and click Next.
5. On the Specify the service account page, select Use the built-in application pool identity. Click Next.
6. On the Specify CA for Network Device Enrollment Service page, click Select. On Select Certification Authority, select the CA you are going to use with this NDES installation and click OK > Next.
7. On the Type the requested information to enroll for an RA certificate page, click Next.
8. On the Configure CSPs for the RA page, click Next.
9. Finally, click Configure.

Alternatively, using the famous PowerShell:

Add-WindowsFeature Adcs-Device-Enrollment -includeManagementTools

Install-AdcsNetworkDeviceEnrollmentService -ApplicationPoolIdentity -CAConfig "CA02.fabrikam.com\FabrikamIssuingCA" -RAName "Fabrikam NDES RA" -RACountry "DE" -RACompany "Fabrikam" -SigningProviderName "Microsoft Strong Cryptographic Provider" -SigningKeyLength 2048 -EncryptionProviderName "Microsoft Strong Cryptographic Provider" -EncryptionKeyLength 2048

Post-Installation IIS Configuration

1. Open Internet Information Service (IIS) Manager.
2. Configure a binding for https using the host name and Server Name Indication (SNI)
   Note: On Windows Server 2012, IIS supports Server Name Indication (SNI), which is a TLS extension to include a virtual domain as a part of SSL negotiation. What this effectively means is that the virtual domain name, or a hostname, can now be used to identify the network end point. This allows IIS to share IP addresses among SSL websites. However, it should be noted that if this feature is enabled, clients (in this case the mobile device itself or the MDM (Mobile Device Management Tool) not ready for SNI will not be able to contact NDES. Find more details about SNI at http://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-server-name-indication-sni-ssl-scalability
3. Change SCEP application pool identity to the gMSA
   

   Note that the NDES application pool is named “SCEP application pool” in IIS.

4. Change ISAPI Handler order:
   Note: The following steps are described in https://support.microsoft.com/en-us/kb/2800975
   If you do not configure IIS in the way described by the knowledge base article mentioned above, your NDES installation will work upon first testing. But later you will find out that the device administrator role is unable to request a challenge password at the mscep_admin site (unless being added to the Enterprise Administrators group).

   a. Still in IIS MMC, select the Default Web Site.
   b. Click View Applications on the Actions pane on the right side.
   c. Double-click Handler Mappings on the middle pane.
   d. On the Actions pane, click View Ordered List…
   e. On the Details pane in the middle, select ExtensionlessUrlhandler-ISAPI-4.0_64bit and click Move Down. Click Yes to move it below the StatifFile item.
   

   f. Repeat steps a to f for the /Certsrv/mscep_admin application.
   g. Restart IIS by typing iisreset on an elevated command prompt.

5. Configure permissions on private keys
   Note: again, we assumed for easiness that you are going to use the default templates. If you followed our recommendations and prepared custom templates instead, you can skip this step.
   During the initial configuration of NDES, two certificates were requested in the security context of the NDES Admin (account used to install NDES role service) and permissions on the corresponding keys were configured for the built-in app pool identity. However, we need to configure permissions to the keys for the gMSA:

   a. Open local computer certificate store (certlm.msc) on the NDES machine
   b. Right-click the CEP Encryption certificate, select All Tasks > Manage Private Keys
   c. Add the NDESgMSA account and add the Read permission.
   d. Repeat the steps a – c for the Exchange Enrollment Agent (Offline) certificate.
   e. Restart IIS by typing iisreset on an elevated command prompt.

   Additional Comments

   Starting with Windows Server 2012 R2, NDES supports policy module integration which can provide additional security for the SCEP. This enhancement lets an organization or mobile device management solution address the issue described in CERT Vulnerability Note VU#971035 “Simple Certificate Enrollment Protocol (SCEP) does not strongly authenticate certificate requests.” See http://www.kb.cert.org/vuls/id/971035for more details on this vulnerability.

   Find more details about the NDES Policy Module support at https://technet.microsoft.com/en-us/library/dn473016.aspx