The web is dependent on there being a robust, secure, and scalable set of CAs being able to provide TLS certificates. It is unhealthy for there to be a single provider because if for any reason they have an operational or security issue they could become unavailable leaving the web in a world of hurt.
Beyond that in the name of TLS reliability TLS certificate consumers should be relying on multiple CAs for their certificates. For example, to reduce exposure to outages your certificate lifecycle management solution should support failover from one CA to the next.
Another example of why you should use multiple CAs is to help ensure relying on party agility to changes in CAs, for example, if a CA changes which root key material they use you may lose (or gain) device compatibility, or if an issuing CA changes and someone is pinning you might break them. By to ensure device compatibility long term one should use multiple CAs to help ensure the relying party ecosystem you support is agile to these changes.
For this to work though you need to have an ecosystem of CAs you can use interchangeably, ACME (RFC 8555) helps here substantially because it provides a normalized way to interact with CAs to get these certificates. That is only helpful if there are multiple CAs that implement the protocol and if those CAs are able to scale to meet the needs of those who rely on them.
This is particularly important when you look at SaaS-like offerings the larger ones will often demand millions of certificates that need to be able to be revoked and re-issued in less than 24 hours in some cases so the scalability of the CA becomes particularly important.
Assessing the scalability of a CA is hard but one of the closest proxies you have is their overall market share.
In the US, according to the Google Transparency Report, 97% of all web traffic is protected with TLS. To put that in context there were 366.8 million registered domain names as of 2022.
Certificates can represent more than one domain name so depending on what you are measuring certificate count may not be the best metric to asses CA market share. With that said in the context of scalability, it’s probably a good metric.
What are some ways to evaluate the CA impact and market share?
- How many certificates are issued by the CA and are unexpired.
- How many domains are contained within the unexpired certificates issued by a CA.
- What percentage of web traffic would be covered by the certificates issued by a CA.
- What percentage of certificates issued by the CA are unexpired and actively in use.
Each of these answers different questions, and they progressively get harder to measure as you go down the list. The easiest by far is how many certificates are issued and still unexpired. This is because all CAs log what is called a pre-certificate to the Certificate Transparency ecosystem before issuance.
NOTE: Publication of a pre-certificate is not required by the rules of the ecosystem however not doing so would mean that users relying on that certificate would get an error.
While the existence of a pre-certificate doesn’t promise the certificate is in use it does signal that someone who controlled that domain wanted to use a certificate for that domain. They wouldn’t have bothered going to the trouble of doing that if there was not an intent to use the certificate in some way.
The easiest way to look at this data is to use the excellent https://crt.sh/cert-populations report. While it does go down from time to time it also provides very fresh views into the un-expired pre-certificate count.
NOTE: Since not all CAs publish what is referred to as the “final certificate” you can safely ignore the Certificate count data on this report.
So what does this data look like (As of July 29th, 2022)?
|ALL||Unexpired||ALL||Unexpired||% of Unexpired Population|
|Internet Security Research Group||2,834,892,521||264,685,335||2,553,476,280||228,023,480||50.18%|
|Google Trust Services LLC||17,284||178||28,112,662||15,443,306||3.40%|
|Asseco Data Systems S.A. (previously Unizeto Certum)||6,298,472||620||9,375,742||1,571,852||0.35%|
|Start Commercial (StartCom) Ltd.||1,495,580||98||2,866,004||883,022||0.19%|
|SECOM Trust Systems CO., LTD.||156,234||-1||12,217,668||242,815||0.05%|
|WoSign CA Limited||88,660||7||250,823||110,101||0.02%|
|Microsoft Corporation Core Services Engineering & Operations ( “Microsoft CSEO”)||216,448||73,560||212,905||74,697||0.02%|
|Deutsche Telekom Security GmbH||57,570||32||147,949||49,556||0.01%|
|Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT)||86,872||23,866||57,206||23,772||0.01%|
What you will see is the top 5 CAs out of 233 issue 98.59% of all TLS certificates. While I would like to see this distribution be more normalized to ensure that the ecosystem is not overly dependent on any one entity as far as health goes it does show there are several large providers out there that support the Web who have demonstrated they can scale to meet large certificate consumption needs.
One thing you will notice in this data is that the variability in the pre-certificate “ALL” and “Unexpired” count is quite large in some cases. This is because some CAs like Let’s Encrypt and Google Trust Services either predominantly, or exclusively issue shorter-lived certificates. This results in the certificate count in “All” being much higher than the “Unexpired” case.
So what can we take away from this data? I think there are four key takeaways:
- Support of certificate issuance via ACME has made shorter-lived certificates viable and they now represent the large majority of certificates on the web.
- Support of ACME has helped grow the percentage of the web that is encrypted from about half of the web to nearly 100% of the web.
- 2.15% of CAs issue 98.59% of all TLS certificates on the web.