NEW The SHA1 Deprecation Policy is listed below under the Section "Algorithm Policies".
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 must be x.509 v3 certificates.
Basic Constraints extension: cA=true
Root CA Organization Name must appear in the Root Certificate
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.
Number of Root Certificates Distributed by the Program
CAs may request distribution of three (3) root certificates per “CA Brand”
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.
Root certificates must meet the following
minimum key size requirements:
All Uses Exception for Code Signing and Time stamping
Code Signing and Time stamping Use
SHA1 (until 1 Jan 2016)
SHA2 (SHA256, SHA384, SHA512)
SHA1 (until 1 Jan 2016)
SHA2 (SHA256, SHA384, SHA512)
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.
Root certificate Key Usage (if present): keyCertSign and cRLSign
Code Signing Root Certificates
New code signing root certificates must support the SHA2 hash algorithm.
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 =126.96.36.199.188.8.131.52.1
Client Authentication =184.108.40.206.220.127.116.11.2
Secure E-mail =18.104.22.168.22.214.171.124.4
Other EKUs may be granted if the CA is able to provide additional or specific justification:
Code Signing =126.96.36.199.188.8.131.52.3 (see Explanatory Note for qualifying your root for the code signing EKU)
Time stamping =184.108.40.206.220.127.116.11.8
OCSP =18.104.22.168.22.214.171.124.9 (see Explanatory Note for qualifying your root for the OCSP EKU)
Encrypting File System =126.96.36.199.4.1.3188.8.131.52
IPsec (Tunnel, User) =184.108.40.206.220.127.116.11.6, 18.104.22.168.22.214.171.124.7
Document Signing = 126.96.36.199.4.1.3188.8.131.52
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.
INTERMEDIATE / ISSUING CA CERTIFICATES
Intermediate CA certificates are excluded from distribution in the Windows Root Certificate Program.
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.
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.
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.
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
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).
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.
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.
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).
Currently Disallowed Algorithms and Key Lengths
The following algorithms and key lengths are no longer accepted in the Program.
MD2, MD4, MD5 (blocked by
RSA with keys smaller than 1024 bits (blocked by
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.
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.
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.
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.
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
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.
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).
KEY SIZES See the section on Algorithm Policies, SHA1 Deprecation Policy for additional information.
KEY SIZES See the section on Algorithm Policies, SHA1 Deprecation Policy for additional information.
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.
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.
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.”
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
For CAs who only support the
CA delegated OCSP signer model, the OCSP EKU is not required by Windows.
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.
This EKU is obsolete. Windows Media DRM uses it own XML format for licenses and does not use X.509.
This EKU is obsolete and is ignored by Windows.
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
Certificate request agent
Key recovery agent
CA encryption certificate
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.
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.
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:
Return to the Microsoft
Root Certificate Program Main Page