Sectigo Public Roots Migration 2025: Plan TLS S/MIME and Code Signing Updates

Sectigo’s migration to single‑purpose public roots is no longer an abstract industry update — it’s an active, time‑bound infrastructure change that requires immediate attention from anyone who runs TLS, S/MIME, or code‑signing certificates issued by Sectigo. The vendor has already begun issuing certificates from the new Sectigo Public roots (R46/E46 and the R36/E36 subordinate CAs), cross‑signing those roots for legacy compatibility, and setting a firm migration window that will leave certificates bound to older chains unsupported if left unattended.

Background​

The root of the problem is trust — how operating systems and browsers decide which certificate chains they accept. Over the last several years, root programs and browsers have moved from permissive, multi‑purpose root paradigms toward narrow, auditable, and single‑purpose root certificates. Sectigo’s 2025 migration responds to this shift by introducing dedicated roots for TLS, S/MIME, and code signing, aligning issuance practices with current CA/Browser Forum and root‑store expectations. The new model removes ambiguity, reduces long‑term attack surface, and provides predictable behavior for modern clients. This change has practical deadlines and compatibility mechanics:

• S/MIME issuance switched to the new public roots on March 1, 2025.
• EV TLS moved on April 15, 2025; OV TLS on May 15, 2025; and DV TLS on June 2, 2025.
• Sectigo reports the migration effort is expected to be completed by January 2026, with cross‑signatures and compatibility bundles provided to ease the transition for older devices.

These dates matter because browsers and OS root programs will progressively distrust legacy chains on enforced schedules, not on server‑side expiration alone. That creates the risk of sudden browser warnings, failing API calls, and broken automation even when a certificate’s NotAfter date has not yet passed.

---

What Sectigo changed — single‑purpose public roots explained​

The old model: multi‑purpose roots​

Traditionally, many CAs issued large, multi‑purpose root certificates that underpinned a wide range of tasks: TLS, S/MIME, code signing, and sometimes even subordinate enterprise CAs. That flexibility created an increasingly complex and risky trust landscape: a single root signing many different types of certificates increases blast radius if the key, policy, or oversight fails.

The new model: single‑purpose roots​

Sectigo’s new approach is to use dedicated root certificates for clearly defined functions (for example, Sectigo Public Server Authentication Root R46 / E46 for TLS), and to enforce strict usage constraints at the root and issuing‑CA level. That means:

• Certificate usage is limited by design rather than by hope.
• Each root and issuing CA does one thing well (e.g., server authentication, email protection, code signing).
• Compatibility for legacy clients is achieved via cross‑signing, not by weakening the new roots’ restrictions.

This design aligns with modern root‑store policies and reduces future surprises when browsers tighten enforcement.

---

Timeline and enforcement — the dates you must track​

Sectigo’s own publications lay out staged cutovers for certificate types:

• S/MIME: March 1, 2025.
• EV TLS: April 15, 2025.
• OV TLS: May 15, 2025.
• DV TLS: June 2, 2025.

Sectigo indicates the remaining migrations and cleanup were expected to be completed by January 2026; cross‑signed bundles (linking R46/E46 back to USERTrust and AAA Certificate Services) are available to maintain legacy compatibility while moving issuance to the modern trust anchors. Administrators should treat January 2026 as the operational cutoff window for completing migrations, and verify any statements about no re‑issuance after a hard date because vendor communications sometimes describe “completion by” rather than an abrupt stop‑date. If you see a claim that Sectigo will stop reissuing under legacy chains exactly on January 1, 2026, treat that as an important warning and verify against Sectigo support if your environment has bespoke constraints. Critical operational point: When root programs distrust a legacy root, browsers and clients will stop trusting any chains that rely on it, regardless of the leaf certificate’s expiry. That means you might be one browser update away from a catastrophic outage if a certificate chain is still tied to legacy anchors.

---

How the new chain works — issuance, cross‑signs, and legacy compatibility​

Sectigo’s redesign can be summarized in three roles:

• New roots (Sectigo Public Server Authentication Root R46/E46 and peers) act as the primary trust anchors for modern platforms. These are single‑purpose and embedded in modern root stores.
• Cross‑signed roots are issued to allow the new roots to chain back to well‑known legacy roots (USERTrust or AAA Certificate Services). This maintains compatibility with older operating systems and appliances that do not yet include R46/E46 in their trust store.
• Legacy roots stop issuing new certificates and become trust anchors only; they are not intended to be used for fresh issuance. The goal is a clean separation of issuance and trust functions.

Practically, when you download your Sectigo SSL bundle today you may see:

• The leaf (your domain certificate).
• One or more intermediate CA certificates (R36/E36 variants).
• A cross‑signed root certificate that chains back to USERTrust or AAA for older clients.
• A CA bundle combining all of the above to ease server configuration.

If servers omit any of these files (especially the required intermediate(s) or the cross‑signed root for legacy clients), some devices will fail validation. Installing the full CA bundle is the most reliable approach.

---

What breaks if you do nothing​

The visible symptoms are straightforward but the root cause is subtle:

• Users get browser security warnings or blocked HTTPS.
• API clients fail TLS handshakes and report certificate errors.
• Search engines and automated crawlers may drop traffic and rankings.
• Internal automation (CI/CD, webhooks, monitoring) that relies on TLS can fail silently, producing cascading operational outages.

These outages are typically not the result of compromise. They are the result of trusts changing in the background — modern clients cease to trust old chains according to root‑store policies. By the time external monitoring shows a failure, users have already encountered the problem. Stay ahead of these changes rather than reacting to end‑user complaints.

---

Practical, step‑by‑step migration checklist​

Follow this prioritized checklist to minimize downtime and avoid surprises.

• Inventory and identify
• Enumerate all public and internal certificates issued by Sectigo (TLS, mail, code signing). Include appliances, IoT devices, containers, and serverless endpoints.
• Record the exact issuing chain for each (leaf → intermediate → root). Tools that inspect the certificate chain (OpenSSL s_client, online SSL checkers, or your certificate management system) are essential.
• Validate issuance date vs. migration cutoffs
• If certificates were issued before the stated cutover dates for their type, verify whether they are on a legacy chain and plan re‑issuance accordingly. Sectigo’s type cutover dates (S/MIME Mar 1, 2025; EV Apr 15, 2025; OV May 15, 2025; DV Jun 2, 2025) define when new issuance defaulted to the R46/E46 hierarchies.
• Obtain and install full bundles
• Download and install the full certificate package Sectigo provides: leaf, intermediate(s), cross‑signed root, and — if supported — the CA bundle. Installing the complete bundle reduces ordering and chain issues.
• Test against modern and legacy clients
• Use SSL checkers and test across a matrix of browsers and OS versions, including older devices that your user base might still use. For cloud platforms with locked root stores (for example, some multi‑tenant PaaS environments), validate compatibility and ask the platform vendor for guidance where necessary. This was the case for Azure App Service where R46 availability required attention.
• Reissue or renew early where needed
• If a production certificate is bound to a legacy chain and you cannot replace the client population immediately, reissue the certificate under the new Sectigo chain now rather than waiting for expiration.
• Update server trust stores and avoid pinning
• Do not pin roots or intermediates in production unless you have a mature rotation and rollback plan. Pinned dates and pinned thumbprints will break when Sectigo or browsers change trust anchors.
• Automate and document
• Use automation for discovery, reissuance, and deployment. Maintain a certificate inventory with owners and expiry dates; automate renewals and chain verification.
• Communicate and schedule maintenance windows
• Coordinate with teams owning legacy systems (OT, embedded devices, appliances) and plan maintenance or fallback measures during the migration.

---

Windows‑specific guidance (common pitfalls and fixes)​

On Windows servers, a common issue is the OS selecting the wrong anchor (for example, using Sectigo’s self‑signed root instead of the USERTrust cross‑signed root) or missing the cross‑signed root entirely. Use the Microsoft MMC (mmc → Certificates snap‑in for Local Computer) or certutil/PowerShell import commands for machine‑wide installations. When trust problems occur, verify the certificate appears under Local Machine → Trusted Root Certification Authorities and that the USERTrust cross‑signed root remains enabled for legacy compatibility. Do not remove root certificates unless you have confirmed the impact and have a rollback plan.
If legacy devices prefer the cross‑signed chain and refuse the new root, ensure the cross‑signed root bundle is present on your server (or distributed to clients via Group Policy for domain‑joined machines). For domain environments, publish the root via Group Policy or certutil -dspublish for consistent distribution. Ad hoc local installs do not scale and are error‑prone.
Important note: modifying the Trusted Root store is a security decision with consequences. Treat any root import as a change‑controlled operation; verify thumbprints over an independent channel to avoid accidentally trusting a malicious CA.

---

Failures and edge cases — what to watch for​

• Cloud PaaS and multi‑tenant environments may not instantly reflect new roots in their trust stores (some Azure App Service customers reported missing R46 in platform trust stores and had to rely on cross‑signing or platform support). If you rely on platform‑managed trust, open a support case to confirm when R46/E46 will be trusted.
• Appliances and firmware‑locked devices (network devices, printers, embedded controllers) may never receive updated trust stores. For those, you must either keep cross‑signed bundles available or replace firmware/hardware. Inventory and act early.
• Internal PKI and delegated subordinate CAs: if your organization runs internal CAs or uses delegated subordinates, audit name constraints and policy constraints — internal hierarchies are often the high‑risk vectors for misissued certificates.
• Monitoring silence: many monitoring tools only check leaf expiry dates. Extend checks to validate the full chain and whether the chain uses a modern root. If a chain switches to an untrusted root (even if the leaf is valid), client trust will fail.

---

Recommended migration playbook for IT teams (actionable, timeline‑driven)​

• Immediate (week 0–2)
• Inventory all Sectigo‑issued certificates and identify issuance chain and issuance date.
• Prioritize public‑facing TLS endpoints and critical APIs.
• Confirm which certificates already use R46/E46; tag the rest for re‑issuance.
• Short term (weeks 2–6)
• Reissue certificates for high‑priority services under the new R36/E36 intermediates if still on legacy chains.
• Install full CA bundles on servers and test using client matrix.
• Coordinate with cloud vendors for platform trust confirmation.
• Medium term (weeks 6–12)
• Replace or update firmware on appliances that cannot accept new roots.
• Roll out cross‑signed bundles to legacy clients where replacement is not feasible.
• Long term (90+ days)
• Remove pinning and hard references to legacy chains from automation.
• Harden certificate lifecycle management (centralized inventory, automated renewal, chain validation on deploy).
• Revalidate internal PKI policies and restrict wildcard or overly broad issuance.

This approach balances urgency with operational safety. Reissue proactively — do not wait for expiration windows to trigger a reactive scramble.

---

Critical analysis — strengths, risks, and the unverified claims to watch​

Strengths

• Security posture: Single‑purpose roots reduce the complexity of trust decisions and confine risk to narrower, better‑audited use cases. This aligns Sectigo with CA/Browser Forum intent and modern root‑store expectations.
• Compatibility via cross‑signing: By cross‑signing new roots with well‑known anchors (USERTrust, AAA), Sectigo provides a compatibility bridge for legacy clients during the migration window.
• Clear staged dates: Sectigo published staged cutover dates for different certificate classes, enabling planning and prioritization.

Risks and operational friction

• Legacy systems and firmware: Long‑lived devices and appliances may never get modern trust stores and will require workarounds or hardware replacement. Cloud platform trust store delays (e.g., Azure App Service) can also complicate rollouts.
• Monitoring gaps: Many organizations only watch leaf expiry. Without chain‑aware checks, you’ll be surprised by policy‑driven distrust that ignores certificate validity dates.
• Verifiable cutoff claims: Some community writeups and third‑party posts describe a hard Jan 1, 2026 no reissue policy. Sectigo’s KB materials emphasize completion by January 2026, but explicit “no re‑issuance under older chains after Jan 1” language should be validated with Sectigo support for high‑impact or bespoke issuance channels. Treat absolute hard‑stop claims as operationally critical and verify them with Sectigo if they affect your renewal schedules.

Unverifiable or cautionary points

• Any claim that every endpoint will seamlessly chain back via cross‑signs is optimistic. Real‑world heterogeneity (platform trust stores, appliances) makes careful testing essential. Cross‑signs ease migration but do not eliminate the need for explicit testing and phased rollouts.

---

Quick technical references (cheat sheet)​

• New TLS roots: Sectigo Public Server Authentication Root R46 (RSA) and E46 (ECC). New issuing CAs include R36/E36 subordinates for DV/OV/EV classes.
• Key migration cutovers: S/MIME — Mar 1, 2025; EV — Apr 15, 2025; OV — May 15, 2025; DV — Jun 2, 2025.
• Best server practice: install the full CA bundle (leaf + intermediates + cross‑signed root) as provided by Sectigo. Test with modern browsers and older devices representative of your user base.
• Windows: prefer Local Machine → Trusted Root for machine‑wide trust. Use Group Policy to distribute roots in domain environments. Verify thumbprints via independent channel before import.

---

Conclusion​

Sectigo’s 2025 migration to single‑purpose public roots is a necessary modernization that simplifies trust semantics and reduces long‑term risk — but it is not a background housekeeping item. It is a calendar‑driven, client‑sensitive change that will produce sudden, visible outages if ignored. The safe course for IT teams is clear: inventory, validate the chains you depend on, reissue where needed, and install the full trust bundles now rather than waiting for the moment a browser update forces your hand.
Actionable priorities for the next 72 hours: locate every Sectigo certificate, check its issuing chain, and confirm whether its chain includes R46/E46 or relies only on legacy anchors. Reissue high‑risk public endpoints if they still rely on legacy chains, and schedule maintenance windows to deploy full bundles and firmware updates for appliances that can’t be updated automatically. When in doubt, open a support ticket with Sectigo and document your chain verification steps for audit readiness.
Proactive migration will be quiet and uneventful; waiting will be noisy and expensive. Treat this migration like a software lifecycle update — plan, test, automate, and execute.

---

Source: Security Boulevard Sectigo New Public Roots and Issuing CAs Hierarchy [2025 Migration Guide]