Sectigo Public Root CA Migration and How TLS Trust Chains Work

A significant shift is underway in the web’s trust infrastructure. Sectigo has begun migrating its public TLS and email certificate ecosystem to a new root and intermediate hierarchy. A transition rolling out through 2025 and moving toward full enforcement in early 2026. While invisible to most end users, this change affects how certificate trust chains are built, validated and maintained across browsers, servers, and security platforms worldwide.

Root migrations reshape the foundation of digital trust and influence certificate validation long after the transition completes. Most modern environments will continue operating normally, but systems relying on older trust chains, pinned intermediates, or outdated configurations may experience validation gaps if left unchecked.

Understanding what is changing and confirming your certificate chain is aligned with the new hierarchy – this helps ensure uninterrupted trust as the PKI ecosystem continues to evolve.

What is Changing in the Sectigo Trust Infrastructure?

At the core of this migration is a redesigned Public Root hierarchy. Sectigo is transitioning away from legacy trust anchors toward a new generation of Sectigo Public Root CAs, including the modern R46 and E46 roots, built to support stronger cryptographic standards, improved lifecycle control, and long-term ecosystem stability. Instead of relying on older mixed-purpose roots, the updated architecture introduces a more structured trust model aligned with how certificates are issued and validated today.

As illustrated in the hierarchy above, the new structure separates certificate purposes into distinct trust paths. Dedicated Public Roots now anchor TLS and email certificate issuance independently. A new generation of issuing certificate authorities – including DV, OV, and EV intermediates in the R36 and E36 series – form a simplified and more maintainable chain from your server certificate to the trusted root.

Another important aspect of this transition is the gradual shift away from legacy trust chains. While the functional validation process for SSL certificates remains unchanged, the path of trust now anchors to Sectigo’s modern Public Root infrastructure. This reduces dependency on aging root hierarchies and aligns certificate issuance with current browser and operating system trust expectations.

To maintain compatibility during the transition, cross-signing bridges new certificates with legacy trust anchors until root stores across platforms fully recognize the new hierarchy. The result is a cleaner, future-ready trust chain that improves long-term validation, simplifies certificate management, and prepares the PKI ecosystem for evolving security and compliance requirements.

Why Sectigo is Migrating its Public Roots

Public roots underpin digital trust, but they must evolve as security standards and cryptographic expectations advance. Sectigo’s Public Root migration reflects this shift by strengthening long-term certificate validation without changing how SSL operates in everyday use.

A primary driver is cryptographic and lifecycle modernization. Earlier hierarchies were built for longer certificate lifetimes and less automation. Today’s environment demands shorter validity, faster renewals, and more predictable trust paths. The new Public Root architecture enables this through a cleaner and more maintainable issuance structure.

The migration also aligns Sectigo with modern browser and operating system root programs for continued global trust across platforms. By reducing reliance on aging hierarchies and simplifying chain complexity, the updated structure improves long-term stability while preparing the ecosystem for evolving compliance and security requirements.

Migration Timeline and Key Deadlines

Sectigo completed its phased Public Root migration during 2025, transitioning TLS and email certificate issuance to the new Public Root hierarchy. The structured rollout allowed trust stores across browsers, operating systems, and infrastructure platforms to adopt the updated roots while maintaining compatibility during the transition.

Since January 1, 2026, the migration is fully enforced. All new certificate issuances and reissues now use Sectigo’s modern Public Root hierarchy, and legacy-chain reissues are no longer supported. Certificates issued under older chains continue to function until expiration, but environments using pinned chains or legacy trust stores should confirm compatibility with the new hierarchy.

Who is Affected by This Change

For most modern environments, the migration occurred without visible disruption. However, the shift to Sectigo’s new Public Root hierarchy is relevant for organizations and teams that manage certificate deployment, trust chains, or legacy infrastructure.

You should review your environment if you fall into any of the following categories:

• Website owners using Sectigo SSL certificates issued or renewed after the migration
• IT and DevOps teams managing manual certificate installation or custom trust configurations
• Organizations using certificate pinning to specific roots or intermediates
• Environments running legacy operating systems, outdated Java runtimes, or older trust stores
• Infrastructure relying on hard-coded or incomplete certificate chains
• Enterprises using S/MIME or email certificates issued under Sectigo hierarchy
• Hosting providers, resellers, and platforms managing certificates across multiple environments

For most users, certificates continue to validate normally. The key difference is ensuring your systems trust the updated Sectigo Public Root hierarchy and no longer depend on legacy chain paths.

Will This Impact Existing Certificates

For most users, existing certificates continue to function normally. Sectigo’s Public Root migration does not invalidate certificates that were issued before the transition. Any certificate already installed will remain trusted until it reaches its natural expiration date.

What has changed is the chain used for new issuance and reissues. Since the migration is now fully enforced, all newly issued or renewed certificates are anchored to Sectigo’s modern Public Root hierarchy. Legacy-chain reissues are no longer available, meaning environments must be capable of validating the updated trust path going forward.

For organizations using multi-year certificates, the transition typically occurs during renewal or reissue. In most modern systems this happens automatically, but environments relying on pinned roots, outdated trust stores, or manual chain configuration should confirm compatibility with the new hierarchy.

In short, nothing breaks immediately but future renewals depend on trusting the updated Sectigo Public Roots.

What Changes for Installation and Trust Chains

The migration does not change how SSL certificates work, but it does change how the certificate chain must be configured and validated. With legacy fallback chains retired, servers must now present the correct intermediate chain that anchors to Sectigo’s modern Public Root hierarchy. In most modern environments this happens automatically, but manually managed or legacy systems may require verification.

The most important requirement is installing the complete and correct CA bundle provided with your certificate. Using outdated intermediates, mixing legacy chain files, or presenting an incomplete chain during the TLS handshake can cause validation errors even when the certificate itself is valid.

In certain environments, administrators may need to ensure the cross-signed intermediate certificate is properly included in the chain store so the certificate can validate across both modern and legacy trust paths. If your environment does not automatically build the full chain, follow best practices for properly adding the cross-sign certificate to the trust chain to avoid incomplete-chain errors and trust failures.

To confirm correct configuration, verify that your certificate validates cleanly from server certificate → issuing intermediate → trusted Sectigo Public Root across your target environments. Most modern systems require no manual changes, but validation offers uninterrupted trust under the updated hierarchy.

For SSL2BUY customers, certificates issued or renewed after the migration already include the correct chain. As long as the full bundle is installed correctly, your certificate will validate normally across supported platforms.

Risks if You Ignore the Migration

Ignoring root and chain transitions does not immediately break certificates, but it increases long-term risk. Potential issues include:

• Certificate validation failures in systems that do not recognize the new Sectigo Public Roots
• Broken trust chains caused by outdated or incomplete intermediate configurations
• Service disruptions in legacy environments relying on deprecated trust paths
• Unexpected errors during certificate renewal or reissue, as legacy-chain issuance is no longer supported
• Compatibility issues in pinned-chain or hard-coded trust configurations

These risks are avoidable with proactive verification that your environment trusts Sectigo’s modern Public Root hierarchy and that your certificate chain is correctly configured.

What SSL2BUY Customers Should Do Now

A practical verification now can prevent unexpected validation failures during renewal, infrastructure changes, or platform updates.

Start by checking the actual certificate chain your server is presenting, not just the certificate installed. The chain should build cleanly from your server certificate through the correct issuing intermediate (R36/E36 series) to the trusted Sectigo Public Root. If your server still presents an older intermediate bundle, replace it with the current CA bundle provided at issuance.

If your infrastructure uses certificate pinning, custom trust stores, Java keystores, or embedded certificate chains, verify that no legacy USERTrust or deprecated intermediates are hard-coded. These configurations often continue working until renewal, then fail when the new trust path is enforced.

Teams running Windows IIS, older Linux distributions, legacy Java runtimes, appliances, or embedded systems should explicitly validate trust against the new Sectigo Public Roots. In some cases, incomplete-chain errors may appear only in specific clients or internal services rather than browsers.

During your next certificate renewal or reissue, confirm that:

• The server presents the correct intermediate chain (not cached or reused from prior installs)
• The full trust path builds successfully across your supported environments
• No application-level certificate validation is pinned to legacy chains
• Monitoring or SSL inspection tools recognize the new trust hierarchy

For most SSL2BUY customers, simply installing the current CA bundle resolves everything. But environments with manual certificate handling, long-lived infrastructure, or mixed legacy systems should treat this migration as a trust-chain validation checkpoint, not just a certificate update.

Final Thoughts

Sectigo’s Public Root migration marks a structural shift in how certificate trust is established and maintained across the web. While the transition is now complete, its impact continues to surface in environments that rely on legacy chains, manual configurations, or long-lived infrastructure. Understanding how trust paths have evolved and verifying that your systems recognize the modern hierarchy helps prevent subtle validation issues in the future.

Related Articles:

• Root Certificates vs. Intermediate Certificates: Everything You Need to Know
• What is the Certificate Chain of Trust? Everything You Need to Know