Root certificate compatibility
Every FairSSL SSL/TLS product shows five shields. Each shield stands for one trust store: Windows, Apple, Android, Linux and Java. The shield fills according to how long the root certificate the product is actually issued from has been present in that particular store.
The aim is a comparable indicator built on observed facts rather than estimates: the same calculation for every product and every authority, so two certificates can be held up against each other. The background to every root changing at once is in the article The industry is moving to dedicated TLS root certificates.
The shields apply to SSL/TLS certificates only. Code signing, email certificates and document signing are issued from entirely different root certificates that take no part in the move to dedicated TLS roots, so those products show no shields.
The five shields
The example below is GlobalSign Root R46 as of August 2026. The root entered Microsoft’s trust store first, then the Mozilla bundle, then Apple, then Android and finally Java. The dark blue part of each shield is the stretch the root covers on its own. The light blue part is what the cross-signed chain closes, and it is why all five shields are full.
GlobalSign Root R46, August 2026. The dark blue figure is the year the root itself is credited from in that store. The hatched figure is the year the cross-signed path reaches back to. All five shields are full and the score is 8.6 of 10.
- Windows
- The Microsoft Trusted Root Program as delivered to Windows through Automatic Root Update.
- Apple
- The Apple root list as shipped in iOS and macOS.
- Android
- The AOSP system store, meaning the roots that ship with the Android version itself.
- Linux
- The Mozilla NSS bundle as distributed in ca-certificates on Debian, Ubuntu and RHEL. The same bundle backs Firefox, curl, OpenSSL and most language runtimes.
- Java
- cacerts in the JDK, measured against the oldest LTS line still under maintenance at that point in time.
The shields for the major certificate authorities
Every authority below is measured with exactly the same calculation as the products, including the ones we do not sell. Pick one to see the detail.
DigiCert, RapidSSL, Thawte and GeoTrust
Sold by FairSSL- Compatibility
- 10 / 10
- Cross-Sign
- Not needed
- Root certificate
- DigiCert Global Root G2 (2013)
- Of that, from the root itself
- The whole score comes from the root itself
- Windows2013
- Apple2013
- Android2013
- Linux2013
- Java2013
What it takes to install
No extra installation. The root is known in all five trust stores.
All four brands are issued today from DigiCert Global Root G2, a 2013 root that has been in all five trust stores for over a decade. The shields are therefore full from the root itself, with no help from a cross-signed chain.
From 15 October 2026 DigiCert issues from its new dedicated TLS roots, G5, by default. The FairSSL account is set to the G2 hierarchy and stays there for as long as DigiCert allows. We publish no date for when we stop, because that depends on DigiCert rather than on us.
GlobalSign and AlphaSSL
Sold by FairSSL- Compatibility
- 8.6 / 10
- Cross-Sign
- Requires 1
- Root certificate
- GlobalSign Root R46 (2019)
- Cross-signed to
- GlobalSign Root CA - R3
- Of that, from the root itself
- 4.3 points + 4.3 points via Cross-Sign
- Windows2021 → 2009
- Apple2022 → 2009
- Android2024 → 2009
- Linux2021 → 2009
- Java2024 → 2009
What it takes to install
Both an intermediate and a cross-signed certificate are required before this works reliably with older clients.
On Linux with nginx or Apache you put both in the chain file. The server sends exactly the file it is given.
On Windows it is particularly awkward: Schannel builds the shortest possible chain, so it can be necessary to disable the newer root certificates on the server before it finds the chain to the older root.
That can also affect what the server itself can reach, because no distinction is made between root certificates for inbound and outbound traffic.
GlobalSign moved all issuance to Root R46 on 27 July 2026, covering both the GlobalSign brand and AlphaSSL. The root dates from 2019, so it has not yet been in the stores long enough to fill the shields on its own.
The rest is covered by the cross-signed certificate to GlobalSign Root CA - R3, which we deliver alongside the certificate. On Linux, sending the chain is enough. On Windows, Schannel builds the chain from the machine’s own stores, and the cross-signed certificate has to be installed there.
Sectigo and Entrust
Sold by FairSSL- Compatibility
- 8.1 / 10
- Cross-Sign
- Requires 1
- Root certificate
- Sectigo Public Server Authentication Root R46 (2021)
- Cross-signed to
- USERTrust RSA Certification Authority
- Of that, from the root itself
- 2.4 points + 5.7 points via Cross-Sign
- Windows2023 → 2010
- Apple2025 → 2010
- Android2025 → 2010
- Linux2024 → 2010
- Java2025 → 2010
What it takes to install
Both an intermediate and a cross-signed certificate are required before this works reliably with older clients.
On Linux with nginx or Apache you put both in the chain file. The server sends exactly the file it is given.
On Windows it is particularly awkward: Schannel builds the shortest possible chain, so it can be necessary to disable the newer root certificates on the server before it finds the chain to the older root.
That can also affect what the server itself can reach, because no distinction is made between root certificates for inbound and outbound traffic.
Sectigo moved during spring 2025, split by validation level: EV on 15 April, OV on 15 May and DV on 2 June. Everything is now issued from Sectigo Public Server Authentication Root R46, which dates from 2021 and is the youngest root in this comparison.
The cross-signed path leads to USERTrust RSA, a 2010 root that virtually every client knows. Because the root itself is new, more of the coverage comes from the chain than for the others, which is also why Sectigo sits lowest here without being worse in practice.
Entrust sold its public TLS business to Sectigo in 2024, after Chrome decided to stop trusting Entrust certificates issued from November 2024. Entrust’s own website uses a Sectigo certificate today, so an Entrust-branded TLS certificate comes in practice from the same root as the rest of Sectigo’s.
Certum
Sold by FairSSL- Compatibility
- 8.4 / 10
- Cross-Sign
- Requires 1
- Root certificate
- Certum Trusted Root CA (2018)
- Cross-signed to
- Certum Trusted Network CA
- Of that, from the root itself
- 3.6 points + 4.8 points via Cross-Sign
- Windows2021 → 2008
- Apple2023 → 2008
- Android2024 → 2008
- Linux2021 → 2008
- Java2008 via Cross-Sign
What it takes to install
Both an intermediate and a cross-signed certificate are required before this works reliably with older clients.
On Linux with nginx or Apache you put both in the chain file. The server sends exactly the file it is given.
On Windows it is particularly awkward: Schannel builds the shortest possible chain, so it can be necessary to disable the newer root certificates on the server before it finds the chain to the older root.
That can also affect what the server itself can reach, because no distinction is made between root certificates for inbound and outbound traffic.
Since 15 September 2025 Certum issues from Certum Trusted Root CA, a 2018 root. The older Certum Trusted Network CA loses trust on 15 April 2027.
The cross-signed certificate to Certum Trusted Network CA runs to 19 September 2028 and covers clients that do not yet carry the new root. Certum states that the new root may be missing on Android older than 14.
Let's Encrypt
Not sold by FairSSL- Compatibility
- 5.8 / 10
- Cross-Sign
- Requires 2
- Root certificate
- Root YE (2025)
- Cross-signed to
- ISRG Root X2
- Of that, from the root itself
- 0 points + 5.8 points via Cross-Sign
- Windows2019 via Cross-Sign
- Apple2015 via Cross-Sign
- Android2015 via Cross-Sign
- Linux2015 via Cross-Sign
- Java2015 via Cross-Sign
What it takes to install
Both an intermediate and a cross-signed certificate are required before this works reliably with older clients.
On Linux with nginx or Apache you put both in the chain file. The server sends exactly the file it is given.
On Windows it is particularly awkward: Schannel builds the shortest possible chain, so it can be necessary to disable the newer root certificates on the server before it finds the chain to the older root.
That can also affect what the server itself can reach, because no distinction is made between root certificates for inbound and outbound traffic.
Let's Encrypt issues from their Gen Y roots, Root YE for ECDSA and Root YR for RSA, both self-signed on 3 September 2025. The chain on letsencrypt.org is leaf, YE2, Root YE and then ISRG Root X2. They are new enough that no store carries them yet, so all of their coverage comes from the cross-signing back to ISRG Root X1 from 2015.
X1 is in turn the story of how a new root becomes widely distributed: it was cross-signed by DST Root CA X3 until 2024 and has managed without it since. That took about nine years. It is the same road every authority is on now, and the reason a low figure here does not mean a poor certificate.
Let's Encrypt is not sold by FairSSL. It is here because it is the most widely used ACME issuer and a useful yardstick for how long a new root takes to become known.
Google Trust Services
Not sold by FairSSL- Compatibility
- 9.2 / 10
- Cross-Sign
- Requires 1
- Root certificate
- GTS Root R1 (2016)
- Cross-signed to
- GlobalSign Root CA
- Of that, from the root itself
- 6.7 points + 2.5 points via Cross-Sign
- Windows2016 → 1998
- Apple2020 → 1998
- Android2022 → 1998
- Linux2019 → 1998
- Java2023 → 1998
What it takes to install
Both an intermediate and a cross-signed certificate are required before this works reliably with older clients.
On Linux with nginx or Apache you put both in the chain file. The server sends exactly the file it is given.
On Windows it is particularly awkward: Schannel builds the shortest possible chain, so it can be necessary to disable the newer root certificates on the server before it finds the chain to the older root.
That can also affect what the server itself can reach, because no distinction is made between root certificates for inbound and outbound traffic.
GTS Root R1 dates from 2016. Google still delivers the cross-signed chain to the 1998 GlobalSign Root CA by default, precisely to reach older clients, and that path expires on 28 January 2028 along with the old root.
Google Trust Services is not sold by FairSSL. Its certificates are issued through Google Cloud and through Google’s own services.
Amazon Trust Services
Not sold by FairSSL- Compatibility
- 9.4 / 10
- Cross-Sign
- Not needed
- Root certificate
- Amazon Root CA 1 (2015)
- Of that, from the root itself
- The whole score comes from the root itself
- Windows2015
- Apple2015
- Android2015
- Linux2015
- Java2020
What it takes to install
No extra installation. The root is known in all five trust stores.
Amazon Root CA 1 dates from 2015 and sits in all five stores. Everything issued through AWS Certificate Manager comes from it, so many sites run on it without having chosen it deliberately.
Amazon Trust Services is not sold by FairSSL, and its certificates can only be used on AWS services.
GoDaddy and Starfield
Not sold by FairSSL- Compatibility
- 7.5 / 10
- Cross-Sign
- Requires 1
- Root certificate
- GoDaddy TLS Root CA - R1 (2025)
- Cross-signed to
- Go Daddy Root Certificate Authority - G2
- Of that, from the root itself
- 0 points + 7.5 points via Cross-Sign
- Windows2009 via Cross-Sign
- Apple2009 via Cross-Sign
- Android2009 via Cross-Sign
- Linux2009 via Cross-Sign
- Java2009 via Cross-Sign
What it takes to install
Both an intermediate and a cross-signed certificate are required before this works reliably with older clients.
On Linux with nginx or Apache you put both in the chain file. The server sends exactly the file it is given.
On Windows it is particularly awkward: Schannel builds the shortest possible chain, so it can be necessary to disable the newer root certificates on the server before it finds the chain to the older root.
That can also affect what the server itself can reach, because no distinction is made between root certificates for inbound and outbound traffic.
GoDaddy has issued from GoDaddy TLS Root CA - R1, a dedicated TLS root, since September 2025. It is new enough that none of the five stores carry it yet, so all of its coverage comes from the cross-signed chain to their own 2009 root, Go Daddy Root Certificate Authority - G2, which all five stores have had for over fifteen years.
They are in the middle of the same transition as the rest of the industry, and their certificates need the same cross-signing to reach older clients. The chain is verified on starfieldtech.com, which is where GoDaddy shows their current TLS hierarchy.
GoDaddy is not sold by FairSSL. It is here because many hosting customers receive their certificate this way without having chosen the authority deliberately.
SSL.com
Not sold by FairSSL- Compatibility
- 6.8 / 10
- Cross-Sign
- Requires 1
- Root certificate
- SSL.com TLS RSA Root CA 2022 (2022)
- Cross-signed to
- SSL.com EV Root Certification Authority RSA R2
- Of that, from the root itself
- 2.4 points + 4.4 points via Cross-Sign
- Windows2024 → 2017
- Apple2025 → 2019
- Android2025 → 2019
- Linux2024 → 2017
- Java2025 → 2021
What it takes to install
Both an intermediate and a cross-signed certificate are required before this works reliably with older clients.
On Linux with nginx or Apache you put both in the chain file. The server sends exactly the file it is given.
On Windows it is particularly awkward: Schannel builds the shortest possible chain, so it can be necessary to disable the newer root certificates on the server before it finds the chain to the older root.
That can also affect what the server itself can reach, because no distinction is made between root certificates for inbound and outbound traffic.
SSL.com issues TLS today from SSL.com TLS RSA Root CA 2022. It is the youngest root in this comparison, so most of the coverage comes from the cross-signed certificate to their own older EV root from 2017.
SSL.com is not sold by FairSSL. They issue a share of Cloudflare’s certificates among others, so plenty of people meet them without having chosen them.
The numbers come from the same half-yearly snapshots of the five trust stores for every authority. If we were missing an authority’s cross-signed certificate it would look worse than it is, so we collect those too.
How each shield is calculated
We record a snapshot of each of the five trust stores twice a year, on 1 January and 1 July. A snapshot is the list of root certificates the store contained on that day. The series starts in 2018, as far back as the versioned sources reach.
The shield fills with what your clients can actually validate. The colour shows how.
The dark blue part is the root itself: snapshots containing the root, capped at 20, divided by 20. Twenty snapshots is ten years. The light blue part is what one cross-signed certificate adds on top, and the amber part what two add.
Each store is worth two points, so five stores make ten. Points depend on how the coverage is reached: the root itself counts 2.0, one cross-signed certificate 1.5, two 1.0. A shield can therefore be full in more than one way, and the number tells you which.
A bridged path weighs slightly less not because it is unsafe. It works. But it depends on the chain being installed correctly on the server, and on Windows that is real work, because Schannel builds the chain itself from the machine's own certificate stores.
Roots already present in a store's first snapshot count as present in every earlier period. Otherwise roots from before 2018 would be penalised for our series not reaching further back.
The calculation happens at display time from the dates, not at data entry. The share coming from the root itself therefore grows on its own as the root ages, and the light blue part shrinks to match. GlobalSign Root R46 stood at 0.55 in the Windows shield in 2026 and reaches 1.0 in 2030 without anyone touching the configuration.
The root itself and the cross-signed certificate
The dark blue part of a shield counts only the self-signed root certificate the CA is issuing from right now. A cross-signed certificate does not make the root older or more widely distributed: it is the same key and the same name, signed by an older root.
Stopping there would be misleading, though. FairSSL delivers the cross-signed chain by default, both in downloads and in the ACME response, so a client that has never heard of Sectigo Public Server Authentication Root R46 still validates the certificate through USERTrust RSA. Five empty shields would state something about the product that is not true.
So the shield fills to the coverage the customer actually gets, and the colour keeps the two apart: what the root manages on its own, and what the chain closes. A brand new root does not inherit the old root's reputation, because the light blue part counts for less than the dark blue and only disappears once the root itself has caught up.
The symbols next to the shields
Chain shape is not subtracted from the shields. It is shown as separate symbols so you can see what costs what.
| Symbol | What it shows |
|---|---|
| Chain links | The number of intermediates between the server certificate and the root. A short chain has a single intermediate. |
| Cross-sign 0, 1 or 2 | How many cross-signed links are needed to reach the broadest old root we have configured for that CA. GlobalSign R46 to R3 through r3r46cross2019 is 1. GlobalSign R46 to R6 and on to R3 is 2. |
| Windows marker | Shown when reaching the older clients on Windows Server requires both a cross-signed certificate and a disabled root. Windows builds the chain itself and picks the shortest path, so the cross-signed certificate stays unused until the new root is switched off locally. |
The Windows procedure is in the guides for Sectigo, GlobalSign and AlphaSSL and DigiCert G5.
When data is missing
Missing data must never read as absence. An empty shield would penalise a root for our own lack of sources. The rules are therefore:
- The root is included, but the date is unknown. We use the root certificate own
notBeforeplus twelve months and mark the shield as estimated. The estimate is replaced automatically as soon as a documented date exists. Sectigo Public Server Authentication Root R46 is in that state for the Windows shield: Microsoft includes the root but has not published a month. - We do not know whether the root is included. That shield is not drawn at all and the total reads "not assessed" instead of a number. Half the evidence does not produce half a number.
- The root is verified absent. Only here does the shield sit at zero. Sectigo R46 is zero in the Android shield for Android 13 and older, because the root never reached those versions.
Data sources
- Windows, Apple, Android and Linux: trust_stores_observatory, which keeps one versioned YAML file per trust store. The git history yields the content of each store at any date, and we check out the commit nearest 1 January and 1 July.
- Java: OpenJDK under
src/java.base/share/data/cacerts/, one file per root with a history per release branch. The observatory Java files are not used, because they have not been updated since 2020 and 2022. - Cross-checks: the Mozilla
certdata.txt, AOSPplatform/system/ca-certificates, the Chromeroot_store.textproto, the Microsoft CCADB report and the per-OS lists on support.apple.com. - Announced removals: the root programs own notices. An announced date feeds into the calculation, so the shield drops on the day without manual work.
Client population is deliberately excluded. Market share moves faster than trust stores, and a number built on it would change for reasons that have nothing to do with the root certificate. The shields measure presence over time and nothing else.
Frequently asked questions about the shields
Find answers to the most common questions about SSL certificates and FairSSL.
Not sure which product fits your client population?
Create a free account and order your first certificate. A DV certificate is issued in under 2 minutes.