== Modern (public) TLS has only a limited number of intermediate certificates [[TLS certificates for servers TLSCertificatesNamingHosts]] are not normally signed directly by the Certificate Authority's root certificate (for various good reasons); instead, they're signed by an *intermediate certificate* that chains up to the CA's root certificate (in modern usage, there generally is only one intermediate certificate between the server certificate and the CA's root certificate). In theory the server is supposed to send the intermediate certificate with its own certificate in a *certificate chain*, but [[in practice servers don't always send intermediate certificates and this can cause mysterious problems ../web/TLSIntermediateCertHell]]. In the old days, one part of this problem is that there were a lot of intermediate certificates and no one really knew what they all were. I won't say that Certificate Authorities created intermediate certificates freely, because I'm sure they charged a lot of money for them, but in practice CAs were relatively willing to give intermediate certificates to third parties who were sufficiently persuasive. Those days are over. In the modern TLS world, intermediate certificates are limited, controlled, and known (and thus very finite). Third party intermediate certificates, ones not under the control of the Certificate Authority that signed them, are especially out of favour and many of them are now dead. Encountering a genuinely unknown intermediate certificate is generally the sign that some Certificate Authority is about to have a bad time, as browser security people descend on it with very pointed questions. The simple version of what triggered this transition is that browsers became increasingly aware that third party intermediate certificates were essentially root Certificate Authorities with less visibility and adult (ie, browser) supervision. TLS intermediate certificates have never really had an effective limit on what TLS server certificates they could sign and have accepted by people, which meant that everyone with a TLS intermediate certificate could create a probably-valid TLS server certificate for any random website, like say google.com. Browsers didn't like this for obvious reasons and so they eventually cracked down. These days things are much more restricted, even for intermediate certificates controlled by Certificate Authorities. Let me quote [[the Mozilla article on preloading intermediate certificates into Firefox https://blog.mozilla.org/security/2020/11/13/preloading-intermediate-ca-certificates-into-firefox/]]: > [...] As a result of Mozilla’s leadership in the CA community, each > CA in Mozilla’s Root Store Policy is required to disclose these > intermediate CA certificates to the multi-browser [[Common CA Database > (CCADB) https://www.ccadb.org/]]. [...] (In the browser crackdown, Certificate Authorities were required to identify all of the intermediate certificates that they had issued and mostly either bring them back under their control or see the intermediate certificates destroyed. Browsers held the cards here because they had various measures to control what intermediates were accepted for various Certificate Authorities.) In case anyone is tempted to cheat (or slips up by accident), [[Certificate Transparency https://en.wikipedia.org/wiki/Certificate_Transparency]] makes it relatively easy to detect new intermediate certificates, at least for anything you want to be usable in major browsers. A TLS certificate logged into CT logs includes [[information on what certificate signed it TLSCertificateIdentity]], so interested parties can monitor the CT logs to detect mentions of new ones. In many cases they will be able to obtain a copy of the new intermediate certificate, letting them identify in turn who signed it. (I don't know if Chrome requires intermediate certificates to also be in the CT logs, but if it does you can directly look for new ones there. Intermediate certificates are recognizably different from TLS server certificates.)