The majority of certificate outages don’t begin with a breach alert. They are silent at first. One day, a browser warning appears when your website loads, causing users to hesitate and your traffic to decline.

This is due to the fact that most certificate failures are not caused by hackers. They occur as a result of teams failing to notice subtle infrastructure changes that are taking place in the background.

That’s precisely what Sectigo’s Public Root and Intermediate CA migration for 2025 aims to achieve.

On your end, everything might appear to be fine. It still indicates that your SSL certificate is valid. Reminders for renewals are still coming in. Your dashboards remain green. However, trust is actually changing at the browser level, and browsers, rather than your server, determine what is safe.

If you don’t prepare for this migration, browsers will stop trusting certificates issued under older chains. When that happens, the impact is immediate: security warnings, broken HTTPS, failed API calls, and lost user confidence.

Why Sectigo Reconsidered Its Strategy of Root CA

Standards of security do not rest on their laurels. Nor can certificate authorities afford to either. This was the case over the last couple of years as browser vendors, as well as root programs, have set the bar high for the aspect of trust.

The regulations that used to be the guiding force in the issuance of certificates are not sufficient to address the current security standards. With those rules being revised, old standard models of certificates became old-fashioned.

That is why Sectigo also left the concept of multi-purpose root CAs and embraced single-purpose Public Root certificates.

The purpose of multi-purpose routes was created at another time. They managed several types of certificates in a single umbrella that made them more complex and risky in the long term. The modern-day security model is biased towards isolation, clarity, and a narrow-scope root, and single-purpose roots provide just that.

Under this Change, Sectigo is assured of being able to:

• Meet evolving CA/Browser Forum requirements without last-minute workarounds
• Stay aligned with Chrome and Mozilla root program policies, including future enforcement changes
• Reduce long-term security exposure by limiting what each root is allowed to do
• Preserve trust across browsers, operating systems, and devices, both modern and legacy

It is a structural change. Browsers are aggressively implementing these standards, and legacy roots are being eliminated on fixed schedules. The certificate authorities never have the privilege of not doing so, nor do the organisations in which they are entrusted.

Also Read: Root Certificate vs Intermediate Certificate

What Single-Purpose Root CAs Actually Mean

For years, legacy root certificates tried to do everything.

They released various forms of certificates, had numerous applications, and the responsibility continued to expand with time. That leeway had been successful in the earlier days, but it also added complexity, risk, and long-term maintenance issues.

Legacy roots simply did too much. Single-purpose Root CAs take the opposite approach.

They are not generic trust anchors but rather constructed to perform one specific, well-defined purpose. In the case of Sectigo, it would be roots dedicated either to TLS/SSL or S/MIME, and strongly restricted certificate usage.

This Design Change delivers Real Security Benefits:

• Certificate usage is limited by design, not policy alone
• Attack surface shrinks because fewer functions mean fewer ways to abuse trust
• Modern browser enforcement rules are met by default, not through exceptions
• Forced distrust timelines are avoided because these roots align with current root program expectations.

Browsers desire predictability. They desire foundations that act predictably and have limited rules of conduct. Root CAs that are single-purpose offer such clarity.

The Timeline You Cannot Ignore

There’s one date you need to remember, and missing it has consequences.

Starting January 1, 2026, Sectigo will no longer re-issue SSL certificates under older root or intermediate chains. This isn’t a recommendation. It’s a hard stop.

Once this date passes, any certificate still tied to a legacy chain hits a dead end. You won’t be able to reissue it. You won’t be able to renew it under the same hierarchy. And waiting until the last moment won’t buy you time.

Once this date passes, any certificate still tied to a legacy chain hits a dead end. You won’t be able to reissue it. You won’t be able to renew it under the same hierarchy. And waiting until the last moment won’t buy you time.

Here’s how it plays out in the real world:

• Old chains mean no renewals
• No renewals mean expired certificates
• Expired certificates mean outages

And outages don’t just break encryption. They break user confidence, search rankings, API integrations, and automated workflows that depend on HTTPS.

Sectigo has already started the migration, and most certificate issuance has moved to the new public roots. The remaining transitions are happening now. The window is closing, and the safest time to act is before browsers force the issue for you.

Also Read: Certificate Management Emerging Trends to Watch in 2026

What Happens If You Stay on Legacy Roots

Everything looks fine on the surface. The certificate is still valid. The expiration date is months away. Monitoring tools stay quiet. And because nothing appears broken, the issue gets pushed down the priority list.

Until it isn’t fine anymore.

Major browser root programs now enforce mandatory distrust timelines. These aren’t theoretical policies. They are active rules that browsers already follow.

Here’s what that means in practice:

• Legacy roots lose trust once their private keys hit age limits, regardless of certificate validity
• Chrome enforces SCTNotAfter dates, which silently invalidate certificates issued after a cutoff point
• Mozilla distrust propagates through NSS, impacting Linux, BSD, and countless enterprise systems

Once distrust kicks in, the browser doesn’t care that your certificate hasn’t expired. Trust disappears anyway.

You are just one browser update away and one policy enforcement, and suddenly, users see security warnings, APIs reject connections, and encrypted traffic stops flowing. By the time it shows up in your dashboards, your users have already noticed, and many of them have already left.

Also Read: What is Certificate Management? Why Do Businesses Need Centralized Certificate Management Solution?

How the New Sectigo Certificate Chain Works

Sectigo didn’t just replace old certificates with new ones. They redesigned the entire trust model for stability, longevity, and compatibility.

The new certificate chain follows a clear and intentional structure.

First, all new certificates are now issued under modern public root CAs:

These roots are single-purpose, tightly scoped, and fully aligned with current browser and root program requirements. This ensures long-term trust without running into future enforcement surprises.

Second, cross-signed roots act as the compatibility bridge:

They allow certificates issued under new roots to chain back to well-established legacy roots such as USERTrust, when older devices or operating systems need them. This keeps legacy environments working without weakening security for modern platforms.

Lastly, legacy roots do not issue certificates anymore:

They exist in the form of trust anchors. They are not to establish chains but to approve those that need to be. This hugely minimizes risk and maintains compatibility.

The outcome is a pure division of roles:

• New roots handle issuance
• Cross-signed roots address compatibility.
• Legacy roots only deal with trust.

Sectigo’s New Roots and Issuing CA for RSA, ECC Trust Path

What is in your Sectigo SSL Certificate Folder?

Once the SSL files have been downloaded, it is easy to forget them. It is where it usually begins to create issues.

Each file in the Sectigo folder has a purpose.

You will be displayed with your domain certificate. This is the one that is attached to your site and which makes HTTPS operational.

Intermediate certificates are also present. These come in between your site and the root of Sectigo and assist the browsers in ensuring that your certificate is genuine.

You can observe a cross-signed root certificate. This is because of older systems that have not yet been updated to the newer root, meaning that your site still functions with them.

The USERTrust root certificate is also included with Sectigo. It is still being used by many older devices, and taking it away too soon will lead to trust errors.

Occasionally, it has a CA bundle, which simply bundles everything together so as to be able to ease setup.

The lesson learned is easy: install every file you’re given. Miss one, and browsers won’t trust your site.

Sectigo Certificate Migration Timeline

Recommended: Access New Sectigo Public Certificate Chain Here

How to Set Up the New Sectigo Certificate Chain

The following steps are to be taken when installing or renewing your Sectigo SSL certificate to prevent a problem of trust.

• Install the entire certificate package: Use the folder of the SSL certificate as it was on your Sectigo account or email. Minimise the downloading of files.
• Install your domain (leaf) certificate: It is the certificate that is issued to your domain (such as yourdomaincom.crt). Install it on your server as the main certificate for SSL.
• Install the intermediate certificates: Install the appropriate intermediate CA depending on the type of certificate that you have (DV, OV, or EV – R36 or E36). Such certificates associate your domain with the public root of Sectigo.
• Install the cross-signed root certificate: Install the cross-signed root, which is chained on the legacy USERTrust root. This will make it compatible with older systems and operating systems.
• Install CA bundle: In case your server supports a CA bundle, it is better to install the MyCA_Bundle.ca-bundle file rather than installing the separate certificates to prevent ordering problems.
• Check the complete certificate chain: Once you have installed the certificate, test the chain using an SSL checker to ensure that the chain is complete and is relied upon by the browsers.

Disable or Delete Untrusted Root from Microsoft Trust Store (Recommended)

If older devices fail to trust your certificate on a Windows server, Windows may select the self-signed Sectigo root instead of the USERTrust cross-signed root. 

To fix this: 

• Log in to the server as an administrator and open Microsoft Management Console (mmc). 

• Add the Certificates snap-in for the Local Computer. 

• In Trusted Root Certification Authorities, locate the certificate: 

• Issued to: Sectigo Public Server Authentication Root R46 (or E46) 

• Issued by: Sectigo Public Server Authentication Root R46 (or E46) 

• Disable or delete this certificate only if the Issued to and Issued by values are the same. 

• Keep the USERTrust-issued cross-signed root enabled. 

This step is required only when trust issues occur on Windows systems. Do not remove root certificates unless the problem is confirmed. 

Best Practices to Avoid Downtime

Most certificate outages happen because of small setup mistakes, not hacking.

To avoid issues:

• Install every certificate you’re given. Missing even one breaks the trust chain.
• Use the CA bundle if your server supports it. It reduces mistakes.
• Don’t pin roots or intermediates. When certificates change, pinned setups fail.
• Keep trust stores updated on servers, containers, and apps.

SSL certificates aren’t one-time setup items. If you don’t maintain them, browsers will eventually stop trusting them.

Conclusion

The Sectigo Public Root and Intermediate CA migration isn’t a future problem. It’s a present responsibility.

The changes are already in motion, browsers are already enforcing new trust rules, and the deadline is fixed. Teams that prepare now will transition quietly without impact. Teams that wait will discover the change only when users start seeing warnings.

Audit your certificate chains. Install the full trust path. Move to the new public roots with confidence.

Because when it comes to certificate trust, being proactive is the only safe option. Don’t hesitate to contact our SSL Experts for any query!