April 15, 2026 is an important date for organizations that still rely on parts of the older DigiCert hierarchies. On that day, Mozilla and Google Chrome will remove DigiCert G1 roots from their trust stores, which means that TLS certificates chaining exclusively to those roots will no longer be trusted in environments based on those trust programs. For many organizations, this is not a dramatic change, because the vast majority of deployments have already been moved to the newer G2 and G3 hierarchies. For some environments, especially those with legacy components, custom trust stores, pinning, or non-standard validation logic, however, this may create a real risk of service disruption, validation errors, and unexpected incidents on the client, application, and device side.
In practice, this is not only about a browser-side change. It is part of a broader trend of cleaning up the public WebPKI, where older root and intermediate hierarchies are being phased out and trust is shifting toward newer, more structured, and requirements-aligned issuance models. DigiCert began moving to default issuance from the G2 hierarchy as early as March 8, 2023 precisely to reduce the impact of the later G1 retirement. This means the issue does not affect every DigiCert, GeoTrust, RapidSSL, or Thawte certificate, but only the portion of active deployments that still remain on the older chaining path.
What exactly is being withdrawn?
The key message is simple: from April 15, 2026, Mozilla and Google Chrome will stop trusting DigiCert G1 roots used for public TLS. DigiCert materials specifically identify three primary roots from this generation: DigiCert Assured ID Root CA, DigiCert Global Root CA, and DigiCert High Assurance EV Root CA. For active TLS certificates, this means a loss of trust after that date if their trust path terminates exclusively at those roots.
This is a very important distinction. The mere fact that a certificate was issued by a brand owned by DigiCert does not automatically mean there is a problem. DigiCert has long issued public certificates from the newer G2 hierarchies, and some products also use newer G3 paths. Cloudflare, describing this change from the perspective of its own customers, emphasizes that the primary area of risk is custom certificates that still chain to legacy G1. Certificates terminating in G2 remain trusted and are not affected by this specific distrust action.
Why does this change matter right now?
In many organizations, roots and intermediates become a topic again only when something stops working. That is a mistake. The trust chain is part of critical infrastructure, yet it often remains outside day-to-day monitoring. In practice, this means that an organization may have a properly installed end-entity certificate, a valid expiration date, and still run into problems on the client side because the validation path ends at a root that has just dropped out of the trust store.
The risk is especially high where mixed environments are involved: modern browsers on one side, and on the other older applications, devices, cryptographic libraries, network appliances, B2B integrations, mail clients, application servers, or internal agent-based components that do not use the same validation model. Some of these systems work correctly for years, which leads their owners to assume that nothing needs to change. In reality, these are precisely the environments where hard-coded trust, certificate pinning, or dependencies on old cross-signed chains are most often found. DigiCert explicitly states that environments which pin or hard-code root and intermediate acceptance, or maintain their own trust stores, require additional attention.
Who is likely to be affected the most?
The least exposed are standard web deployments that have been renewed in recent years through the usual process and did not rely on non-standard exceptions. If a certificate was renewed or reissued in the normal lifecycle after DigiCert moved to G2, a large share of such environments is already operating on supported hierarchies today. DigiCert states that most customers have already been migrated and do not need to take additional action.
Much greater caution is required for organizations that meet at least one of the following conditions:
- they have active TLS certificates issued from the G1 hierarchy,
- they require trust in environments based on Chrome or Mozilla Firefox,
- they maintain custom trust stores or their own CA bundles,
- they pin roots or intermediates,
- they use older devices, agents, libraries, or servers that were prepared for the former certification path,
- they deploy certificates outside the classic web model, for example in appliances, B2B integrations, devices, intermediary services, or components that are not updated frequently.
A special case also includes environments where compatibility workarounds were historically used, for example cross-signing intended to preserve trust in older trust stores. These are solutions that often worked correctly during the transition period, but they should not be treated as a long-term target strategy. DigiCert already noted in 2023 that the cross-signed root was transitional in nature, and that maintaining trust beyond the distrust date requires migration to a newer hierarchy.
What operational effects may appear after April 15, 2026?
The most obvious effect will be untrusted certificate warnings in browsers and applications using trust stores based on the Chrome and Mozilla programs. For the end user, this means a security warning. For the organization, it means reduced credibility, interrupted login flows, blocked access to panels, forms, APIs, or purchasing processes.
In practice, however, the effects may be broader than a browser warning alone. If the certificate is used in machine-to-machine integrations, reverse proxies, load balancers, shared services, telemetry agents, or intermediary security layers, the issue may appear as a TLS connection failure, inability to establish a session, trust rejection by the client, loss of communication renewal capability, or vague application errors. Some of these issues will not immediately be identified as a root CA problem, because the logs may only show a generic certificate validation error. That is exactly why this topic requires earlier inventory work rather than reacting only after an incident occurs.
How can an organization check whether it is exposed?
The first step should not be ordering new certificates immediately, but determining where active G1 chains actually exist. This is a certificate inventory task, not a single support case.
In practice, it is worth approaching this in four layers.
1. Inventory of active public certificates.
This should include not only public domains, but also certificates used in administrative portals, B2B interfaces, integration services, edge devices, WAFs, appliances, VPNs, mail gateways, and anywhere a public certificate is used outside a classic website. The greatest number of issues is usually found in exactly these less visible points.
2. Identification of the actual chaining path.
For each active deployment, it is necessary to determine which intermediate and root the trust path actually leads to. The end-entity certificate alone is not enough. The fact that the certificate brand is RapidSSL, GeoTrust, or Thawte does not yet determine whether the deployment uses G1 or a newer hierarchy. DigiCert publishes mappings of former G1 intermediates and their G2 successors, which makes such comparisons easier. For example, for RapidSSL, the transition involved moving from RapidSSL Global TLS RSA4096 SHA256 2022 CA1 under DigiCert Global Root CA to RapidSSL TLS RSA CA G1 under DigiCert Global Root G2. Similar mappings exist for GeoTrust, Thawte, and DigiCert products.
3. Verification of dependencies on the client and device side.
Even if the server sends the correct chain after reissue, the issue may remain on the client, agent, or device side if they expect the old root, pin a specific path, or use their own CA bundle. This is often the area that determines whether the migration will be trivial or turn into a series of incidents spread across different teams.
4. Review of historical exceptions.
It is worth identifying whether compatibility workarounds related to a cross-signed root, custom chain files, manually built bundles, or appliance-specific exceptions were introduced in the past. Such decisions are often poorly documented, but they tend to resurface during exactly this kind of change.
What actions does DigiCert recommend?
DigiCert’s core recommendation is clear: affected certificates should be renewed or reissued into the G2 or G3 hierarchy before the withdrawal date in order to avoid untrusted warnings after April 15, 2026. At the same time, DigiCert emphasizes that most standard renewals already move certificates into supported hierarchies automatically, and issuing new certificates in G1 is no longer the standard path.
It is worth noting one more important aspect. Cloudflare points out that for affected certificates, a standard reissue into G2 is usually sufficient and in most cases does not require generating a new private key. This is operationally important, because some teams fear that such a migration will be equivalent to a full rebuild of the deployment. In many scenarios, it is not. First, however, it is necessary to confirm the policy of the specific product, the issuance process, and the organization’s own security requirements regarding key rotation.
What should not be assumed?
The biggest mistake would be to assume that the issue will resolve itself because “the certificate has not expired yet.” The problem here is not the expiry date of the end-entity certificate itself, but the loss-of-trust date of the root to which that certificate chains. It is therefore possible to have a certificate that is formally valid and still untrusted in practice. DigiCert explicitly states that after April 15, 2026, active TLS certificates chaining to G1 will lose trust in Chrome and Mozilla.
The second mistake is to assume that if the main corporate website works, the topic is closed. In reality, the most problematic systems are often the secondary ones: older administrative subdomains, devices, service panels, partner integrations, externally accessible test environments, and services that rarely appear in standard security reviews.
The third mistake is to treat cross-signing as a target strategic solution. Such mechanisms were useful as compatibility bridges, but in the long term the market is clearly moving toward simplification, retirement of old hierarchies, and greater predictability of trust paths.
Why does this topic fit into the broader direction of WebPKI changes?
The withdrawal of DigiCert G1 is not an isolated incident. It is another element of the broader clean-up of public PKI. In 2026, the industry is simultaneously implementing shorter maximum TLS certificate validity periods, stricter validation rules, MPIC, and further restrictions on the use of public WebPKI for purposes other than classic server authentication. DigiCert and the Chrome Root Program are also signaling further measures to simplify hierarchies and eliminate multifunction structures in favor of more explicit, dedicated TLS paths.
For infrastructure owners, this means one thing: a certificate is no longer a one-time purchase, but an element of a continuous management process. Organizations need to know who owns the certificate, where it is deployed, what chain it uses, how it is renewed, who is responsible for domain validation, how monitoring works, and whether the environment can safely move to a new hierarchy without manual exceptions.
Recommended action plan for organizations.
The most reasonable approach is not a panicked replacement of everything, but an orderly impact review and controlled migration.
The first step is to create a list of all public certificates and assign business and technical owners to them. Then it is necessary to determine which of them actually terminate in G1 and which client systems depend on the historical trust path. The next stage is reissue or renewal into G2 or G3 where required, followed by compatibility testing on the client, device, and integration side. Finally, there should be monitoring that checks not only the expiration date, but also chain changes, intermediate changes, and operational risk during future migrations.
From a business perspective, this is a good moment to treat the topic more broadly than simply “ordering a new certificate.” Organizations that put their inventory, monitoring, and renewal process in order today will be much better prepared not only for the DigiCert G1 withdrawal, but also for the next stages of WebPKI change, including further shortening of certificate lifecycles and stricter issuance rules.
Conclusions.
The change taking effect on April 15, 2026 does not mean a universal crisis for all DigiCert customers. It does, however, mark a very specific risk point for those organizations that still use active certificates chaining to G1 roots or maintain environments dependent on older trust models. In such cases, the issue will not be theoretical. It will mean loss of trust in browsers and potential errors in TLS-based services.
The key point is therefore not simply to remember the date, but to answer three questions: do we know where G1 chains still exist within the organization, do we understand dependencies on the client and device side, and do we have a process that allows such deployments to be moved safely to a supported hierarchy without chaos or downtime. Organizations that do this now will treat April 15, 2026 as a routine operational change. Those that ignore the issue may discover the problem only when a user sees an untrusted certificate warning.
Source:
– https://knowledge.digicert.com/alerts/digicert-tls-root-strategy-aligning-with-industry-standards
– https://www.digicert.com/blog/tls-certificate-rule-changes
– https://knowledge.digicert.com/general-information/digicert-root-and-intermediate-ca-certificate-updates-2023
– https://developers.cloudflare.com/ssl/reference/migration-guides/digicert-g1-distrust/