Windows Vista and Windows Server 2008 have a convenient user interface to create custom certificate requests. This is especially helpful since computer certificate enrollment through the web enrollment pages was discontinued from Windows Server 2008 and on.

If you want to create a custom certificate request, perform the following steps:

1. Start the Certificates MMC snap-in and expand the Personal – Certificates container in the left pane.

2. Right click the Certificates container and chose Create custom request from the context menu.

3. Click Next to accept the welcome page of the wizard.

4. If you have Enterprise CA connectivity in your Active Directory forest, you can chose from a list of available certificate templates and create the request based on a specific certificate template. If you want to be independent of any certificate template, select (No template) CNG key if the application can handle CNG keys. Else select the (No Template) Legacy Key instead. For more information on Cryptography Next Generation (CNG), see the documentation on MSDN. Click Next to continue.

5. To customize your certificate request click the little arrow next to the word Details in the Certificate Enrollment page.

6. Click the Properties button.

7. Use the dialog tabs to define the certificate properties.

8. After defining all certificate attributes, click OK.

9. Finally, specify a filename to save the offline certificate request and click Finish.

10. The pending certificate request appears in the Certificate Enrollment Requests container in the Certificates MMC snap-in until the offline request was accepted.

11. To verify the certificate request, double-click the pending request in the MMC snap-in. Alternatively use certutil [mycert.req] at a command-line where [mycert.req] is equal to the file that you saved in step 9.

12. To enroll for the certificate request, submit the request with certreq –submit. If no certificate template was selected in the wizard, it is required to specify one as command-line parameter. Also don’t forget the –config parameter to specify the name of the certification authority where you are enrolling from. The certreq command might look like the following example if the CA is accessible via DCOM:

certreq –config "myCAserver\myCAname" –submit –attrib "CertificateTemplate:User" mycert.req

If certreq is executed on a computer running Windows 7 or Windows Server 2008 R2, the following command leverages the new web enrollment protocol on a Windows Server 2008 R2 CA where DCOM access to the CA is not mandatory. The URL provided with the config command is configured at the CA and can be found out with the certutil -dump command:

certreq –config https://www.contoso.com/My-CES/service.svc/CEP –submit –attrib "CertificateTemplate:User" mycert.req

If the CA is only accessible via the web enrollment pages, you have to open the mycert.req file with Notepad and copy/paste it into the web enrollment pages.

13. To install the certificate once it was enrolled, accept the certificate. This will also remove the pending certificate request from the Certificate Enrollment Requests container. Use certreq -accept [certificatename.cer] to accept the certificate request.

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, if this 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!

During my work with a customer renewing their Issuing CA’s certificate based on the steps documented in this article, I discovered that the Request file generated couldn’t be located in the default location of %systemDrive% . The Issuing CA didn’t log any errors in the Event Log, nor did it post any error messages. I also searched for all files with the extension *.req on all drives, and still couldn’t find the file.

After some more research, I discovered that my customer changed the default location of the RequestFileName Registry Key during their installation to a drive that no longer exists on the CA. The location configured was a:\%1_%3%4.req. I followed these steps to fix this issue:

1. Start the Registry Editor
2. Navigate to HKLM\System\CurrentControlSet\Services\Certsvc\Configuration\<CASanitizedName>
3. Locate the Registry String RequestFileName
4. Change the value from a:\%1_%3%4.req to C:\%1_%3%4.req
5. Stop and Start the Certification Active Directory Certificate Services service

I was then able to create the Request File and submit it to the Offline Root CA to process it.

Windows Vista and Windows Server 2008 have a convenient user interface to create custom certificate requests. This is especially helpful since computer certificate enrollment through the web enrollment pages was discontinued from Windows Server 2008 and on.

If you want to create a custom certificate request, perform the following steps:

1. Start the Certificates MMC snap-in and expand the Personal – Certificates container in the left pane.

2. Right click the Certificates container and chose Create custom request from the context menu.

3. Click Next to accept the welcome page of the wizard.

4. If you have Enterprise CA connectivity in your Active Directory forest, you can chose from a list of available certificate templates and create the request based on a specific certificate template. If you want to be independent of any certificate template, select (No template) CNG key if the application can handle CNG keys. Else select the (No Template) Legacy Key instead. For more information on Cryptography Next Generation (CNG), see the documentation on MSDN. Click Next to continue.

5. To customize your certificate request click the little arrow next to the word Details in the Certificate Enrollment page.

6. Click the Properties button.

7. Use the dialog tabs to define the certificate properties.

8. After defining all certificate attributes, click OK.

9. Finally, specify a filename to save the offline certificate request and click Finish.

10. The pending certificate request appears in the Certificate Enrollment Requests container in the Certificates MMC snap-in until the offline request was accepted.

11. To verify the certificate request, double-click the pending request in the MMC snap-in. Alternatively use certutil [mycert.req] at a command-line where [mycert.req] is equal to the file that you saved in step 9.

12. To enroll for the certificate request, submit the request with certreq –submit. If no certificate template was selected in the wizard, it is required to specify one as command-line parameter. Also don’t forget the –config parameter to specify the name of the certification authority where you are enrolling from. The certreq command might look like the following example if the CA is accessible via DCOM:

certreq –config "myCAserver\myCAname" –submit –attrib "CertificateTemplate:User" mycert.req

If certreq is executed on a computer running Windows 7 or Windows Server 2008 R2, the following command leverages the new web enrollment protocol on a Windows Server 2008 R2 CA where DCOM access to the CA is not mandatory. The URL provided with the config command is configured at the CA and can be found out with the certutil -dump command:

certreq –config https://www.contoso.com/My-CES/service.svc/CEP –submit –attrib "CertificateTemplate:User" mycert.req

If the CA is only accessible via the web enrollment pages, you have to open the mycert.req file with Notepad and copy/paste it into the web enrollment pages.

13. To install the certificate once it was enrolled, accept the certificate. This will also remove the pending certificate request from the Certificate Enrollment Requests container. Use certreq -accept [certificatename.cer] to accept the certificate request.

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, if this 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!

During my work with a customer renewing their Issuing CA’s certificate based on the steps documented in this article, I discovered that the Request file generated couldn’t be located in the default location of %systemDrive% . The Issuing CA didn’t log any errors in the Event Log, nor did it post any error messages. I also searched for all files with the extension *.req on all drives, and still couldn’t find the file.

After some more research, I discovered that my customer changed the default location of the RequestFileName Registry Key during their installation to a drive that no longer exists on the CA. The location configured was a:\%1_%3%4.req. I followed these steps to fix this issue:

1. Start the Registry Editor
2. Navigate to HKLM\System\CurrentControlSet\Services\Certsvc\Configuration\<CASanitizedName>
3. Locate the Registry String RequestFileName
4. Change the value from a:\%1_%3%4.req to C:\%1_%3%4.req
5. Stop and Start the Certification Active Directory Certificate Services service

I was then able to create the Request File and submit it to the Offline Root CA to process it.

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

    

    

    

A fellow engineer at Microsoft, Roger Grimes, has published a great article on Implementing SHA-2 in ADCS.  You can read it at the link below:

http://social.technet.microsoft.com/wiki/contents/articles/31296.implementing-sha-2-in-active-directory-certificate-services.aspx

Update: This page has been removed.  For the most up to date information on the Microsoft SHA1 deprecation policy please see https://aka.ms/sha1

Hi there!

This is Tochi Ezebube with the Active Directory Certificate Services (ADCS) engineering team; I wanted to share some further details on how to write a custom policy module for the ADCS Network Device Enrollment Service (NDES) in Windows Server 2012 R2 and onwards.

Here it is: how-to-write-an-ndes-policy-module.

And here’s some general info on policy modules in NDES.

Let me know if you have any questions!

Tochi

Hey Everyone,

A little while back I posted this article to my own personal blog and it is getting some traction but it might get more here so I wanted to share it as these questions come up all the time.  I hope you enjoy it.

https://blogs.technet.microsoft.com/crypto/2016/01/27/https-inspection-and-your-pki-2/

Wes Hammond here from Premier Field Engineering.  It has been a while since I posted anything, but I wanted to step back into the spotlight to talk a little bit about something a few customers have been asking about lately.  How will Certificate Transparency affect their Active Directory Certificate Services environments?  Well, here are your answers…

Before we get started, here is a little bit of information about Certificate Transparency that is relevant to this article.  CT is being applied to certificate authorities that chain to a Public/Commercial Root Authority to detect fraudulent certificates used for HTTPS purposes.  Many public certificate authorities have already been reporting to the CT logging servers for some time now.  How it works is beyond the scope of this document and I would recommend you read the information located at the site linked to at the bottom of this article.

CT in Browsers

Google is scheduled to enforce CT in Chrome browsers on April 30^th 2018 for certificates issued after April 1^st 2018.

CT in Private PKI (CA's that DO NOT chain to a public Root)

I am going to start with the most common scenario.  Most of you have a private PKI within your organization that does not chain up to a public root.  In this scenario, CT will not affect your CA's.  Chrome browser uses Windows native CAPI to determine trusted chains.  Windows can differentiate between commercial/public CA chains and internal/private chains.  Since Windows has this ability, CT will not affect Private/Internal PKI chains.

CT in Certificate Chains that DO chain to public Root

"IF" your certificate authority chains up to a public root and you issue SSL/TLS/HTTPS certificates, CT may affect your PKI.  How it affects you is beyond the scope of this article, and I would recommend you consult your provider for more information.

Other Certificate Purposes

As I mentioned earlier, CT is only relevant to certificates used for HTTPS.  All other certificate purposes such as smartcard logon, code signing, document signing, SMIME, any many others are not visible through Chrome browsers and thus are not affected, so rest easy

For more information on Certificate Transparency see the official site on it here: https://www.certificate-transparency.org/

If you liked this blog please don't forget to rate it.

Hello all, Tochi Ezebube here again from the Active Directory Certificate Services engineering team.

Sometime back, we released support for the precertificate flow of Certificate Transparency v1 (RFC 6962) in Windows Server 2016 (https://support.microsoft.com/en-us/help/4093260/introduction-of-ad-cs-certificate-transparency). For this to work end-to-end, the component submitting the request to the ADCS CA must submit the returned precertificate to a suitable set of Certificate Transparency Logs using the RFC 6962 protocol, aggregate the results as a SignedCertificateTimestampList, and return it to the ADCS CA for X.509 issuance.

Since release, we’ve received a number of requests for sample code to speak the RFC 6962 protocol between the CA and the CT Logs. Here is an unofficial sample to get you started with precertificate submission. It is released as-is with the usual caveats.

Sample code:  https://msdnshared.blob.core.windows.net/media/2018/12/ADCS-CT-E2E-Sample.zip

Sample.sln code breakdown:

• SampleLibrary.csproj: library containing a simple ILogClient and implementation, which speaks the RFC 6962 protocol for adding certificates & precertificates, as well as preparing the SignedCertificateTimestampList object.
• ConsoleApp.csproj: simple console app illustrating an ADCS CA CT enrollment end-to-end, utilizing SampleLibrary.csproj for Certificate Transparency interactions.

To use:

1. Register your ADCS CA certificate's root with the CT Log to be used.
2. Enable the Certificate Transparency feature on your ADCS CA and restart the CA service as follows:
   1. certutil.exe -setreg CA\CertificateTransparencyFlags 0x1
   2. net stop certsvc
   3. net start certsvc
3. Open Sample.sln in Visual Studio.
4. Verify it builds.
5. Run ConsoleApp.exe passing in the ADCS CA config string and the CT Log URI, for example:
   1. ConsoleApp.exe {ServerName}\{CAName} https://ct.googleapis.com/testtube

Happy coding…

Tochi