Sectigo New Public Roots and Issuing CAs Hierarchy [2025 Migration Guide]
Home » Sectigo New Public Roots and Issuing CAs Hierarchy [2025 Migration Guide]
The majority of certificate outages don’t begin with a breach alert. They are silent at first.
![Sectigo New Public Roots and Issuing CAs Hierarchy [2025 Migration Guide]](https://certera.com/blog/wp-content/plugins/wp-postratings/images/stars/rating_on.gif)
Sectigo New Public Roots and Issuing CAs Hierarchy [2025 Migration Guide]
Home » Sectigo New Public Roots and Issuing CAs Hierarchy [2025 Migration Guide]
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:
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
Certificate Type
Issued Before This Date (Legacy Chain)
Issued After This Date (New Chain)
New Intermediate CA
New Root CA (Trusted Chain)
Action Required
EV SSL
Before Apr 15, 2025
On/After Apr 15, 2025
Sectigo Public Server Authentication CA EV R36 / E36
Sectigo Public Server Authentication Root R46 / E46 (cross-signed via USERTrust)
Verify chain if issued before date
OV SSL
Before May 15, 2025
On/After May 15, 2025
Sectigo Public Server Authentication CA OV R36 / E36
Sectigo Public Server Authentication Root R46 / E46 (cross-signed via USERTrust)
Update on renewal or reissue
DV SSL
Before June 2, 2025
On/After June 2, 2025
Sectigo Public Server Authentication CA DV R36 / E36
Sectigo Public Server Authentication Root R46 / E46 (cross-signed via USERTrust)
Check older certs immediately
S/MIME (Email)
Before Mar 1, 2025
On/After Mar 1, 2025
Sectigo Public Email Protection CA R36
Sectigo Public Email Protection Root R46 / E46
Update trust stores
Code Signing (OV & EV)
Early 2025 (legacy roots)
2025 onward (phased)
Sectigo Public Code Signing CA R36
Sectigo Public Code Signing Root R46 (USERTrust cross-signed)
Mandatory for future signing
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!
Janki Mehta
Janki Mehta is a passionate Cyber-Security Enthusiast who keenly monitors the latest developments in the Web/Cyber Security industry. She puts her knowledge into practice and helps web users by arming them with the necessary security measures to stay safe in the digital world.
*** This is a Security Bloggers Network syndicated blog from EncryptedFence by Certera – Web & Cyber Security Blog authored by Janki Mehta. Read the original post at: https://certera.com/blog/sectigo-new-public-roots-and-issuing-cas-hierarchy-2025-migration-guide/
About Author
