Installing the trusted root certificate

Applies to: Lync Server 2013 | Skype for Business 2015

Installing a trusted root certificate is necessary only if you are notified that the certificate of authority is not trusted on any machine. This can occur when you use a private or custom certificate server instead of acquiring certificates from an established public certificate of authority.

Installing a trusted root certificate

On the machine that requires a certificate, in your web browser, navigate to your local certification server. This should be the same certificate of authority used for generating the server and, optionally, client certificates.

Choose Download a CA certificate, certificate chain, or CRL link, as needed.

Select the appropriate certificate of authority from the list and choose the Base 64 Encoding method.

Choose the Download CA certificate link and then choose Open option when prompted to open or save the certificate.

When the certificate window opens, choose Install Certificate…. The Certificate Import wizard appears.

In the wizard, choose Next. Then, when you are prompted for the Certificate Store, choose Place all certificates in the following store. Select the Trusted Root Certification Authorities store.

Complete the remaining steps of the wizard and click Finish.

Upon completing the wizard, you next want to add the certificate snap-ins using the Microsoft Management Console (MMC).

Adding certificate snap-ins

Launch MMC (mmc.exe).

Choose File > Add/Remove Snap-ins.

Choose Certificates, then choose Add.

Choose My user account.

Choose Add again and this time select Computer Account.

Move the new certificate from the Certificates-Current User > Trusted Root Certification Authorities into Certificates (Local Computer) > Trusted Root Certification Authorities.

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.

Required trusted root certificates

This article lists the trusted root certificates that are required by Windows operating systems. These trusted root certificates are required for the operating system to run correctly.

Original product version: В Windows 7 Service Pack 1, Windows Server 2012 R2
Original KB number: В 293781

Summary

As part of a public key infrastructure (PKI) trust management procedure, some administrators may decide to remove trusted root certificates from a Windows-based domain, server, or client. However, the root certificates that are listed in the Necessary and trusted root certificates section in this article are required for the operating system to operate correctly. Removal of the following certificates may limit functionality of the operating system, or may cause the computer to fail. Don’t remove them.

Necessary and trusted root certificates

The following certificates are necessary and trusted in:

• Windows 7
• Windows Vista
• Windows Server 2008 R2
• Windows Server 2008

Issued to	Issued by	Serial number	Expiration date	Intended purposes	Friendly name	Status
Microsoft Root Authority	Microsoft Root Authority	00c1008b3c3c8811d13ef663ecdf40	12/31/2020	All	Microsoft Root Authority	R
Thawte Timestamping CA	Thawte Timestamping CA	00	12/31/2020	Time Stamping	Thawte Timestamping CA	R
Microsoft Root Certificate Authority	Microsoft Root Certificate Authority	79ad16a14aa0a5ad4c7358f407132e65	5/9/2021	All	Microsoft Root Certificate Authority	R

The follow certificates are necessary and trusted in Windows XP and in Windows Server 2003:

Issued to	Issued by	Serial number	Expiration date	Intended purposes	Friendly name	Status
Copyright (c) 1997 Microsoft Corp.	Copyright (c) 1997 Microsoft Corp.	01	12/30/1999	Time Stamping	Microsoft Timestamp Root	R
Microsoft Authenticode(tm) Root Authority	Microsoft Authenticode(tm) Root Authority	01	12/31/1999	Secure E-mail, Code Signing	Microsoft Authenticode(tm) Root	R
Microsoft Root Authority	Microsoft Root Authority	00c1008b3c3c8811d13ef663ecdf40	12/31/2020	All	Microsoft Root Authority	R
NO LIABILITY ACCEPTED, (c)97 VeriSign, Inc.	NO LIABILITY ACCEPTED, (c)97 VeriSign, Inc.	4a19d2388c82591ca55d735f155ddca3	1/7/2004	Time Stamping	VeriSign Time Stamping CA	R
VeriSign Commercial Software Publishers CA	VeriSign Commercial Software Publishers CA	03c78f37db9228df3cbb1aad82fa6710	1/7/2004	Secure E-mail, Code Signing	VeriSign Commercial Software Publishers CA	R
Thawte Timestamping CA	Thawte Timestamping CA	00	12/31/2020	Time Stamping	Thawte Timestamping CA	R
Microsoft Root Certificate Authority	Microsoft Root Certificate Authority	79ad16a14aa0a5ad4c7358f407132e65	5/9/2021	All	Microsoft Root Certificate Authority	R

The follow certificates are necessary and trusted in Microsoft Windows 2000:

Issued to	Issued by	Serial number	Expiration date	Intended purposes	Friendly name	Status
Copyright (c) 1997 Microsoft Corp.	Copyright (c) 1997 Microsoft Corp.	01	12/30/1999	Time Stamping	Microsoft Timestamp Root	R
Microsoft Authenticode(tm) Root Authority	Microsoft Authenticode(tm) Root Authority	01	12/31/1999	Secure E-mail, Code Signing	Microsoft Authenticode(tm) Root	R
Microsoft Root Authority	Microsoft Root Authority	00c1008b3c3c8811d13ef663ecdf40	12/31/2020	All	Microsoft Root Authority	R
NO LIABILITY ACCEPTED, (c)97 VeriSign, Inc.	NO LIABILITY ACCEPTED, (c)97 VeriSign, Inc.	4a19d2388c82591ca55d735f155ddca3	1/7/2004	Time Stamping	VeriSign Time Stamping CA	R
VeriSign Commercial Software Publishers CA	VeriSign Commercial Software Publishers CA	03c78f37db9228df3cbb1aad82fa6710	1/7/2004	Secure E-mail, Code Signing	VeriSign Commercial Software Publishers CA	R
Thawte Timestamping CA	Thawte Timestamping CA	00	12/31/2020	Time Stamping	Thawte Timestamping CA	R

Some certificates that are listed in the previous tables have expired. However, these certificates are necessary for backward compatibility. Even if there’s an expired trusted root certificate, anything that was signed by using that certificate before the expiration date requires that the trusted root certificate is validated. As long as expired certificates aren’t revoked, they can be used to validate anything that was signed before their expiration.

Support for urgent Trusted Root updates for Windows Root Certificate Program in Windows

This article describes an update that enables urgent updates for the Windows Root Certificate Program in Windows 8.1, Windows RT 8.1, Windows Server 2012 R2, Windows 8, Windows RT, Windows Server 2012, Windows 7, and Windows Server 2008 R2. Before you apply this update, see more about this update and check out the prerequisites in this article.

About this update

The Windows Root Certificate Program enables trusted root certificates to be distributed automatically in Windows. Usually, a client computer polls root certificate updates one time a week. After you apply this update, the client computer can receive urgent root certificate updates within 24 hours.

Known issue

After you apply this update, you may encounter error 0x800706f7 when you run Windows Update.

Resolution
To resolve this issue, install update 3024777.

How to obtain this update

Method 1: Windows Update

This update is available from Windows Update.

Method 2: Microsoft Download Center

The following files are available for download from the Microsoft Download Center.

All supported x86-based versions of Windows 8.1

Download the package now.

All supported x64-based versions of Windows 8.1

Download the package now.

All supported x64-based versions of Windows Server 2012 R2

Download the package now.

All supported x86-based versions of Windows 8

Download the package now.

All supported x64-based versions of Windows 8

Download the package now.

All supported x64-based versions of Windows Server 2012

Download the package now.

All supported x86-based versions of Windows 7

Download the package now.

All supported x64-based versions of Windows 7

Download the package now.

All supported x64-based versions of Windows Server 2008 R2

Download the package now.

All supported IA-64-based versions of Windows Server 2008 R2

Download the package now.

The update installer should be run from an elevated command prompt.

The update for Windows RT 8.1 or Windows RT can be obtained only from Windows Update.

For more information about how to download Microsoft support files, click the following article number to view the article in the Microsoft Knowledge Base:

119591 How to obtain Microsoft support files from online services Microsoft scanned this file for viruses. Microsoft used the most current virus-detection software that was available on the date that the file was posted. The file is stored on security-enhanced servers that help prevent any unauthorized changes to the file.

Method 3: Update rollup for Windows 8.1, Windows RT 8.1, Windows Server 2012 R2, Windows 8, Windows RT, or Windows Server 2012

Install one of the following update rollup packages that are dated December 2014:

Note The update rollup fixes many other issues in addition to the issue that the stand-alone update fixes. The update rollup is larger than the stand-alone update. Therefore, the update rollup takes longer to download.

Update information

Prerequisites

To install this update, you must install update 2919355 in Windows 8.1 or Windows Server 2012 R2. Or, install Service Pack 1 for Windows 7 or Windows Server 2008 R2.

Registry information

To apply this update, you do not have to make any changes to the registry.

Restart requirement

You may have to restart the computer after you apply this update.

Update replacement information

This update does not replace a previously released update.

More Information

For more information, see the following articles in the Microsoft Knowledge Base:

The global version of this update installs files that have the attributes that are listed in the following tables. The dates and the times for these files are listed in Coordinated Universal Time (UTC). The dates and the times for these files on your local computer are displayed in your local time together with your current daylight saving time (DST) bias. Additionally, the dates and the times may change when you perform certain operations on the files.

Windows 8.1 and Windows Server 2012 R2 file information and notes

The files that apply to a specific product, milestone (RTM, SP n), and service branch (LDR, GDR) can be identified by examining the file version numbers as shown in the following table.

Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2

The MANIFEST files (.manifest) and the MUM files (.mum) that are installed for each environment are not listed.

For all supported x86-based versions of Windows 8.1