Salesforce Infrastructure Advisory: 2026 Certificate and Root Authority Migrations

In early 2026, the cybersecurity landscape implemented three critical infrastructure shifts: a 200-day maximum validity period for public TLS certificates, Salesforce’s migration to a new identity trust anchor (DigiCert Global Root G2), and the deprecation of dual-use certificates for Mutual TLS (mTLS) and Single Sign-On (SSO).

For organisations managing external Salesforce integrations and identity access, these concurrent updates introduce significant operational risk across different architectural layers. This advisory delineates the necessary remediation steps for Salesforce Administrators and the technical validation required from enterprise IT and DevOps teams to ensure operational continuity.

---

Executive Summary: Critical Action Deadlines

Organisations are currently operating within the active transition window for these mandates. Immediate validation is required to prevent integration and authentication failures.

• The 200-Day Validity Mandate (Effective 15 March 2026): Publicly trusted certificates issued on or after this date are restricted to a 200-day lifespan. Organisations must transition custom domains to automated renewal protocols (e.g., ACME or Salesforce CDN) immediately to mitigate the risk of lapsed certificates.
• The G2 Root Authority Migration (Actively Deploying): Salesforce commenced its platform-wide certificate rotation on 5 February 2026. This is a phased deployment. If external middleware environments (Azure/AWS) lack the corresponding G2 root trust, connectivity will drop asynchronously as Salesforce updates individual server pods.
• Dual-Use Certificate Deprecation (Effective 15 June 2026 / Immediate Audit Required): Industry root programs are enforcing cryptographic key separation. Certificates can no longer be used for both Server and Client authentication simultaneously in mTLS, nor for both signing and encrypting operations within SAML SSO configurations.

---

Part 1: The 200-Day Certificate Validity Mandate

Industry standards now prohibit the issuance of long-term public certificates, rendering manual procurement and installation processes operationally unsustainable.

1. Architectural Exemptions (JWT Bearer Flows)

Integrations utilising the JWT Bearer Flow rely on private key pairs uploaded directly to a Salesforce Connected App. Because these are self-managed and not subject to public Certificate Authority (CA) validation, they are exempt from the 200-day mandate. Organisations may maintain their existing rotation schedules for these specific assets.

2. Responsibility Matrix for Domain Architectures

The operational burden of the 200-day rule depends on the specific URL architecture routing traffic to or from Salesforce:

• Standard Salesforce Domains (*.my.salesforce.com,*.force.com): Salesforce manages the TLS lifecycle for these endpoints automatically. No administrative action is required.
• Custom Domains (api.yourcompany.com or portal.yourcompany.com): Remediation responsibilities vary based on the hosting infrastructure.

Scenario A: Experience Cloud and Salesforce Sites

If a custom domain is hosted directly on the Salesforce platform, it falls under the purview of the Salesforce Administrator.

• The Vulnerability: Configurations utilising the Setup > Domains option to “Upload a CA-Signed Certificate” require manual intervention. Under the new mandate, this process must be repeated bi-annually, introducing high operational risk.
• The Technical Constraint: Standard automated certificate management (ACME) clients, such as Certbot, require direct file-system access to validate domain ownership. Because Salesforce restricts foundational server access, external automation tools cannot interface with the manual upload menu.
• The Remediation: Administrators must transition to platform-native automation. Navigate to the domain settings and select “A Salesforce content delivery network (CDN) partner serves the domain” (or the Salesforce-managed Let’s Encrypt option). This delegates the ACME protocol execution to Salesforce, ensuring automated compliance.

sequenceDiagram
    autonumber
    participant Client as ACME Client (e.g., Certbot / Salesforce CDN)
    participant ACME as ACME Server (e.g., Let's Encrypt)
    participant Domain as Web Server / DNS Provider

    Note over Client, ACME: Phase 1: Domain Authorisation
    Client->>ACME: Request Certificate for api.yourcompany.com
    ACME-->>Client: Issue Challenge (e.g., HTTP-01 or DNS-01) & Token

    Note over Client, Domain: Phase 2: Challenge Provisioning
    Client->>Domain: Provision Challenge Token (Place file or TXT record)
    Client->>ACME: Notify ACME Server that challenge is ready

    Note over ACME, Domain: Phase 3: Challenge Verification
    ACME->>Domain: Verify Challenge (HTTP GET or DNS Lookup)
    Domain-->>ACME: Return Token
    ACME-->>Client: Validation Successful

    Note over Client, ACME: Phase 4: Certificate Issuance
    Client->>ACME: Send Certificate Signing Request (CSR)
    ACME-->>Client: Issue & Return Signed Certificate

    Note over Client, Domain: Phase 5: Deployment
    Client->>Domain: Install / Apply New Certificate securely

Scenario B: External Middleware Services (Azure/AWS)

If a custom domain routes to an external integration server (e.g., Azure API Management, MuleSoft), the enterprise IT/DevOps team is responsible for compliance.

• The Vulnerability: Outbound REST/SOAP callouts from Salesforce will validate the external server’s certificate. Manually provisioned 1-year certificates will no longer be issued.
• The Remediation: IT teams must implement an ACME client protocol (such as Azure Managed Certificates or Certbot) at the infrastructure level to automate the lifecycle of the middleware’s TLS certificates.

Responsibility and Remediation Matrix:

Custom Domain Endpoint	Hosting Environment	Remediation Protocol
Experience Cloud Site (Manual Upload)	Salesforce Platform	Administrator Action Required - MANUAL: High risk of expiry. Requires bi-annual manual procurement.
Experience Cloud Site (CDN/Managed)	Salesforce Platform	Compliant - AUTOMATED: Salesforce manages the lifecycle natively.
Middleware / API Gateway	Azure / AWS	IT/DevOps Action Required - AUTOMATED: Must configure infrastructure-level ACME automation.

---

Part 2: The DigiCert G2 Root Authority Migration

At the transport layer, Salesforce is updating the TLS handshake protocol to establish identity via the DigiCert Global Root G2. If the internal Trust Store of an external server (Azure/AWS) does not recognise this root authority, the TLS handshake will fail, terminating the integration.

3. Validation Testing Protocol: Utilising Microsoft as a Proxy

While Salesforce is actively upgrading its infrastructure, external environments must independently establish trust with the new root authority. Because the Salesforce rollout is phased, testing directly against current Salesforce endpoints may yield inconsistent validation.

To ensure deterministic testing, we recommend utilising Microsoft Entra ID as a validation proxy. Microsoft completed its G2 migration in January 2026 and utilises the exact same DigiCert Global Root G2 hierarchy required by Salesforce.

Validation Execution (For IT & DevOps Teams): This protocol must be executed from the terminal of the specific integration server, not from a local workstation or general cloud shell.

Execution Steps for Azure App Services (Web Apps / APIs):

1. Authenticate to the Azure Portal (portal.azure.com) and navigate to App Services.
2. Select the specific resource handling Salesforce traffic.
3. Under Development Tools, select Console (Windows) or SSH (Linux).
4. Execute the validation command: curl -v https://login.microsoftonline.com

Execution Steps for Azure Virtual Machines (VMs):

1. Authenticate to the Azure Portal and navigate to Virtual machines.
2. Select the target VM.
3. Under Operations, select Run command.
4. Select RunShellScript (Linux) or RunPowerShellScript (Windows).
5. Input the validation command curl -v https://login.microsoftonline.com and select Run.

Interpreting the Output:

Status	Standard Output Signature	Diagnostic Conclusion
PASS ✅	A successful TLS handshake (e.g., no SSL errors, SSL connection established, and an HTTP 200 or 302 response).	The environment recognises the G2 Root. Ready for Salesforce migration.
FAIL ❌	Explicit TLS/SSL handshake failures (e.g., curl: (60) SSL certificate problem or unable to get local issuer certificate).	Trust anchor missing. Immediate remediation of the OS certificate bundle is required.

4. Risk Matrix by Hosting Environment

Standardisation varies across cloud compute models. IT teams should reference this matrix to identify high-risk assets:

Architecture	Risk Level	Diagnostic Context
Java / MuleSoft	Critical	Java runtimes utilise an isolated keystore (cacerts), bypassing OS-level updates.
Custom Docker Images	Critical	Trust configurations are immutable post-build. Images require recompilation.
Windows/Linux VMs	Medium	Susceptible to enterprise Group Policy Objects (GPOs) or firewalls blocking automated root updates.
Azure/AWS Functions	Low	Fully managed PaaS. The provider maintains the underlying trust stores.

5. Specialised Remediation: Isolated Java Keystores (cacerts)

For infrastructures leveraging Java-based middleware (e.g., Spring Boot, MuleSoft), OS-level validation is insufficient. Java maintains an isolated repository of trusted certificate authorities known as the cacerts file.

IT personnel must explicitly verify the presence of the DigiCert Global Root G2 within this keystore.

Verification Command: keytool -list -v -keystore $JAVA_HOME/lib/security/cacerts -alias digicertglobalrootg2 (Note: Standard keystore authentication applies; the default credential is changeit).

Output Analysis:

• Compliant Signature (Pass): The command returns the certificate properties, confirming the correct Issuer and Owner data.

  Alias name: digicertglobalrootg2 Owner: CN=DigiCert Global Root G2, O=DigiCert Inc, C=US

• Non-Compliant Signature (Fail): The command yields an exception indicating the alias is absent.

  keytool error: java.lang.Exception: Alias <digicertglobalrootg2> does not exist (Action: Integration failure is imminent upon Salesforce deployment).

Remediation Protocol: If the environment fails validation, a full Java runtime environment (JRE) upgrade is not strictly necessary. IT administrators must manually acquire the DigiCertGlobalRootG2.crt from the authoritative DigiCert repository and inject it into the cacerts file utilising the keytool -import directive.

---

Part 3: Deprecation of Dual-Use Certificates (mTLS and SAML)

In alignment with modern cryptographic best practices and updated browser root program policies, the industry is enforcing strict key separation. The practice of utilising a single “dual-use” certificate for multiple cryptographic purposes is being deprecated across two distinct architectural layers.

6. The Mutual TLS (mTLS) Client Authentication Ban

Effective 15 June 2026, the Google Chrome Root Program Policy (v1.7) and the broader Certificate Authority and Browser Forum (CABF) are banning the use of multi-purpose public certificates for client-side identification.

• The Vulnerability: Historically, IT departments would procure a standard public SSL/TLS certificate - typically designed to verify a website’s identity (Server Authentication) - and deploy it on an integration server to also verify the client’s identity (Client Authentication) during inbound Salesforce API calls. Following the June deadline, certificates containing both Extended Key Usages (EKUs) will be rejected during the mTLS handshake.

Diagnostic Protocol for Dual-Use Identification

IT architecture teams must audit their mTLS configurations within the Salesforce Certificate and Key Management setup to identify non-compliant public certificates.

1. Download Certificate: Export the .crt file from Salesforce Setup.
2. Inspect EKU Attributes: Run the following OpenSSL command against the file: openssl x509 -in cert_file.crt -text -noout | grep -A 1 "Extended Key Usage"
3. Analyse Results:
   • Compliant: Certificate lists only Server Auth OR only Client Auth.
   • Non-Compliant: Certificate lists BOTH Server Authentication and Client Authentication.

• The Remediation: IT must revoke dual-use public certificates. Transition to a Private PKI for client authentication or procure dedicated “Client Auth-only” certificates from compliant public root hierarchies.

7. SAML SSO Cryptographic Separation

Salesforce is enforcing the principle of cryptographic separation of duties at the application authentication layer.

• The Vulnerability: Historically, organisations could utilise a single “dual-use” certificate for both signing SAML requests and decrypting SAML assertions from third-party Identity Providers (IdPs). Using the same key pair for multiple cryptographic operations (signing and encryption) exponentially increases the attack surface and “blast radius” if the private key is compromised. Many modern Identity Providers (e.g., Entra ID, Okta) are beginning to flag or reject these legacy dual-use configurations.

• The Remediation (Administrator Action Required): System Administrators must execute an immediate audit of their SAML SSO configurations.

  1. Navigate to Setup > Single Sign-On Settings.
  2. Review existing SAML configurations.
  3. Ensure that the Request Signing Certificate and the Assertion Decryption Certificate fields are populated with two distinctly separate certificates.
  4. If a single certificate occupies both roles, generate or procure a secondary certificate and assign it to separate the cryptographic workloads. Coordinate this update with your Identity Provider administrator to ensure assertion encryption matches the new Salesforce public key.

---

Action Items and Remediation Checklist

1. JWT Assets: Maintain current rotation schedules; exempt from the 200-day mandate.
2. Experience Cloud Domains: Ensure configuration is set to Salesforce CDN/Managed Certificates prior to the 15 March deadline to prevent lapse.
3. Middleware Domains: Direct IT to implement infrastructure-level ACME protocols for external routing endpoints.
4. Transport Layer Trust: Direct DevOps to execute the curl validation protocol via the Microsoft proxy to confirm G2 Root trust.
5. Java/MuleSoft Assets: Provide IT with Section 5 to mandate explicit validation of isolated cacerts keystores.
6. mTLS and SAML Audits: Audit integration environments to replace dual-use public certificates (prior to 15 June 2026) and strictly separate SAML signing and encryption certificates.

Is your Salesforce infrastructure ready for the G2 transition? Contact Sliick for a comprehensive platform audit of your security posture and integration resilience.