Skip to main content

PKI and Root Certificate Rotation

NOTE​

This document is a machine translation of the Japanese version.

Overview​

In PKI (Public Key Infrastructure), which supports secure connections to web services (HTTPS), root certificate rotation is a critical event that impacts client environments. This article explains the mechanism and necessary actions, using the migration to "DigiCert Global Root G2" by Salesforce as a case study.

Core Technologies​

What is PKI (Public Key Infrastructure)?​

PKI (Public Key Infrastructure) is a framework that uses public-key cryptography to ensure secure communication and identity verification over the internet. PKI consists of the following key components:

  • Public and Private Keys: A pair of keys used for encryption and signature verification.
  • Digital Certificate: An electronic credential that proves "who owns" the public key.
  • Certificate Authority (CA): A trusted third-party entity that issues digital certificates and guarantees their validity. It acts as the anchor of trust.
  • Repository: A location where certificates and Certification Revocation Lists (CRLs) are published and stored.

PKI enables secure information exchange by preventing "spoofing," "tampering," and "repudiation."

Chain of Trust​

In SSL/TLS communication, the "Chain of Trust" is verified to prove that a server certificate is legitimate.

  1. Root CA: The anchor of trust. Pre-installed in OS or browsers.
  2. Intermediate CA: Signed by the Root CA.
  3. Server Certificate: Signed by the Intermediate CA.

When a client is presented with a server certificate, it traces the signatures up the chain. If it ultimately matches a Root CA present in its own trust store, the communication is allowed.

What is Root Certificate Rotation?​

It involves switching to a new root certificate due to the expiration of the root certificate authority or changes in security standards.

  • Server-side changes: Replacing the certificate chain with one that is rooted under the new Root CA.
  • Client-side impact: In older devices or environments (e.g., old Java versions, old OSs) that do not possess the new Root CA certificate, an SSL Handshake Error will occur, preventing connection.

Maintenance Points​

When a root certificate switch is announced, the following "trust stores" need to be checked.

Environments to Check​

Environment TypeCheck ContentNotes
Client PC/BrowserOS/Browser update statusUsually updated automatically on the latest Windows/Mac/Chrome, etc.
Java (JDK/JRE)cacerts fileJava has a keystore independent of the OS, so caution is required.
Docker ContainersBase image OSOld Alpine/Ubuntu images may have outdated certificates (ca-certificates package).
Legacy SystemsOS patch application statusNew root certificates might not be distributed to OSs that are out of support.

Salesforce Case Study (Migration to DigiCert Global Root G2)​

On February 5, 2026, Salesforce will change its certificate chain to one rooted in "DigiCert Global Root G2".

Required Actions​

Check if "DigiCert Global Root G2" is included in the trust store of the client environment. Note that the migration is to G2, not DigiCert Global Root G3.

  • Browsers: Major browsers are already compatible.
  • API Integration: If connecting via API from custom Java environments or older Linux servers, verification of the certificate store is necessary.

Implementation Guide (.NET)​

Guidelines for handling verification when using Salesforce APIs from a .NET backend, by environment.

Certificate Verification in .NET​

.NET (System.Net.Http.HttpClient) basically uses the OS certificate store for verification. If the OS trust store contains the new root certificate, no code changes are usually required.

Environment-Specific Actions​

  1. Windows / Azure VM: Automatically updated via Windows Update. Manual import is required for closed networks.
  2. Linux / Docker: Update the ca-certificates package. 
    # Dockerfile example (Debian/Ubuntu)
    RUN apt-get update && apt-get install -y ca-certificates
  3. Azure PaaS (App Service/Functions): Managed and updated by Microsoft at the platform level, so no action is required.

Verifying Certificate Existence​

Example commands to check if "DigiCert Global Root G2" exists in the trust store.

Windows (PowerShell):

Get-ChildItem Cert:\LocalMachine\Root | Where-Object { $_.Subject -like "*DigiCert Global Root G2*" }

Linux (Debian/Ubuntu/Alpine): Check if it is included in /etc/ssl/certs/ca-certificates.crt.

grep "DigiCert Global Root G2" /etc/ssl/certs/ca-certificates.crt

Code Considerations (Certificate Pinning)​

If you are performing Certificate Pinning (e.g., fixed Thumbprint checks) in your application, modification is mandatory.

// [NG] Hardcoding old thumbprints will cause connection failures
if (cert.Thumbprint == "OLD_THUMBPRINT...") return false;

References​