Downloading and Installing a Root Certificate
A root certificate is a digital certificate issued by a trusted certificate authority (CA). As the root node of the certificate trust chain, it is used to verify the authenticity of all lower-level certificates (including intermediate certificates and server certificates) issued by the CA. It is the foundation of the client trust system.
- You do not need to manually configure the root certificate in the following scenarios: If users access your web services through the JDK environment, mainstream browsers (such as Google Chrome, Mozilla Firefox, and Microsoft Edge), or OSs (such as Windows, macOS, Android, and iOS), you do not need to pay attention to the root certificate because the root certificate is embedded in the web server. You only need to install the SSL certificate issued by the CA on the web server to implement HTTPS communication between the client and server.
- You need to manually install the root certificate in the following scenario: If users access your web services through a Java client, download the root certificate and manually install it on the client because the client does not have a built-in root certificate. This ensures that the client can verify the encryption information of your web server. Otherwise, the connection may fail or an alarm indicating that the connection is insecure may be displayed. For example, if a GeoTrust EV SSL certificate is installed on your web server, the GeoTrust EV root certificate must be installed on the client to implement HTTPS communication between the client and server. For details about the scenarios where you need to manually install the root certificate on the client, see Table 1.
After the root certificate is installed on the client, an insecure connection warning may appear, or access may fail due to causes such as root certificate expiration or a policy change. You are advised to download the root certificate, install it in the default trust store of the system, and use the trust store to verify the client.
| Client Environment | Scenario |
|---|---|
| Java client | Certificate trust relies on an independent Java keystore (cacerts), which is decoupled from the system trust store. The corresponding root certificate must be installed on the client so that the server can verify the SSL certificate. |
| IoT devices and embedded systems | IoT devices and embedded systems have limited resources and only a small number of built-in trusted root certificates. Therefore, you need to install corresponding root certificates to enable HTTPS communication. |
| Mobile applications | Mobile applications use a custom trust store and do not synchronize with the global trusted root certificates of the system and browser. These applications cannot properly parse HTTPS service certificates to establish encrypted connections unless the matching root certificates are manually installed. |
| Enterprise intranet environment | Enterprise intranets use private CAs to issue certificates. The root certificates of these CAs are not included in the public trust store. HTTPS services cannot be accessed unless the matching root certificates are installed. |
| Browsers or operating systems of an earlier version | Old systems such as Windows XP and Android 4.x do not have new root certificates built in. You need to manually install the root certificates to complete the certificate trust chain. |
| Special security and compliance requirements | Some industries need to manage and customize their list of trusted CAs through a trustlist to comply with industry standards and enterprise security control policies. |
Constraints
Your customers access your web services through clients such as Java.
Download Links
Currently, only the following types of root certificates can be downloaded.
| Certificate Authority | Root Certificate Download Address |
|---|---|
| DigiCert | |
| DigiCert | |
| DigiCert | |
| GeoTrust | |
| GeoTrust | |
| GlobalSign |
Installing a Root Certificate
The following uses Windows 10 as an example to describe how to install a root certificate.
- On the Windows 10 desktop, press Windows + R to open the Run dialog box. Enter mmc. Figure 1 Run dialog box
- Click OK. The Microsoft Management Console (MMC) is displayed.
- On the menu bar of the console, choose File > Add/Remove Snap-ins. Figure 2 Add or remove snap-ins
- Select Certificates from the Available Snap-ins list on the left, click Add, and click OK. Figure 3 Adding a certificate
- In the displayed Certificates snap-in dialog box, select Computer account and click Next.
- In the Select Computer dialog box, select Local computer: (the computer this console is running on) and click Finish.
- In the navigation tree on the left of the MMC console, click Certificates (Local Computer), right-click the target directory (for example, Enterprise Trust), and choose All Tasks > Import from the shortcut menu. Figure 4 Enterprise trust
- Import the certificate as prompted.

Security Risk Precautions
- Certificate source security risk: Root certificates can be obtained only from official, authoritative, and trusted channels. If an unverified root certificate from an unknown source is installed, it is highly likely to introduce malware and trigger man-in-the-middle attacks, posing a threat to the security of the entire system.
- Certificate deployment error risks: If a certificate is imported into an incorrect storage directory or the format of the uploaded file is invalid, the integrity of the system trust chain may be compromised, causing SSL or TLS connection exceptions and access interruptions for service applications.
Maintenance Cost Precautions
- Replacement cost: Each root certificate has a validity period. After a root certificate expires or the CA replaces the root certificate, certificates on the client must be updated accordingly to maintain the normal trust chain.
- Upgrade cost: Legacy systems and applications incompatible with new root certificate algorithms and specifications need to be upgraded, which incurs additional cost.
- Batch deployment cost: When there are a large number of heterogeneous devices or clients, manually installing the root certificate on each device is inefficient and prone to human error. To reduce manual P&M costs, you can use automated scripts and device configuration management tools for batch deployment and centralized maintenance.
FAQ
Do I Need to Redeploy the Root Certificate When My SSL Certificate Expires?
- Scenario 1: Manual deployment is not required.
If the SSL certificate is issued by a public and trusted CA and the corresponding root certificate has been pre-installed in the trust stores of mainstream operating systems and browsers, there is no need to deploy the certificate manually. When a CA updates the root certificate through routine updates, the system and browser automatically synchronize the root certificate through their built-in update channels. In this case, manual deployment is not required.
- Scenario 2: Manual deployment is required.
For terminal environments without built-in trusted root certificates, you need to manually deploy the root certificate in the following scenarios (for details about terminal environments, see Table 1):
- The CA or the certificate type (DV, OV, or EV) for a newly purchased SSL certificate has been changed.
- The original root certificate has expired or the CA has enabled a new root certificate system.
What is your overall rating for this page?
Thank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot