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]

 

 

 

 

audits

General

CAs must complete a Qualified Audit conducted by a Qualified Auditor annually, and submit audit results to Microsoft every twelve (12) months.

The Audit must cover all certificates uses enabled by Microsoft through the assignment of Extended Key Usages (EKUs). The audit report must document the full scope of the PKI hierarchy including any sub-CA that issues a specific type of certificate covered by an audit.

Commercial CAs

Qualified Audits are conducted by WebTrust for CAs and ETSI qualified auditors (See the section on Qualified Auditors below).

Government CAs
Previously Government CAs had the option to pursue the same Qualified Audits as commercial CAs (WebTrust, ETSI), or demonstrate audit equivalency and pursue an audit conducted according to local law or regulation.  We are phasing out the current audit equivalency exception for server authentication (SSL) use and replacing it with a new audit equivalency with baseline requirements exception.

Phase Out Period
Microsoft will continue to accept audit equivalency statements from Government CAs who are already members of the Windows Root Certificate Program until 15 January 2017. After this date audit equivalency statements will only be accepted from CAs whose roots are limited to client authentication and/or document signing use.

Audit equivalency statement
Until 15 January 2017, Microsoft will accept a statement from a government or private party auditor that the Government CA is audited according to local law or regulation.  The statement must attest to the CA’s audit status, giving the name of and reference to their audit guidelines, the date of the last audit, and equivalence of their audit criteria to a Qualified Audit (WebTrust, ETSI).

Audit equivalency with baseline requirements
Government CAs may continue to be audited according to local law or regulation after 2017 provided they either:

  • limit their root certificate to secure email, client authentication and time stamping uses (no server authentication use), or
  • the government CA incorporates the then current CAB Forum Baseline Requirements into their local audit criteria, and local auditors include them in their annual assessment.[14]

The Audit equivalency exception is available only to Government CAs.

Audit equivalency with baseline requirements will be available only to Government CAs whose conduct is governed by local law or regulation, and who accept the then current CAB Forum Baseline Requirements. Government CAs that opt not to pursue the Qualified Audit or audit equivalency with the baseline requirements exception by 15 January 2017 will have their root certificate(s) limited to secure email, client authentication and time stamping uses by removing EKUs.  No server authentication use can be enabled without a Qualified Audit...

qualified auditors

Qualified Auditors must meet the accreditation established by each of the audit regimes:

WebTrust for CAs
Microsoft accepts WebTrust audit reports from auditors who are licensed by WebTrust.  A list of licensed WebTrust audit practitioners is available at
http://www.webtrust.org/licensed-webtrust-practitions-international/item64419.aspx


ETSI
Microsoft accepts ETSI audit reports from auditing bodies that follow the rules of CEN Workshop Agreement CWA 14172-2. The auditing body for ETSI must have an official national accreditation – each nation has its own scheme for supervision of Certification Service Providers (also known as CAs or Trust Service Providers (TSPs).  Each nation also establishes an (optional) standard of national accreditation.  A simple list of national accreditation bodies accepted for ETSI audits is available at http://www.european-accreditation.org/home

Cross-border conformity assessment

For nations outside the ETSI framework, we will accept ETSI audits based on ETSI cross-border conformity rules.[15]

These are the qualified audits and auditors at this time for CAs. We reserve the right to change the audits listed above and/or accept other comparable audits in the future.

 

 

 

Qualified Audit Regime

EKUs Assigned

Qualified Audit

WebTrust for CAs

Server Auth (OV, DV)

Client Auth

Principles and Criteria for Certification Authorities 2.0
And
SSL Baseline Requirements Audit Criteria V1.1
Or
SSL Baseline Requirements Audit Criteria V1.1 (amended)

 

 

Server Auth (EV)

Client Auth

 

Principles and Criteria for Certification Authorities 2.0
And

Principles and Criteria for Certification Authorities – Extended Validation Audit Criteria 1.4 
Or
Principles and Criteria for Certification Authorities – Extended Validation Audit Criteria 1.4 (amended)

 

 

Code Signing (OV)

Principles and Criteria for Certification Authorities 2.0

 

 

Code Signing (EV)

Principles and Criteria for Certification Authorities 2.0
And
EV Code Signing Certificate Guidelines Version 1.1

 

ETSI

Server Auth (OVCP, DVCP)

Client Auth (QCP Public, QCP Public + SCCP)

Code Signing

ETSI TS 101 456 V1.4.3 or later version,

Policy requirements for certification authorities issuing qualified certificates

 

Server Auth (EVCP, EVCP+, OVCP, DVCP)

Client Auth (NCP, NCP+, LCP)

Code Signing

ETSI TS 102 042 V2.4.1 or later version,  Policy requirements for certification authorities issuing public key certificates

 

 

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.

[14] AUDIT EQUIVALENCY WITH BASELINE REQUIREMENTS There are general risks to Windows users created by CAs who issue SSL and other certificate uses according to criteria that do not incorporate the accepted baseline requirements for secure operations.  The Baseline Requirements may be updated annually by the CAB Forum, and the commitment by a government CA to incorporate them into local audit criteria must reflect an intention to incorporate the then-current baseline requirements on an annual basis.

Government CAs who make use of the audit equivalency exception do so based on the availability of alternate audit criteria established by local law or regulation, such as electronic signature laws. In particular, electronic signature laws have been the minimum criteria for verification of certificate operations in certain jurisdictions, but it becomes increasingly difficult to assess audit equivalency given the absence of baseline criteria for government CAs.  The CAB Forum Baseline Requirements give us a reasonable basis to assess periodically all CA’s certificate operations.

[15] ETSI CROSS-BORDER CONFORMITY ETSI is primarily a European Community organization, and most nations outside the European Community have not established a national accreditation scheme based on ETSI policies.  When evaluating whether ETSI auditors working in a location without national accreditation are Qualified Auditors, we look to the ETSI system of cross border conformity assessment. For example, a qualified ETSI auditor from a destination with a national accreditation scheme may conduct an ETSI Qualified Audit in a different location.  This is described in Section 7.2 of ETSI TS 119 403.

Return to the Microsoft Root Certificate Program Main Page