Windows trust root ca

Trusted Root Certification Authorities Certificate Store

Starting with Windows Vista, the Plug and Play (PnP) manager performs driver signature verification during device and driver installation. However, the PnP manager can successfully verify a digital signature only if the following statements are true:

The signing certificate that was used to create the signature was issued by a certification authority (CA).

The corresponding root certificate for the CA is installed in the Trusted Root Certification Authorities certificate store. Therefore, the Trusted Root Certification Authorities certificate store contains the root certificates of all CAs that Windows trusts.

By default, the Trusted Root Certification Authorities certificate store is configured with a set of public CAs that has met the requirements of the Microsoft Root Certificate Program. Administrators can configure the default set of trusted CAs and install their own private CA for verifying software.

NoteВ В A private CA is unlikely to be trusted outside the network environment.

Having a valid digital signature ensures the authenticity and integrity of a driver package. However, it does not mean that the end-user or a system administrator implicitly trusts the software publisher. A user or administrator must decide whether to install or run an application on a case-by-case basis, based on their knowledge of the software publisher and application. By default, a publisher is trusted only if its certificate is installed in the Trusted Publishers certificate store.

The name of the Trusted Root Certification Authorities certificate store is root. You can manually install the root certificate of a private CA into the Trusted Root Certification Authorities certificate store on a computer by using the CertMgr tool.

NoteВ В The driver signing verification policy that is used by the PnP manager requires that the root certificate of a private CA has been previously installed in the local machine version of the Root Certification Authorities certificate store. For more information, see Local Machine and Current User Certificate Stores.

For more information about driver signing, see Driver Signing Policy.

Источник

Program Requirements — Microsoft Trusted Root Program

1. Introduction

The Microsoft Root Certificate Program supports the distribution of root certificates, enabling customers to trust Windows products. This page describes the Program’s general and technical requirements.

• For information on the most-recent updates shipped, please see https://aka.ms/rootupdates
• Bookmark this page as: https://aka.ms/RootCert

2. Continuing Program Requirements

Audit Requirements

1. Program Participants must provide to Microsoft evidence of a Qualified Audit (see https://aka.ms/auditreqs) for each root, unconstrained subordinate CA, , and cross-signed certificate, before conducting commercial operations and thereafter on an annual basis.
2. Program Participants must assume responsibility to ensure that all unconstrained subordinate CAs and cross-signed certificates meet the Program Audit Requirements.
3. CAs must publicly disclose all audit reports for unconstrained subordinate CAs.

Communication and Disclosure Requirements

Program Participants must provide Microsoft the identities of at least two «Trusted Agents» to serve as representatives to the Program and one general email alias. Program Participants must inform Microsoft upon the removal or addition of personnel as a Trusted Agent. Program Participants agree to receive notices by e-mail and must provide Microsoft with an email address to receive official notices. Program Participants must agree that notice is effective when Microsoft sends an email or official letter. At least one of the contacts or aliases provided should be a 24/7 monitored communications channel for revocation requests or other incident management situations.

The Program Participant must disclose its full PKI hierarchy (non-limited subordinate CA, cross-signed non-enrolled root CAs, subordinate CAs, EKUs, certificate constraints) to Microsoft on an annual basis, including certificates issued to CAs operated by external third parties within the CCADB. Program Participants must keep this information accurate in the CCADB when changes occur. If a subordinate CA is not publicly disclosed or audited, it must be domain-constrained.

Program Participants must inform Microsoft via email at least 120 days before transferring ownership of enrolled root or subordinate CA that chains to an enrolled root to another entity or person.

Reason Code must be included in revocations for intermediate certificates. CAs must update the CCADB when revoking any intermediate certificates within 30 days.

Program Participants agree that Microsoft may contact customers that Microsoft believes may be substantially impacted by the pending removal of a root CA from the Program.

Other Requirements

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

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

If Microsoft, in its sole discretion, identifies a certificate whose usage or attributes are determined to be contrary to the objectives of the Trusted Root Program, Microsoft will notify the responsible CA and request that it revoke the certificate. The CA must either revoke the certificate or request an exception from Microsoft within 24 hours of receiving Microsoft’s notice. Microsoft will review submitted material and inform the CA of its final decision to grant or deny the exception at its sole discretion. In the event that Microsoft does not grant the exception, the CA must revoke the certificate within 24 hours of the exception being denied.

3. 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 will exclude that 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 extension MUST be present and MUST be marked critical. Bit positions for KeyCertSign and cRLSign MUST be set. If the Root CA Private Key is used for signing OCSP responses, then the digitalSignature bit MUST be set.
      • Root Key Sizes must meet the requirements detailed in «Key Requirements».
2. Certificates to be added to the Trusted Root Store MUST be self-signed root certificates.
3. Newly minted Root CAs must be valid for a minimum of 8 years, and a maximum of 25 years, from the date of submission.
4. Participating Root CAs may not issue new 1024-bit RSA certificates from roots covered by these requirements.
5. All end-entity certificates must contain an AIA extension with a valid OCSP URL. These certificates may also contain a CDP extension that contains a valid CRL URL. All other certificate types must contain either an AIA extension with an OCSP URL or a CDP extension with a valid CRL 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 unexpected 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. Government CAs must restrict server authentication to government-issued top level domains and may only issue 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»). These government-issued TLDs are referred to in each CA’s respective contract.
8. Issuing CA certificates that chain to a participating Root CA must be constrained to a single EKU (e.g., separate Server Authentication, S/MIME, Code Signing, and Time Stamping uses. This means that a single Issuing CA must not combine server authentication with S/MIME, code signing or time stamping EKU. A separate intermediate must be used for each use case.
9. 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 located at https://cabforum.org/baseline-requirements-documents/.
10. CAs must declare one of the following policy OIDs in its Certificate Policy extension end-entity certificate:
    1. DV 2.23.140.1.2.1
    2. OV 2.23.140.1.2.2
    3. EV 2.23.140.1.1.
    4. IV 2.23.140.1.2.3
    5. EV Code Signing 2.23.140.1.3
    6. Non-EV Code Signing 2.23.140.1.4.1
11. 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.
12. A CA must technically constrain an OCSP responder such that the only EKU allowed is OCSP Signing.

B. Key Requirements

C. Revocation Requirements

1. The CA must have a documented revocation policy and must have the ability to revoke any certificate it issues.
2. CAs that issue Server Authentication certificates must support the following OCSP responder requirements:
   1. Minimum validity of eight (8) hours; Maximum validity of seven (7) days; and
   2. The next update must be available at least eight (8) hours before the current period expires. If the validity is more than 16 hours, then the next update must be available at ВЅ of the validity period.
3. All certificates issued from a root CA must support either the CRL distribution point extension and/or AIA containing an OCSP responder URL.
4. The CA must not use the root certificate to issue end-entity certificates.
5. If a CA issues Code Signing certificates, it must use a Time Stamp Authority that complies with RFC 3161, «Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP).»

D. Code Signing Root Certificate Requirements

1. New root CAs that support code-signing infrastructure must be signed with using the SHA2 hashing algorithm.
2. Root certificates that support code signing use may be removed from distribution by the Program 10 years from the date of distribution of a replacement rollover root certificate or sooner, if requested by the CA.
3. 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) may be set to ‘disable’ in the Windows 10 OS.

E. EKU Requirements

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

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. Document Signing EKU=1.3.6.1.4.1.311.10.3.12

• This EKU is used for signing documents within Office. It is not required for other document signing uses.

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

Windows 10 has heightened requirements to validate kernel-mode drivers.В Drivers must be signed by both Microsoft and a Program partner using Extended Validation requirements.В В All developers who wish to have their kernel-mode drivers included in Windows must follow the procedures outlined by the Microsoft Hardware Development Team.В Program documentation can be found here

4. Technical Best Practices

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

Источник

Updating List of Trusted Root Certificates in Windows 10/8.1/7

All Windows versions have a built-in feature for automatically updating root certificates from the Microsoft websites. As part of the Microsoft Trusted Root Certificate Program, MSFT maintains and publishes a list of certificates for Windows clients and devices in its online repository. If the verified certificate in its certification chain refers to the root CA that participates in this program, the system will automatically download this root certificate from the Windows Update servers and add it to the trusted ones.

Windows requests a trusted root certificate lists (CTL) renewal once a week. If Windows doesn’t have a direct access to the Windows Update directory, the system won’t be able to update the root certificates, so a user may have some troubles when browsing websites (which SSL certificates are signed by an untrusted CA – see the article about the “Chrome SSL error: This site can’t provide a secure connection”), or with installing/running signed scripts and apps.

In this article, we’ll try to find out how to manually update the list of root certificates in TrustedRootCA on isolated networks or computers/servers without a direct Internet connection.

Managing Trusted Root Certificates in Windows 10

How to see the list of root certificates of a Windows computer?

1. To open the root certificate store of a computer running Windows 10/8.1/7/Windows Server, start the mmc.exe console;
2. Select File ->Add/Remove Snap-in, select Certificates (certmgr) in the list of snap-ins ->Add;
3. Select that you want to manage certificates of local Computer account;
4. Next -> OK -> OK;
5. Expand the Certificates node ->TrustedRootCertificationAuthoritiesStore. This section contains the list of trusted root certificates on your computer.

You can also get a list of trusted root certificates with expiration dates using PowerShell:

Get-Childitem cert:\LocalMachine\root |format-list

You can list the expired certificates, or which expire in the next 30 days:

Get-ChildItem cert:\LocalMachine\root | Where

In the mmc console, you can view information about any certificate or remove it from trusted ones.

You can manually transfer the root certificate file between Windows computers using the Export/Import function.

1. You can export any certificate to a .CER file by clicking on it and selecting All Tasks -> Export;
2. You can import this certificate on another computer using the option All Tasks -> Import.

Rootsupd.exe Utility

In Windows XP, the rootsupd.exe utility was used to update computer`s root certificates. The list of root and revoked certificates in it was regularly updated. The utility was distributed as a separate update KB931125 (Update for Root Certificates). Let’s see if we can use it now.

1. Download the rootsupd.exe utility using the following link http://download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/rootsupd.exe . At the moment (August 2, 2019) the link doesn’t work, maybe Microsoft decided to remove it from the public. Today you can download the rootsupd.exe from kaspersky.com website — http://media.kaspersky.com/utilities/CorporateUtilities/rootsupd.zip ;
2. To install the Windows root certificates, just run the rootsupd.exe file. But we will try to examine its contents more carefully. Extract the certificates from the executable file with the command: rootsupd.exe /c /t: C:\PS\rootsupd
3. Certificates are stored in SST files, like authroots.sst, delroot.sst, etc. To delete/install a certificate, you can use the following commands:
   updroots.exe authroots.sst
   updroots.exe -d delroots.sst

However, as you can see, these certificate files were created on April 4, 2013 (almost a year before the end of official support of Windows XP). Thus, since then the utility has not been updated and cannot be used to install up-to-date certificates. A little later we will need the updroots.exe file.

Certutil: Getting Latest Root Certificates from Windows Update

The latest version of the Certutil.exe tool for managing certificates (available in Windows 10), allows you to download from Windows Update and save the actual root certificates list to the SST file.

To generate an SST file, run this command with the administrator privileges on a computer running Windows 10 and having a direct access to the Internet:

certutil.exe -generateSSTFromWU roots.sst

As a result, an SST file containing up-to-date list of root certificates will appear in the target directory. Double-click to open it. This file is a container containing trusted root certificates.

As you can see, a familiar Certificate Management snap-in opens, from which you can export any of the certificates you have got. In my case, there have been 358 items in the list of certificates. Obviously, it is not rational to export the certificates and install them one by one.

To install all the certificates from the SST file and add them to the list of trusted root certificates on a computer, you can use the PowerShell commands:

$sstStore = ( Get-ChildItem -Path C:\ps\rootsupd\roots.sst )
$sstStore | Import-Certificate -CertStoreLocation Cert:\LocalMachine\Root

To install all certificates listed in the file, use the updroots.exe (it is located in the rootsupd.exe file, which was extracted in the previous section).

Run the certmgr.msc snap-in and make sure that all certificates have been added to the Trusted Root Certification Authority.

The List of Root Certificates in STL Format

There is another way to get the list of root certificates from Microsoft website. To do it, download the file http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab (updated twice a month). Using any archiver (or even Windows Explorer) unpack authrootstl.cab. It contains one file authroot.stl.

The Authroot.stl file is a container with a list of trusted certificates in Certificate Trust List format.

You can install this file in the system using the context menu of the STL file (Install CTL).

Or using certutil.exe tool:

certutil -addstore -f root authroot.stl

You can also import certificates using the certificate management console (Trust Root Certification Authorities -> Certificates -> All Tasks -> Import). Specify the path to your STL file with certificates.

After you have run the command, a new section Certificate Trust List appears in Trusted Root Certification Authorities container of the Certificate Manager console (certmgr.msc).

In the same way, you can download and install the list of the revoked (disallowed) certificates that have been removed from Root Certificate Program. To do it, download disallowedcertstl.cab (http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/disallowedcertstl.cab), unpack it and add to the Untrusted Certificates section using this command:

certutil -addstore -f disallowed disallowedcert.stl

Updating Root Certificates in Windows with GPO in an Isolated Environment

If you have the task of regularly updating root certificates in an Internet-isolated Active Directory domain, there is a slightly more complicated scheme for updating local certificate stores on domain joined computers using Group Policies. You can configure root certificate updates on user computers in the isolated Windows networks in several ways.

The first way assumes that you regularly manually download and copy to your isolated network a file with root certificates obtained as follows:

certutil.exe –generateSSTFromWU roots.sst

Then the certificates from this file can be distributed via SCCM or PowerShell logon script in GPO:

$sstStore = (Get-ChildItem -Path \\fr-dc01\SYSVOL\woshub.com\rootcert\roots.sst )
$sstStore | Import-Certificate -CertStoreLocation Cert:\LocalMachine\Root

The second way is to obtain the actual root certificates using the command:

Certutil -syncWithWU -f \\fr-dc01\SYSVOL\woshub.com\rootcert\

A number of root certificate files (CRT file format) will appear in the specified network shared folder, including files (authrootstl.cab, disallowedcertstl.cab, disallowedcert.sst, thumbprint.crt).

Then, using Group Policy Preference, you need to change the value of the RootDirURL parameter in the registry key HKLM\Software\Microsoft\SystemCertificates\AuthRoot\AutoUpdate. This parameter should point to the shared network folder from which your Windows computers should receive new root certificates. Run the domain GPMC console, create a new GPO, switch to the edit policy mode and expand the section Computer Configuration -> Preferences -> Windows Settings -> Registry. Create a new registry property with the following settings:

• Action: Update
• Hive: HKLM
• Key path: Software\Microsoft\SystemCertificates\AuthRoot\AutoUpdate
• Value name: RootDirURL
• Type: REG_SZ
• Value data: file://\\fr-dc01\SYSVOL\woshub.com\rootcert\

It remains to link this policy on a computer`s OU and after updating the policies to check for new root certificates in the certstore.

In this article, we looked at several ways to renew trusted root certificates on a Windows network that is isolated from the Internet.

Источник