NEW The SHA1 Deprecation Policy is listed below under the Section "Algorithm Policies".

Return to Windows Root Certificate Program Main Page







The Technical Requirements version 1.1 have been superseded by this version 2.0.  Version 1.1 is preserved here for information and reference only.







Last Updated November 11, 2013

New root certificates must meet the following technical requirements. Additional requirements apply to Intermediate, Issuing Certificate Authority (CA) and End-Entity certificates as described in those sections.

 

ROOT CERTIFICATES

Root certificates must be x.509 v3 certificates.

Basic Constraints extension: cA=true [1]

Root CA Organization Name must appear in the Root Certificate



Subject Name in any CA certificates (root or intermediate) must contain the name of the organization that operates the CA at the time of issuance.

Unique Private Keys and Subject Names per root certificate



Private Keys and subject names must be unique per root certificate: reuse of private keys or subject names in subsequent root certificates by the same CA may result in random certificate chaining issues.  CAs must generate a new key and apply a new subject name when generating a new root certificate prior to distribution by Microsoft. [2]

Number of Root Certificates Distributed by the Program



CAs may request distribution of three (3) root certificates per “CA Brand”[3] and algorithm type supported by Windows – SHA1, SHA2, RSA, and ECDSA.  CAs may also designate three (3) root rollover certificates for distribution by Windows to replace roots periodically.

KEY SIZES

Root certificates must meet the following minimum key size requirements:

 

Algorithm

All Uses Exception for Code Signing and Time stamping

Code Signing and Time stamping Use

Digest Algorithms

SHA1 (until 1 Jan 2016)[4]



SHA2 (SHA256, SHA384, SHA512)

SHA1 (until 1 Jan 2016)[5]



SHA2 (SHA256, SHA384, SHA512)[6]

RSA

2048

4096 (New roots only)

ECC / ECDSA

NIST P-256, P-384, P-521

 

 

In accordance with prior Program technical requirements and NIST Guidance (SP 800-57 Part 1), Program CAs must already rely on RSA root certificates with minimum RSA 2048-bit modules or ECC equivalent (P256). 

Root certificates with code signing use must be a minimum RSA 4096-bit modulus or ECC equivalent (P384).  Root certificates with other uses must be a minimum RSA 2048-bit modulus or ECC equivalent (P256).

Root Key Expiration



The estimated algorithm security lifetime of RSA 2048 or ECC equivalent is the year 2030.  RSA 2048 root certificates should expire by 2030.  RSA 2048 root certificates with longer expiration can expect to be removed from distribution no later than 2030.

Root certificates must expire no more than 25 years after the date of application for distribution.

Key uses

Root certificate Key Usage (if present): keyCertSign and cRLSign

Code Signing Root Certificates



New code signing root certificates must support the SHA2 hash algorithm. [7]

Removing Root Certificates replaced by root rollover



Root certificates that support other uses besides code signing will be removed from distribution by the Program 6 to 12 months from the date of distribution of a replacement rollover root certificate.  CAs that expect to have unexpired end-entity certificates still chaining to root certificates after 6-12 months must apply to Microsoft for an extended root removal date before distribution of a rollover root certificate.

Root certificates that support code signing use will be removed from distribution by the Program 10 years from the date of distribution of a replacement rollover root certificate, or a shorter deadline on request of the CA.

Root certificates that support a combination of code signing use with any other use will be removed from distribution by the Program 10 years from the date of distribution of a replacement rollover root certificate, or a shorter deadline on request of the CA.

Root certificates that remain in distribution to support only code signing use beyond their algorithm security lifetime (e.g. RSA 1024 = 2014, RSA 2048 = 2030) will be limited to code signing use only. Additional EKUs may be removed at the end of their algorithm security lifetime.

CAs should plan to cease issuing end entity certificates for uses besides code signing such that those certificates expire according to these root removal guidelines.  Root certificates will be removed from distribution by the Program according to these deadlines without regard to any unexpired end entity certificates issued from them. 

EXTENDED KEY USES (EKUs)

Each root certificate will be associated with a minimum set of EKU Object Identifiers (OIDs) to enable the supported product or business scenario.

The following is a list of EKUs allowed to CAs.

Server Authentication =1.3.6.1.5.5.7.3.1

Client Authentication =1.3.6.1.5.5.7.3.2

Secure E-mail =1.3.6.1.5.5.7.3.4

Other EKUs may be granted if the CA is able to provide additional or specific justification:

Code Signing =1.3.6.1.5.5.7.3.3 (see Explanatory Note for qualifying your root for the code signing EKU)[8]

Time stamping =1.3.6.1.5.5.7.3.8

OCSP =1.3.6.1.5.5.7.3.9  (see Explanatory Note for qualifying your root for the OCSP EKU)[9]

Encrypting File System =1.3.6.1.4.1.311.10.3.4

IPsec (Tunnel, User) =1.3.6.1.5.5.7.3.6, 1.3.6.1.5.5.7.3.7

Document Signing = 1.3.6.1.4.1.311.10.3.12

CAs must provide a business justification for all of the EKUs assigned to their root certificate.  Justification may be in the form of public evidence of a current business of issuing certificates of a type or types, or a business plan demonstrating an intention to issue those certificates in the near term (within one year of root certificate distribution by the Program). 

Certificate issuance practices will be reviewed periodically and assignment of an EKU may be removed or suspended if the CA is not actively issuing that certificate type according to business justification or plan.

A number of EKUs are deemed ineligible for use by root certificates distributed by the Program.  Please see the Explanatory Note for details. [10]

 

 

 

INTERMEDIATE / ISSUING CA CERTIFICATES

Intermediate CA certificates are excluded from distribution in the Windows Root Certificate Program.   

KEY SIZES

Intermediate CA certificates must meet the requirements for algorithm type and key size for Subordinate CA certificates listed in Appendix A of the CAB Forum Baseline Requirements, e.g. https://www.cabforum.org/Baseline_Requirements_V1_1_5.pdf.

 

Intermediate CA certificate key sizes smaller than RSA 2048 or ECC equivalent may be blocked from operation in Windows without notice in the near future.

EXPIRATION

{reserved}

Key uses

Separation of SSL and Code Signing Key Uses

Intermediate CA certificates under root certificates submitted for distribution by the Program must be configured to separate server authentication (SSL) from code signing and time stamping uses. A single issuing CA must not be used to issue both server authentication and code signing certificates.

Rollover root certificates will not be accepted that combine server authentication with code signing uses unless the uses are separated by application of EKUs at the intermediate CA certificate level that are reflected in the whole certificate chain.[11]

Code Signing Intermediate CA Certificates



It is recommended that CAs should operate a timestamp server authority (TSA) in conjunction with their code signing service, and as a best practice request that their customers timestamp the digital signature after signing their code.  The TSA must comply with RFC 3161, “Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP).” 

EXTENDED KEY USES

{reserved}

 

 

 

END-ENTITY CERTIFICATES

Revocation Information for End Entity Certificates (OCSP)



Online Certificate Status Protocol (OCSP) must be used to provide certificate revocation information for end entity certificates. The URL for the OCSP service must be specified in the Authority Information Access (AIA) extension.

Random Values in End Entity Certificates



For all end-entity certificates, the contents of the serialNumber field must include at least 8 bytes of entropy obtained from a FIPS 140 approved random number generator (note that the default configuration of Active Directory Certificate Services in Windows Server 2012 or later already meets this requirement).

The serialnumber field inside the Subject Name may be used provided it is positioned before all other fields in the subject name.

CAs are no longer allowed to place entropy into the Date fields. [12]

KEY SIZES

End-entity certificates must meet the requirements for algorithm type and key size for Subscriber certificates listed in Appendix A of the CAB Forum Baseline Requirements, e.g. https://www.cabforum.org/Baseline_Requirements_V1_1_5.pdf.

EXPIRATION

{reserved}

Key uses

End Entity certificates that allow both code signing and server authentication EKUs are prohibited. (See the section on Intermediate / Issuing CA Certificates, Key Uses, Separation of SSL and Code Signing Key Uses).

 

 

 

algorithm policies

Currently Disallowed Algorithms and Key Lengths



The following algorithms and key lengths are no longer accepted in the Program.

MD2, MD4, MD5 (blocked by KB2862973)

RSA with keys smaller than 1024 bits (blocked by KB2661254)

RSA with keys equal to 1024-bits (may be blocked from operation in Windows without notice in the near future)

RSA 1024 Deprecation Policy



CAs who issue RSA 1024-bit certificates of any type with expirations beyond 31 December 2013 do so at their own risk.  RSA 1024 may be blocked from operation in Windows without notice in the near future.

Microsoft will remove from distribution most RSA 1024 root certificates in 2014.  RSA 1024 root certificates with code signing or time stamping uses may remain in distribution by the Program for an additional period on application of the CA.

SHA1 Deprecation Policy

There will be separate timelines for discontinuing SHA1-based SSL and code signing certificates.

  1. CAs must stop issuing new SHA1 SSL and Code Signing certificates by 1 January 2016.
  2. For SSL certificates, Windows will stop accepting SHA1 certificates by 1 January 2017. This means any SHA1 SSL certificates issued before or after this announcement must be replaced with a SHA2 equivalent by 1 January 2017.
  3. For code signing certificates, Windows will stop accepting SHA1 signed code and SHA1 certificates that are time stamped after 1 January 2016.  SHA1 signed code time stamped by an RFC 3161 Time Stamp Authority before 1 January 2016 will be accepted until such time when Microsoft decides SHA1 is vulnerable to pre-image attack.
  4. The Program will no longer accept for distribution new root certificates with code signing use supporting SHA1 or RSA 2048.  New code signing root certificates must support SHA2 and RSA 4096.[13]

For non SSL and Code Signing certificates, CAs should stop issuing SHA1 certificates by 1 January 2016. Microsoft reserves the right to update Windows to stop accepting SHA1 certificates on or after 1 January 2017.

 

 

Explanatory Notes



The following explanatory notes are meant to explain or to illustrate aspects of the technical requirements.  The technical requirements are part of the CA Agreement, not the explanatory notes. 



 


 

[1] BASIC CONSTRAINTS End-entity certificates must be identified with the Basic Constraints extension in accordance with IETF RFC 5280. If either the Basic Constraints extension is absent, or if the Basic Constraints extension is present, then the cA field must be set to FALSE and the pathLenConstraint field must be absent.

[2] UNIQUE PRIVATE KEYS AND SUBJECT NAME Windows may not detect which certificate chain you want to use if both chains use the same private key.  If presented with multiple valid chains, the heuristics used are documented in this blog post http://blogs.technet.com/b/pki/archive/2010/05/13/certificate-path-validation-in-bridge-ca-and-cross-certification-environments.aspx. When root certificates with identical keys and subject names are present on a Windows system, and the client attempts to build a valid certificate chain, it could pick either root depending on the Windows version and validity period of the certificates. While both roots are trusted, same keys for multiple certificates can result in problems for Windows users.  If a system is configured to require certificates to chain up to the SHA1 root and Windows picks the newer SHA2 root, then the applications relying on the older root would fail.   Avoid this by assigning a new private key and new subject name to every new root certificate prior to distribution by Microsoft.

[3] NUMBER OF ROOT CERTIFICATES DISTRIBUTED “CA Brand” refers to a separate root certificate hierarchy operated by a member CA by virtue of merger or acquisition with another existing CA.  CA Brand does not include separate certificate hierarchies created by a single member CA.  The purpose of this root requirement is not to penalize a CA for acquisitions or mergers that may take place in the CA industry.

Example.  Contoso CA operates as a CA selling SSL certificates issued from RSA root certificates.  They may distribute up to 3 root certificates per algorithm (RSA).  Contoso CA acquires another existing CA, Fabrikam, who also sells SSL certificates from RSA root certificates.  Contoso CA may now distribute its original 3 root certificates per algorithm for Contoso CA, and an additional 3 root certificates per algorithm for Fabrikam CA (total 6 root certificates).  In addition, Contoso may also distribute up to 3 root certificates per algorithm as root rollover certificates (for a total of 12 root certificates).

[4] KEY SIZES See the section on Algorithm Policies, SHA1 Deprecation Policy for additional information.

[5] KEY SIZES See the section on Algorithm Policies, SHA1 Deprecation Policy for additional information.

[6] KEY SIZES, CODE SIGNING New root certificates accepted by the Program with code signing use enabled may no longer support SHA1, but must support SHA2 and RSA 4096.

[7] CODE SIGNING ROOT CERTIFICATES See the section on Algorithm Policies, SHA1 Deprecation Policy for the reasoning for this requirement.  SHA1 must be deprecated no later than January 2017 and to meet that deadline no more SHA1 root certificates will be admitted to the Windows Root Certificate Program.

[8] QUALIFYING FOR THE CODE SIGNING EKU New root certificates submitted for distribution by the Program must be configured to separate server authentication (SSL) from code signing and time stamping uses at the intermediate certificate level.  See the description in the section on Intermediate Certificates, Key Uses, “Separation of SSL and Code Signing Key Uses.”

[9] QUALIFYING FOR THE OCSP EKU Microsoft may apply the OCSP EKU to root certificates distributed by the Program only in certain very narrowly defined circumstances known as the indirect OCSP signer model:

For OCSP responder certificates that are used to revoke certificates issued by the same issuing CA (e.g., they have the same issuer name and are signed with the same CA key), the OCSP responder certificate must have the OCSP EKU, but the OCSP EKU is exempt from the usual CryptoAPI (or “CAPI”) nested EKU semantics. That is, CAPI will honor the OCSP EKU in the OCSP responder certificate even if the chain goes up to a root that does not have the OCSP EKU enabled. This is also known as the CA delegated OCSP signer model.

For OCSP responder certificates that are used to revoke certificates issued by other CAs (either they are issued by different CAs under the same root, or under different roots), the OCSP responder certificate must have the OCSP EKU and the usual CAPI nested EKU semantics apply. That is, the chain including the root must have the OCSP EKU enabled. This is known as the indirect OCSP signer model.

For CAs who only support the CA delegated OCSP signer model, the OCSP EKU is not required by Windows.

[10] What EKUs are typically not assigned to root certificates?

The following EKUs do not fit the Program criteria or are no longer necessary:

Smart card logon

This is an enterprise only scenario, because Active Directory deployment is required and the root must be added to the NTAuth store in Active Directory. See the following KB article for details.



http://support.microsoft.com/default.aspx?scid=kb;en-us;Q281245

Digital rights

This EKU is obsolete. Windows Media DRM uses it own XML format for licenses and does not use X.509.

Qualified subordination

This EKU is obsolete and is ignored by Windows.

Key recovery

Enterprise scenario

File recovery

This EKU is obsolete and is ignored by the Windows Encrypting File System (EFS).

All application policies

We cannot grant “all usages” since this necessarily admits enterprise-only and other unacceptable EKUs

Directory service email replication

Enterprise scenario

Certificate request agent

Enterprise scenario

Key recovery agent

Enterprise scenario

CA encryption certificate

Enterprise scenario

 

[11] SEPARATION OF SSL AND CODE SIGNING USES Example 1.  Fabrikam CA issues SSL and code signing certificates, and wants to issue from a new or rollover root certificate.  The root certificate may be enabled with both the server authentication and code signing EKU, provided that their CPS adequately reflect that SSL certificates are issued from an intermediate CA with the server authentication EKU enabled, and code signing certificates are issued from a separate intermediate CA with the code signing authentication EKU enabled.

 

Example 2.  Contoso CA also sells SSL and code signing certificates.  Their certificate operations allow them to issue from separate root certificates (best practice).  One root certificate will be enabled for server authentication, and the other root will be enabled for code signing.

[12] RANDOM VALUES IN END ENTITY CERTIFICATES The application of serial numbers in certificates becomes critically important in mitigation of algorithm or key length attacks: while an algorithm or key size may be vulnerable to attack, a properly implemented random or pseudo-random value in the certificate can mitigate the effects of attack and give certificates greater security value, allowing a CA more time to roll to newer and more secure certificates.  Certificates found not to have a proper random or pseudo random value in attack scenarios may be subject to revocation by the CA, or if necessary Microsoft may disallow all certificates issued by the intermediate or root certificate from operation on Windows.

[13] SHA1 DEPRECATION POLICY Microsoft will give new consideration to the SHA deprecation deadlines in July 2015.  We will consider these among other conditions that may be prevalent at the time:

  • whether SHA1 is still considered resistant to pre-image attacks by the security community, and
  • whether a significant portion of the ecosystem is not capable of switching to SHA2. Third party legacy systems and embedded devices that cannot be upgraded to SHA1may be particularly susceptible.  We will continue to gather data on this portion of the ecosystem.



Return to the Microsoft Root Certificate Program Main Page