Microsoft Trusted Root Certificate: Program Requirements

  • Article

1. Introduction

The Microsoft Trusted Root Certificate Program (“Program”) supports the distribution of qualifying root certificates in Microsoft Windows and other Microsoft Products and Services. This page describes the Program’s general and technical requirements, including information about how a Certificate Authority (CA) can contact Microsoft to request inclusion into the Program.

This document lists the details and requirements for the Program. Certification Authorities ("CAs") that are current members of the Program are listed at https://support.microsoft.com/kb/931125.

How Root Certificate Distribution Works

Starting with the release of Windows Vista, root certificates are updated on Windows automatically. When a user visits a secure Web site (by using HTTPS SSL), reads a secure email (S/MIME), or downloads an ActiveX control that is signed (code signing) and encounters a new root certificate, the Windows certificate chain verification software checks the appropriate Microsoft Update location for the root certificate. If it finds it, it downloads it to the system. To the user, the experience is seamless. The user does not see any security dialog boxes or warnings. The download happens automatically, behind the scenes.

2. Certificate Authority Intake Process

In order to begin the process to be included in the Program, a CA must fill out the application located at https://aka.ms/rootcertapply and email the completed form to trustcert@microsoft.com. This will begin the onboarding process, outlined below:

  1. Microsoft will review the application, and may request additional documentation from the CA to determine if the CA meets the Program requirements and whether, in Microsoft’s judgment, the CA’s inclusion into the program will benefit Microsoft’s customers.

  2. Microsoft will provide preliminary Program approval to the CA and a deadline by which all materials must be completed and returned to Microsoft, for the CA to in included in the next release (typically every four months).

  3. Upon receipt of preliminary approval from Microsoft, the CA will need to engage an auditor to complete the necessary audit. See, https://aka.ms/auditreqs for more information about the Program’s audit requirements.

  4. When the audit is complete, the CA must send the following materials to Microsoft:

    1. A copy of all of the roots that the CA wishes to have Microsoft include in the Program in .cer file format (contained in a .ZIP file)

    2. Test URLs for each root, or a URL of a publicly accessible server that Microsoft can use to verify the certificates.

    3. An electronic copy or URL that contains the most recent audit attestation for each of the roots the CA wishes to have Microsoft include in the Program

    4. Information to complete and sign the Program contract, including:

      1. The name, email address, phone number, and job title of the person who will sign the Program contract

      2. A second contact’s name, email address, and phone number.

      3. The company’s principle place of business (street address).

      4. The company’s place of incorporation (country or state/province).

  5. Microsoft will send the Program contract to the CA to sign and return to Microsoft.

  6. Upon receipt of the completed contract, Microsoft will add the CA to the next release, if the CA has returned the materials by the deadline provided to the CA. Otherwise, Microsoft will add the CA’s roots to a subsequent release.

Note

Microsoft will determine at its sole discretion which CA certificates are included the Program.

Microsoft will not charge any fee for including a CA’s certificates in the Program.

Microsoft reserves the right to not include a CA in the Program for any reason or no reason at all, and such decisions are at Microsoft’s sole discretion.

3. Continuing Program Requirements

All CAs in the Program must comply with these Continuing Program Requirements. If Microsoft determines that a CA is not in compliance with the below requirements, Microsoft may exclude the CA from the Program.

  1. The CA must provide to Microsoft evidence of a Qualified Audit (see https://aka.ms/auditreqs) for each root, non-limited sub-root, or cross-signed non-enrolled root, before conducting commercial operations and thereafter on an annual basis.

  2. The CA must assume sole responsibility for ensuring that all non-limited sub-roots and cross-signed, non-enrolled roots meet the Program Audit Requirements.

  3. The CA must provide Microsoft with updated Program contact information every July, November, and March, as well as upon Microsoft’s request. The CA must designate and disclose to Microsoft at least two contacts to be responsible to receive communications from Microsoft, including contact names, email addresses, and business and mobile phone numbers.

  4. The CA must disclose its full PKI hierarchy (non-limited sub-roots, cross-signed non-enrolled roots, intermediates, EKUs, certificate restrictions) to Microsoft on an annual basis, including certificates issued to CAs operated by external third parties. More about the depth of sub-CA (define as all below root)

  5. CAs must inform Microsoft at least 120 days before transferring ownership of an enrolled root to another entity or person, and obtain Microsoft’s written consent prior to transfer, which consent may be granted or denied in Microsoft’s sole discretion.

  6. CAs must agree to receive notices by e-mail and must provide Microsoft with an email address to receive official notices. If Microsoft sends an email that is undeliverable, Microsoft will send notices to the last-known address for the CA. CAs must agree that notice is effective when Microsoft sends the email or the letter.

  7. CAs must agree that Microsoft may contact the CA’s customers who Microsoft believes may be substantially impacted by Microsoft’s decision to remove a root from the Program.

  8. CAs may not enroll a root into the Program that is intended to be used internally within an organization (i.e. Enterprise CAs).

  9. CAs must publicly disclose all audit reports for non-limited sub-roots.

  10. If a CA uses a subcontractor to operate any aspect of its business, the CA must assume responsibility for the subcontractor’s business operations.

4. Program Technical Requirements

All CAs in the Program must comply with the Program Technical Requirements. If Microsoft determines that a CA is not in compliance with the below requirements, Microsoft may exclude the CA from the Program.

A. Root Requirements

  1. Root certificates must be x.509 v3 certificates.

    1. The CN attribute must identify the publisher and must be unique.

    2. The CN attribute must be in a language that is appropriate for the CA’s market and readable by a typical customer in that market.

    3. Basic Constraints extension: must be cA=true.

    4. Key Usage (if present) must be keyCertSign and cRLSign only.

      1. Root Key Sizes must meet the requirements detailed in “Key Requirements”.

  2. New roots must be valid for at least eight (8) years from the date of submission.

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

  4. The CA may not issue new 1024-bit RSA certificates.

  5. All certificates issued from a root certificate must support either the CRL distribution point extension or AIA containing an OCSP responder URL

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

  7. All roots that are being used to issue new certificates, and which directly or transitively chain to a certificate included in the Program, must either be limited or be publicly disclosed and audited.

  8. Government CAs must restrict server authentication to .gov domains and may only issues other certificates to the ISO3166 country codes that the country has sovereign control over (see https://aka.ms/auditreqs section III for the definition of a “Government CA”).

  9. Government CAs that also operate as commercial, non-profit, or other publicly-issuing entities must use a different root for all such certificate issuances (see https://aka.ms/auditreqs section III for the definition of a “Commercial CA”).

  10. 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, which can be found at https://www.cabforum.org.

  11. Intermediate CA certificates under root certificates submitted for distribution by the Program must separate Server Authentication Code Signing and Time Stamping uses. This means that a single issuing CA must not be used to issue both server authentication and code signing certificates. A separate CA must be used for each use case.

  12. Rollover root certificates, or certificates which are intended to replace previously enrolled but expired certificates, will not be accepted if they combine server authentication with code signing uses unless the uses are separated by application of Extended Key Uses (“EKU”s) at the intermediate CA certificate level that are reflected in the whole certificate chain.

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

  14. For Server Authentication certificates, Windows will stop trusting SHA1 certificates on 1 January 2017. This means any SHA1 SSL certificates issued before or after this announcement must be replaced with a SHA2 equivalent by January 1, 2017.

    Note

    Microsoft will not require CAs to replace SHA1 Server Authentication certificates but will no longer trust SHA1 certificates after January 1, 2017.

  15. CAs must use the following OIDs in the end-entity certificate: DV 2.23.140.1.2.1; OV 2.23.140.1.2.2; EV 2.23.140.1.1.; IV 2.23.140.1.2.3; EV Code Signing 2.23.140.1.3; Non-EV Code Signing 2.23.140.1.4.

  16. End-entity certificates that include a Basic Constraints extension in accordance with IETF RFC 5280 must have the cA field set to FALSE and the pathLenConstraint field must be absent.

B. Key Requirements

Algorithm All Uses Except for Code Signing and Time Stamping Code Signing and Time Stamping Use

Digest Algorithms

SHA1 (may submit until January 1, 2016)

SHA2 (SHA256, SHA384, SHA512)

SHA1 (may submit until January 1, 2016)

SHA2 (SHA256, SHA384, SHA512)

RSA

2048

4096 (New roots only)

ECC / ECDSA

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

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

C. Revocation Requirements

  1. The CA must have a documented revocation policy and must have the ability to revoke any certificate it issues.

  2. [Deleted July 2015.]

  3. CAs that issue Server Authentication certificates must support the following OCSP responder requirements:

    1. Minimum validity of 1 day; Maximum validity of 1 week; and

    2. The next update must be available at an interval of ½ of the validity period. For example, if the maximum validity is 48 hours the next update must be available 24 hours before the current item expires.

  4. All certificates issued from a root certificate must support either the CRL distribution point and/or AIA containing an OCSP responder URL.

  5. The CA must not use the root certificate to issue end-entity certificates.

  6. The CA must operate their own Time Stamp Authority. The Time Stamp Authority must comply with RFC 3161, “Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP).”

D. Code Signing Root Certificate Requirements

  1. In order to qualify for the code signing EKU, new root certificates submitted for distribution by the Program must be separate Server Authentication from Code Signing and Time Stamping uses at the intermediate certificate level.

  2. New code signing root certificates must support the SHA2 hash algorithm.

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

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

  5. Root certificates will be removed from distribution by the Program without regard to any unexpired end entity certificates issued from them, according to the following deadlines:

    1. Server Authentication certificates: CAs must begin issuing new certificates using only the SHA-2 algorithm after January 1, 2016. Windows will no longer trust certificates signed with SHA-1 after January 1, 2017.

    2. Code signing certificates: CAs must begin issuing new certificates using only the SHA-2 algorithm after January 1, 2016. For developers targeting Windows Vista and Windows Server 2008 CAs will be allowed to continue issuing SHA-1 certificates.

    3. Time-stamping certificates: CAs must begin issuing new certificates using only the SHA-2 algorithm after January 1, 2016. For developers targeting Windows Vista and Windows Server 2008, CAs will be allowed to continue issuing SHA-1 certificates. Windows will not enforce a policy on time-stamping certificates.

    4. OCSP signatures: Microsoft requires CAs to start issuing new OCSP signatures using only the SHA-2 algorithm after January 1, 2016. Windows will no longer trust OCSP responses that use SHA-1 for their signature if the corresponding certificate had the Must Staple extension after January 1, 2016

    5. Time-stamp signature hashes: CAs must start issuing new time-stamp signature hashes using only the SHA-2 algorithm after January 1, 2016. For developers targeting Windows Vista and Server 2008, CAs will be allowed to continue issuing SHA-1 time-stamps.

E. EKU Requirements

  1. 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).

  2. Microsoft will only enable the following EKUs:

    1. Server Authentication =1.3.6.1.5.5.7.3.1

    2. Client Authentication =1.3.6.1.5.5.7.3.2

    3. Secure E-mail EKU=1.3.6.1.5.5.7.3.4

    4. Code Signing EKU=1.3.6.1.5.5.7.3.3

    5. Time stamping EKU=1.3.6.1.5.5.7.3.8

    6. Encrypting File System EKU=1.3.6.1.4.1.311.10.3.4

    7. Document Signing EKU=1.3.6.1.4.1.311.10.3.12

F. Windows 10 Kernel Mode Code Signing (KMCS) Requirements

Windows 10 has additional requirements to validate kernel-mode drivers, which are appropriately signed by Microsoft and a CA. CAs who wish to become authorized for kernel mode code signing must complete the steps below.

  1. The CA must send an email to trustcert@microsoft.com with:

  2. Microsoft will evaluate whether the CA complies with all of the Program’s requirements.

    1. A zipped copy of the .cer file of the root that the CA will use kernel-mode code signing; and

    2. The policy OID that the CA will use to identify kernel-mode code signing.

  3. Microsoft will evaluate whether the CA complies with all of the kernel mode code signing requirements.

  4. Microsoft will send the CA the appropriate contract materials.

  5. Upon receipt of the signed contract materials, Microsoft will add the CA to the list of authorized kernel-mode code signing participants.

5. Technical Best Practices

Though not required by Microsoft, the following represents what Microsoft believes to be the best practices that each CA should follow.

  1. Microsoft recommends that each CA have an established communication channel to its customers. For example, if Microsoft were to notify the CA that Microsoft was disabling weak file hashes, the CA should have a method to notify its customers to use the updated signtool.exe file.

  2. Because root certificates will be removed without regard to any unexpired end entity certificates issued from them, the 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.

  3. While Windows will not enforce specific policies on Secure Email certificates, Microsoft recommends that CAs start issuing new Secure Email certificates using the SHA-2 algorithm.

6. Security Incident Response Requirements

A. Definitions

  1. “A compromise” means a direct or indirect incident, affecting either the CA or any of the CA’s sub-roots ooor cross-signed, non-enrolled roots, that results in an actual or potential degradation of the security stature of the PKI, which includes hardware, software, or physical building issues.

  2. “Security Incident” or “Incident” means any of the following that occur at the CA or a sub-CA:

    1. A Private Key compromise.

    2. A mis-issued certificate.

    3. A known or reasonably knowable, publicly reported compromise.

    4. Any physical compromise of the CAs infrastructure (e.g. physical access control failure, building compromise, or a failure of the HVAC in the data center).

    5. Any other issue that Microsoft identifies as calling into question the CA’s integrity or trustworthiness.

  3. “Exceptional Circumstance(s)” means an Incident(s) the causes Microsoft to reasonably believe that the PKI is compromised; and such Incident affects the security posture of a large number of Microsoft’s customers.

B. Microsoft’s Rights in the Event of an Incident

In the event of a Security Incident, Microsoft may at its sole discretion, do any of the following:

  1. In an Exceptional Circumstance, immediately revoke any certificate the CA or any sub-CA has enrolled in the Program, otherwise it may revoke any certificate after providing 7 days’ advance notice to the CA.

  2. Microsoft may take action including, but not limited to marking files signed by compromised certificates as malware, blocking web navigation to sites served with compromised Server Authentication certificates, preventing delivery of mail signed by compromised Secure Email certificates, etc.

  3. Request that the CA make specific reports at a periodic interval to be determined by Microsoft.

  4. Specify a due date for the CA to submit to Microsoft a final Security Incident report.

  5. Communicate with affected third parties.

  6. Require the CA to employ, at the CA’s expense, a third-party investigator to investigate the Security Incident and prepare the final Security Incident report.

  7. Disqualify any Qualifying Audit and require the CA to perform a new Qualifying Audit at the CA’s sole expense.

C. Microsoft’s Responsibilities in the Event of a Security Incident

In the event that Microsoft exercises any of the rights described above, Microsoft will:

  1. Notify the CA, in writing, of its intentions 7 days prior to Microsoft’s action, except under Exceptional Circumstances, in which case Microsoft will make reasonable efforts to communicate with the CA prior to taking action; and

  2. Allow the CA to propose an alternate course of action, in which case, Microsoft will consider reasonable alternatives but reserves the right to reject such proposals if it deems the proposed course of action not to be in its customers’ best interest.

D. CA Responsibilities in the Event of an Incident

In the event of a Security Incident, the CA must:

  1. Notify Microsoft as soon as is practical but no later than 24 hours from the time of the Security Incident by (a) completing the form located at https://aka.ms/rootnotify, and (b) sending the completed form to rootnotify@microsoft.com. The form requires the following information (if known at the time):

    1. Who detected the Incident.

    2. If available, the identity of the perpetrator(s) whose actions caused the Incident.

    3. When the CA discovered the Incident.

    4. Where the Incident occurred.

    5. The Roots and, if requested by Microsoft, end-user certificates that were affected by the Incident, if any.

    6. The sub-CAs that were affected by the Incident, if any.

    7. What the CA believes to be the underlying cause of the Incident.

    8. What remedial measures the CA has taken or will take that the CA believes will address the underlying cause of the Incident.

    9. Any other information the CA believes to be appropriate.

    10. Any other information requested by Microsoft when it responded to the initial notification.

  2. At Microsoft’s request, the CA must provide a list of all certificates that were mis-issued as a result of the Incident.

  3. At Microsoft’s request, the CA must provide Microsoft with periodic reports at an interval specified by Microsoft. If Microsoft does not make a specific request within 24 hours of an initial notification, the CA must provide reports to Microsoft as it discovers any new information.

  4. The CA must provide a final Security Incident report to Microsoft that includes:

    1. A list of certificates and domains involved in the Incident.

    2. How did the CA detect the Incident? If the CA did not detect the Incident, who did and why did the CA not detect it?

    3. If the CA has reported conflicting information, why?

    4. Detailed description of the Incident.

    5. Details about what infrastructure was compromised.

    6. Details about how the infrastructure was compromised.

    7. A detailed timeline of events.

    8. The CA’s interpretation of who perpetrated the Incident.

    9. Log files (appendix only).

    10. Was the Incident detected by the CAs normal operation? If it was not, the CA must explain why.

    11. If the Incident involved vulnerability, was the vulnerability discovered in the most-recent audit? If yes, then provide information explaining how the vulnerability was remediated. If the vulnerability was not remediated, the CA must provide information about the reason for not doing so.

    12. What changes to the CP/CPS policies will the CA make?

    13. Detailed description of how the Incident was closed.

    14. If requested by Microsoft, a complete investigative and technical report of the compromise.

See Also

Other Resources

Microsoft Trusted Root Certificate Program: Audit Requirements for Certificate Authorities