Sectigo Public Root CA Migration: What SSL Users Must Know

Sectigo executed a significant migration of Public Root and Intermediate CAs from 2025 up to the beginning of 2026.

This alteration has an impact on the issuance of TLS/SSL and S/MIME certificates, as well as their installation process.

This article discusses the reasons behind the change, the specific changes made, and the steps for a secure migration.

What Are Public Root CAs?

Public Root Certificate Authorities are the topmost tier of trust in the digital certificate ecosystem. Root certificates that are included in the trusted stores of operating systems, browsers, and email clients allow them to automatically verify SSL/TLS and S/MIME certificates.

If a certificate connects back to a trusted public root CA, the users are able to create secure connections and have encrypted communications without any warnings or need for manual intervention.

Also Read: What is SSL Certificate Chain in PKI? How Does It Work?

Why Sectigo Introduced New Public Roots

Sectigo brought up new Public Root CAs as a means to strengthen the security in the long run and to keep up with the ever-changing requirements of the browsers and industry. The older roots were created years back and are getting to the point where modern cryptography and compliance expectations can no longer be met.

New single-purpose roots for both TLS and S/MIME will allow Sectigo to enhance its cryptographic agility, manage trusts more easily, and guarantee acceptance everywhere in the root programs.

What has been modified in the Sectigo Ecosystem

Transition from Traditional to Contemporary Sectigo Foundations

In the past, a majority of Sectigo certificates were linked to the long-existing USERTrust and AAA root certificates. After the migration, certificates being issued are linked to present-day Sectigo Public Roots, including the Server Authentication and Email Protection roots (R46 and E46).

Trusting these roots means that browsers and operating systems will support Sectigo’s discontinuing the use of legacy roots for new issuances, but all the same maintaining the trust between users and the issuer.

New Intermediaries

Now, new intermediates at the level of authorities have been introduced, namely the R36 (RSA) and E36 (ECC) series. These intermediates are designated for specific purposes that distinguish the different scenarios, such as Domain Validation, Organization Validation, Extended Validation, and Email Signing.

In this way, there is a certain predictability in routine, a clean certificate chain, thus making it easier to manage, audit, and eventually rotate the certificates.

Cross-Signing for Backward Compatibility

To stop the trust loss for the older devices and systems, Sectigo cross-signed its new Public Root CAs with existing trusted roots such as USERTrust.

With cross-signing, the new root certificate via the older and more trusted root has the validation done, which means compatibility with legacy devices, older operating systems, and outdated applications. This solution allows for co-existing with the past while being at the forefront of technology.

Migration Timelines

The following are the important timelines related to migration.

Starting from the 1st of January, 2026, no SSL reissues under old root chains, no fallback to USERTrust-only chains, only R46/E46 roots and R36/E36 intermediates will be allowed.

Certificate Type	Migration Date
S/MIME	March 1, 2025
EV TLS	April 15, 2025
OV TLS	May 15, 2025
DV TLS	June 2, 2025
Enforcement Deadline	January 1, 2026

What Changed in Certificate Installation

Full CA Bundle Is Now Mandatory

Sectigo has altered its policy and is now offering the whole bundle of certificates together with the CA as a default. This huge lot consists of the intermediate certificate, the cross-signed root certificate, and the old USERTrust root, if that is the case.

When the whole bundle is installed, clients are able to be the ones who create the trust path correctly and automatically, especially in the case of the older devices and OS that still verify through cross-signed chains.

RSA and ECC Awareness

Sectigo continues to support the use of both RSA and ECC cryptographic algorithms, with RSA being the most widely used for the majority of certificates. On the other hand, many modern servers and balancers generate automatic ECC certificates during TLS handshakes.

In order to prevent the occasional trust or handshake problems, the administrators should make sure that the right RSA and ECC intermediates and roots are installed for their environment and use case.

Also Read: Root Certificates vs. Intermediate Certificates

Migration Steps

Step 1: Audit Your Environment

• Find out the certificate pinning

• Look for the places where the root or intermediate is hard-coded

• Assess the custom trust stores

Step 2: Update Trust Stores

• Put Sectigo Public Roots into (R46/E46)

• Keep the USERTrust roots for compatibility

• Java, OS, and appliance trust stores should all be updated.

Step 3: Install Full CA Bundles

• Always include:
  • Intermediate
  • Cross-signed root
  • Legacy root
• Never have partial chains

Step 4: Handle Microsoft IIS Carefully

• Microsoft Servers could:
  • Choose the shortest chain
  • Disregard the cross-signed roots
  • Cut off the trust for older clients

The recommended fix is:

• Disable the self-signed Sectigo R46/E46 root,
• Keep the cross-signed version enabled,
• If necessary, restart the server.

Step 5: Test Before Renewal or Reissue

• Test on:
  • the older browsers
  • the legacy OS versions
  • the mobile and email clients
• This is especially critical for S/MIME deployment.

Conclusion

If you have any questions or need assistance, contact our SSL experts at CheapSSLweb. Get ready for Migration now and review your certificate setup.

Search