Microsoft Trusted Root Certificate: Program Requirements

4 programming

Microsoft Trusted Root Certificate: Program Requirements

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

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 and email the completed form to 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.

  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)
  1. The name, email address, phone number, and job title of the person who will sign the Program contract

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 for each root, non-limited sub-root, or cross-signed non-enrolled root, before conducting commercial operations and thereafter on an annual basis.

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.
  1. Root Key Sizes must meet the requirements detailed in “Key Requirements”.

B. Key Requirements

SHA1 (may submit until January 1, 2016)

SHA2 (SHA256, SHA384, SHA512)

SHA1 (may submit until January 1, 2016)

SHA2 (SHA256, SHA384, SHA512)

4096 (New roots only)

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.
  1. Minimum validity of 1 day; Maximum validity of 1 week; and

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

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).
  1. Server Authentication =

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. A zipped copy of the .cer file of the root that the CA will use kernel-mode code signing; and

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.

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.
  1. A Private Key compromise.

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.

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

D. CA Responsibilities in the Event of an Incident

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

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.