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

Posts on this page:

Original URL:
Post name: Windows Server 2012 R2/IIS8.5 – Automatic Rebind of Renewed Certificates
Original author: Amerk [MSFT]
Posting date: 2014-04-28T13:41:00+00:00

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

Certificate Rebind in IIS 8.5

CA manager approval required for certificate re-enrollment





Original URL:
Post name: Constraints: what they are and how they’re used
Original author: Amerk [MSFT]
Posting date: 2014-03-05T14:01:00+00:00

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.


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.



Signature= "$Windows NT$"






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.


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


Universal Resource Identifiers (URI)


E-mail name and User principal name (UPN)

Email =

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:

Applying Naming Constraints


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.



Signature= "$Windows NT$"






_continue_ = "SubTree=Include&"

_continue_ = "UPN ="

_continue_ = "email ="

_continue_ = "DNS ="

_continue_ = "DIRECTORYNAME = DC=corp, DC=contoso, DC=com&"

_continue_ = "URL ="

_continue_ = "SubTree=Exclude&"

_continue_ = "UPN ="

_continue_ = "email ="

_continue_ = "DNS ="

_continue_ = "DIRECTORYNAME = DC=east, DC=corp, DC=contoso, DC=com&"

_continue_ = "URL ="


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.


Signature= "$Windows NT$"


Include = NameConstraintsPermitted

Exclude = NameConstraintsExcluded

Critical = True



email =


DIRECTORYNAME = "DC=corp, DC=contoso, DC=com"




email =



DIRECTORYNAME = "DC=east, DC=corp, DC=contoso, DC=com"


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


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.



Signature= "$Windows NT$"


Policies = AppEmailPolicy, AppCodeSignPolicy, AppClAuthPolicy, AppSeAuthPolicy



OID = ; Secure Email


OID = ; Code Signing


OID = ; Client Authentication


OID = ; Server Authentication


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


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

Original URL:
Post name: A novel method in IE11 for dealing with fraudulent digital certificates
Original author: Saboori Anoosh
Posting date: 2014-02-21T16:22:00+00:00

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 and 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 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.


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.


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




Original URL:
Post name: [CrossPost] Microsoft PKI OCSP Responder Now JITC Certified and Lab Setup Guide
Original author: Adam Stasiniewicz
Posting date: 2014-01-08T07:43:25+00:00

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:

Original URL:
Post name: Upgrade Certification Authority to SHA256
Original author: Amerk [MSFT]
Posting date: 2013-09-19T10:51:00+00:00

A common question in the field is about upgrading a certification authority running on Windows Server 2003 to use Crypto Next Generation (CNG) to support SHA256. CNG was introduced in Windows Server 2008 and higher operating systems, as a result,
an upgrade to the operating system is required. After upgrading the certification authority’s operating system, you will need to run
the following commands from an elevated command line window:

certutil -setregca\csp\CNGHashAlgorithm SHA256
net stop certsvc
net start certsvc

Make sure you are using a Key Storage Provider that supports SHA256 – for example the Microsoft Key Storage Provider- and then renewing the certification authority’s certificate.

If this proves to be too complicated, then you can simply issue certificates to clients using SHA256 even if the entire certification authority’s chain is signed with SHA1 certificates. The applications consuming the SHA256 certificates have to support the SHA256 signature on any given certificate in the chain.

Amer Kamal

Senior Premier Field Engineer