Updated: January 22, 2008
This document lists the details and requirements for the Microsoft Root Certificate Program ("Program"). Certification Authorities ("CAs") that are current members of the Program are listed at http://support.microsoft.com/kb/931125 .
On This Page
.gif)
Introduction
How Root Certificate Distribution Works
General Requirements
Technical Requirements
Government CAs
Extended Validation (EV) CAs
Code Signing Certificates
Exclusions from the Program
How to Apply
Annual Renewal
Frequently Asked Questions
Introduction
The Microsoft Root Certificate Program supports the distribution of root certificates, enabling trust among Windows clients. To date, Microsoft has approved nearly one hundred commercial and government CAs for participation in the Program. This page describes the terms for participation and will help new CAs get started to apply to the Program.
How Root Certificate Distribution Works
Root certificates are updated on Windows Vista 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.
Root certificates are also delivered for Windows XP and earlier via the Microsoft Update Catalog. Visitors to the Catalog can search on “root update” or the KB article for the Root Certificate Program, “KB931125”, and download the latest Root Update package. Root Updates are cumulative, so it should only be necessary to install the latest one to receive all root certificates in the Program.
Whether a user, or “relying party”, should trust a root certificate for any particular purpose can be a difficult question. CAs must be on guard against issuing certificates to people who put them to bad use, such as signing malicious software to make it seem more acceptable. CAs should have effective revocation policies and procedures to adequately deal with such certificates. Also, users are expected to scan a CA’s Certificate Practice Statement (CPS) before deciding to trust a certificate - to ensure that acceptance would not cause undue risk to a user’s security, for example. Such documents can be hundreds of pages long though, making user trust decisions complex. Microsoft’s role is to assess CAs and qualify them according to the Program requirements before enabling distribution of their root certificates. We rely upon the judgment of qualified assessors who have themselves been inside the doors of a CA and audited them against publicly available criteria. While our scope of review is relatively narrow and confined to parameters we can verify in advance, our intention is to help customers make difficult trust decisions.
General Requirements
-
The CA must provide the information requested below (see Step 1. Contact Microsoft), and receive preliminary approval for membership in the Program.
-
The CA must provide a test certificate issued from the CA’s root certificate for testing purposes. Optionally, a CA can provide to Microsoft a URL of a publicly accessible server where certificates issued from their root certificate can be verified. (See FAQ for details)
-
The CA must complete a Microsoft CA Agreement. The agreement will be provided only after you have completed Step 1 of the application process and received preliminary approval of your application.
-
Root certificates must comply with the Technical Requirements section below. In particular, we require a minimum crypto key size of RSA 2048-bit modulus for any root and all issuing CAs. Microsoft will no longer accept root certificates with RSA 1024-bit modulus of any expiration. We prefer that new roots are valid for at least 8 years from date of submission but expire before the year 2030, especially if they have a 2048-bit RSA modulus.
-
Certificates issued from a root certificate must support the CRL distribution point extension. The CRL distribution point should point to a location that is publicly accessible.
-
The CA must have a documented revocation policy, and the CA should be able to revoke any certificate they issue.
-
The CA must complete an audit and submit audit results to Microsoft every twelve (12) months. The Audit must cover the full PKI hierarchy that will be enabled by Microsoft through the assignment of Extended Key Usages (EKUs). All certificate usages that we enable must be audited periodically. 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. Eligible audits include:
These are the accepted audits at this time for non-government CAs. We reserve the right to change the audits listed above and/or accept other comparable audits in the future.
Technical Requirements
New root certificates must meet the following technical requirements:
-
Root certificates must be x.509 v3 certificates.
-
Subject Name must contain a meaningful name of the CA (ex. cannot be “Root” or “CA1”)
-
Basic Constraints extension: cA=true
-
Key Usage (if present): keyCertSign and cRLSign only
-
Root Key Sizes requirements are based on NIST SP 800-57:
-
Hash algorithm must be at least SHA1. No MD2, MD4 or MD5 hashes accepted.
-
For a root key size of greater or equal to an RSA 2048-bit modulus, root certificate must not expire until at least 8 years after submission and no later than 2030. Longer expiration may be afforded to larger root key sizes.
-
Intermediate CA certificates are excluded from the Root CA Program (See Frequently Asked Questions for more information)
Government CAs
Increasingly national and regional governments are establishing Certification Authorities intended primarily for government to government or citizen to government (e-government) transactions. These government CAs may be actual government entities, or private parties operating according to a government Certification Practice Statement (“CPS”). Government CAs must meet all the General and Technical Requirements for inclusion in the Program with the exception of audit. Microsoft may accept the following audit equivalency from government CAs.
Audit equivalency – for government CAs who issue certificates to secure government to government or citizen to government transactions, Microsoft will accept a statement from a government or private party auditor attesting 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 the Operating Standards (e.g. WebTrust For CAs, ETSI TS 102 042, ETSI 101 456, ISO 21188).
Extended Validation (EV) CAs
CAs have begun to issue a new, enhanced type of digital certificate known as Extended Validation (“EV”) certificates. Microsoft will mark a root certificate for issuance of EV digital certificates only when a Program-eligible CA has completed a qualified EV audit. Currently the only qualified EV audit is the WebTrust for CAs – WebTrust Extended Validation Criteria from a licensed WebTrust auditor. The WebTrust for CAs EV audit necessarily requires successful completion of a base audit as well. See General Requirements, above.
Code Signing Certificates
If a CA requests application of the code signing EKU to their root certificate, a supplementary agreement to the Root CA agreement may be required, covering the following requirements.
-
In the subscriber agreement the CA should require of the applicant or subscriber that the application details they provide be truthful, accurate, and not misleading, (application name, information URL, and application description). The subject also must be identified by a verified organization name. Failure by a subscriber to comply, or to promptly correct inaccurate information should result in revocation of the code signing certificate.
-
In the subscriber agreement the CA should give notice that they will revoke certificates issued to subscribers who use it to digitally sign hostile code, including spyware or other malicious software (malware) downloaded without user consent.
Exclusions from the Program
Microsoft includes in this Program CAs from all regions, regardless of relative size or market share. However, we currently exclude any of the following types of CAs from the Program:
-
Enterprise CAs: root certificates that are used internally within an organization or among partners (ex. large enterprises and businesses) are not accepted in the Program.
-
CA certificate usages must be public, meaning that the CA must issue certificates with approved usages to members of the public.
-
CAs who fail an audit, who fail to submit required audit results to Microsoft, or otherwise don’t meet the General or Technical Requirements.
-
CAs who fail to meet the burden of proof for the broad business value of their offering to Microsoft customers.
These are the current Program exclusions. We will give consideration to CAs addressing legitimate customer needs that may fall outside these guidelines, however. See the FAQ for some discussion of the issues we face and our philosophy for change. We reserve the right to change the exclusions listed above at any time in response to the needs of the Program.
How to Apply
We recommend that CAs applying for the Program complete these steps in order:
-
Contact Microsoft. To begin the Program application process, send an email with the following information to casubmit@microsoft.com:
-
Company name and address
-
Company Web page address (URL)
-
Two contacts from your organization (first and last name, e-mail address, and phone number)
-
Number of roots you would like to submit – maximum of three (3). Up to three roots per CA can be accepted into the Program because each additional root negatively impacts users by increasing download time.
-
Please answer the following questions about your root certificates:
-
What is the business purpose of the certificates issued from the root certificate(s)?
-
To whom will you issue certificates? For example, to the general public, or to members of a certain organization (please specify).
-
What Extended Key Usage does the root require? For example, SSL server or client authentication, secure email, or code signing (See the FAQ for EKUs that are allowed and not allowed by the Program).
-
What is done to validate the identity of someone requesting a certificate you issue?
-
Provide a pointer to your Certification Practices Statement (URL).
-
List any third-party audits your CA practice has undergone.
-
Please describe how the services for which your root will be used to provide broad value to Microsoft customers.
-
Obtain Preliminary Approval of your application. Microsoft will respond to your email within a commercially reasonable timeframe after confirmation of receipt. An email will be sent with any questions or concerns, or containing a preliminary approval of your application and Next Steps to join the Program.
-
Engage an auditor. Engage a qualified auditor, and audit according to their assessment criteria (see General Requirements). Unless you would engage an auditor in the ordinary course of doing business, we do not recommend that you engage an auditor for purposes of joining this Program until after you have received preliminary approval of your application for membership.
-
Complete a Microsoft CA Agreement. Complete a Microsoft CA Agreement, memorializing the above program requirements. Return two (2) signed copies (signed by a duly authorized representative of your organization) to Microsoft at the following address:
Microsoft Root Certificate Program
Attn: Tom Albertson
Program Manager, Windows Security
Bldg 27/2292
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052- 6399
Ph 425-882-8080
Microsoft will review the submitted CA Agreement and, if accepted, will counter-sign and return the Agreement to you after steps 5 and 6 below have been successfully completed.
-
Send your Root Certificates. Send your root certificate(s) as an email attachment to Microsoft, at casubmit@microsoft.com. It is best to send .cer or .der files packaged in a .zip format to avoid Microsoft’s mail filters.
-
Publication of roots via Windows Update. Microsoft will distribute new Root Updates on a regular basis, typically 3-4 times per year, or as necessary to ensure distribution of the root certificates. Root certificates accepted by Microsoft are made available to Windows Vista and Windows XP clients through Windows Update and the Microsoft Update Catalog.
Annual Renewal
Microsoft will endeavor to contact each CA approximately three (3) months prior to expiration of the twelve (12) month period after their participation in the Program commences. Remember that participation in the Program requires annual renewal of the following:
-
CA must complete a qualified audit and submit the audit report to Microsoft every twelve (12) months.
-
CA must complete or extend a Microsoft CA Agreement, as necessary.
CAs are responsible to perform a qualified audit of their operations in a timely manner regardless whether Microsoft contacts them as described here.
Frequently Asked Questions
-
How much does the program cost?
Microsoft does not currently charge for the Root Certificate Program. However, there is a material cost to CAs payable to an assessor associated with meeting the annual audit requirements. The CA is solely responsible for, and shall bear all financial and other costs and obligations associated with, meeting the requirements of the Program.
-
How can I establish the equivalency of my audit / auditor to WebTrust or ETSI?
The burden is on the CA to establish audit equivalency. Typically we do not accept audit equivalency except from government CAs. In the case of government CAs, we may accept a statement of equivalency from their auditor, documenting where the audit meets, exceeds or falls short of eligible audit criteria.
Audits are an obligatory part of the Program, and it’s also the area where our requirements can be the most adaptable. The CA industry is relatively new, laws can vary, and few audits exist specifically to validate a CA’s typical PKI operations. Over time we have expanded our list of accepted CA audits to include ETSI 102 042, ETSI 101 456, WebTrust for CAs, WebTrust EV Readiness audits, and ISO 21188. We also recognize a statement of audit equivalency from a government CA or from a private party operating according to a government designated CPS.
At the moment we do not accept an ISO 27001 certification primarily because it is not focused on CA operations. But we intend to investigate ISO 27001 in the future, and if you have any additional information on its use to evaluate CA PKIs in particular we would appreciate hearing about it. Until our requirements change, if you have an interest in participating in our Program we recommend that you contact your auditor to pursue one of the other audits.
-
What is the deadline for submitting my root certificate?
Microsoft will accept root certificates on an on-going basis, so there is no hard deadline. We publish the Root Update 3-4 times per year on what is known as the Windows Update Non-Security refresh schedule, which releases on the 4th Tuesday of the month. The Root Update is due to Windows Update near the beginning of the month, and we need at least 2 weeks time to test the Root Update package before that. Generally speaking when we anticipate a Root Distribution in the following month (January), CAs should be approved and have all materials at Microsoft by the 15th of the previous month (December). However, Microsoft cannot guarantee distribution of a Root Update on a regular schedule or in a specific month, as Windows Update may cancel non-security refresh releases on short notice in order to prepare for update releases that require additional attention.
CAs who have received preliminary approval for membership will be kept advised of upcoming deadlines for distribution. If you have a specific release deadline for your root certificate, talk to us, and we will do what we can to help you meet it. As it is with many things, much can be accomplished with communication and preparation. Microsoft will use commercially reasonable efforts to accommodate a CA’s start date for root availability via Windows Update; however, Microsoft makes no representations, warranties, guarantees or other promises with respect to the actual date of availability on Windows Update or the Microsoft Update Catalog.
-
What is meant by “how the services for which your root will be used provide broad value to Microsoft customers”?
Roughly speaking, it means the benefits to including the root certificate outweigh any risks to Microsoft customers. Among potential benefits include alignment of a CA’s certificate issuance with Microsoft strategies.
-
What is meant by “the Audit must cover the full PKI hierarchy that will be enabled by Microsoft through the assignment of Extended Key Usages (EKUs)?”
All certificate usages that we enable via the Program must be audited. 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. This audit requirement holds the CA accountable for their certificate usages, nothing more. In the past, CAs might produce audit reports covering only a chosen part of their PKI, while we would be asked to enable their root certificate for a number of unaudited usages. Going forward, if a CA wants to be enabled for [code signing], they must be audited for [code signing]. Same for client and server authentication (SSL) and S/MIME.
This lack of an audit was also reflected in revocation policies: some CAs might neglect to define revocation policies for certain certificate usages, leaving their subscribers and relying parties uncertain as to their actual responsibilities after they issue a certificate. Going forward, CAs must have revocation policies in their Subscriber Agreements that clearly cover the EKUs that they specify for their root certificates. Every certificate policy must include a revocation policy. We will seek evidence of revocation policies during annual audits, and rely on those audits to determine which EKUs we will apply to the root certificates.
We believe this is a reasonable audit requirement, in that under most any regulatory framework a PKI is not allowed to function without that aspect of its usage being audited.
-
What is meant by “the CA must have clear policy and be able to revoke any certificate they have issued?” How will you monitor this?
CAs must have revocation policies in their Subscriber Agreements that clearly cover the EKUs that they specify for their root certificates. Every certificate policy must include a revocation policy. We will seek evidence of revocation policies during annual audits.
-
Can you explain some more about issuing test certificates as part of the application process? Our certificate policy for the root certificate does not allow us to issue test certificates.
We don’t exhaustively test certificates for compatibility with Windows, but a test certificate is used to verify the automatic root update feature on Windows XP and later. If permitted by a CA’s CPS, the test certificate should be issued under the production root hierarchy, and the certificate chain should be sent to Microsoft. Optionally, a CA can provide an HTTPS URL which we can connect to during test and verify proper chaining to the root certificate.
-
Why won’t you distribute my intermediate root CAs? I have problems building chains to my root certificate without them.
The Program is responsible for updating root certificates only. Intermediate certificates included in Windows today are purely for legacy reasons. Managing the distribution of intermediate certificates for all CAs in the root program is not scalable since CAs frequently add and remove intermediate CAs for business and lifecycle reasons. Generally intermediate CA certificates can be distributed in two ways:
-
PKI applications such as SSL, S/MIME, and Microsoft Authenticode always send the intermediate CA certificates with the end certificate to facilitate intermediate certificae distribution. This is the preferred solution.
-
The CA has the option to specify a URL in a certificate via the Authority Information Access extension (RFC 3280) that serves as a hint to Windows CryptoAPI to download the issuer certificate. Most CAs today issue certificates with the AIA extension to enable issuer certificate discovery.
-
I have more than three roots certificates I would like considered for distribution in the Program, how can I get them in?
Generally you cannot have more than three roots per CA in the Program, except for root rollover or legacy situations. CAs submitting multiple roots must justify why each additional root is necessary – such as, it was created to accommodate specific government regulations, a legacy deployment, access control requirements etc. We will accept any additional certificates beyond three roots as a ‘rollover root’ (intended to replace an existing root certificate) provided we can agree on a date for removal of the legacy root. Generally we will work together with CAs on these dates, but we expect to remove expired root certificates 6-12 months after expiration and an existing root certificate 6-12 months after we begin to distribute a rollover root certificate.
-
Why must I specify EKUs for my roots?
The intent of the Program is to enable PKI scenarios for the mass consumer market such as e-commerce, secure e-mail, and code signing. It is not intended to enable enterprise-only scenarios.
EKUs in Windows are inherited from the root certificate down to the end entity certificate. This ensures certificates issued by any CA under this root can only be used for the stated list of usages.
We will attach EKU metadata to the certificate as metadata in the Windows certificate store so you do not need to regenerate your root certificate with the EKU extension.
-
What EKUs are allowed?
The following is a list of allowed EKUs. Other EKUs may be granted if the applicant is able to provide justification:
-
Server Authentication EKU=%1_SAUTH%
-
Client Authentication EKU=%1_CAUTH%
-
Secure E-mail EKU=%1_EMAIL%
-
Code Signing EKU=%1_CSIGN%
-
Time stamping EKU=%1_TSTMP%
-
OCSP EKU=%1_OCSP%
-
Encrypting File System EKU=%1_EFS%
-
IPSec (Tunnel, User) EKU=%1_IPTUNNEL%, EKU=%1_IPUSER%,
-
What EKUs are typically not allowed?
The following EKUs do not fit the Program criteria or are no longer necessary:
-
Smart card logon
-
Digital rights
-
Qualified subordination
-
Key recovery
-
File recovery
-
All application policies
-
Directory service email replication
-
Certificate request agent
-
Key recovery agent
-
CA encryption certificate
-
Is there a maximum number of roots that can be included in the Program? May there come a time when you don’t accept any more root certificates?
Yes. Increasing the number of root certificates made available through this Program can negatively affect Windows performance, since all root certificates are decoded into memory in every process that uses certificates. Actual performance degradation may differ based on version of Windows and type of hardware, but we consider the long-term impact of every decision to incorporate new root certificates, and new classes of CAs. We have not approached the number of root certificates where performance might be impacted, but we make individual application decisions with the long-term in mind. We reserve the right to make membership decisions in our sole discretion based on these criteria, and to change those criteria without notice in the event of any disruption to Windows performance.
Also, every additional root certificate increases the risk of a key compromise or bad certificates due to CA error for hundreds of millions of Windows users worldwide. As a result, we face increasing pressure from the worldwide security community to limit the number of root certificates we distribute for CAs. We only accept CAs that provide value to a large percentage of Microsoft Windows users worldwide or within a country or region. Going forward, we intend to work with the PKI and audit communities on audit regimes and assessor guidelines that will improve CA practices and justify our decision to admit additional CAs.