Modern (public) TLS has only a limited number of intermediate certificates

May 22, 2022

TLS certificates for servers 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.

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:

[...] 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). [...]

(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 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, 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.)


Comments on this page:

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.

Note that there is the concept of "Name Constraints", see RFC 5280 § 4.2.1.10:

The name constraints extension, which MUST be used only in a CA certificate, indicates a name space within which all subject names in subsequent certificates in a certification path MUST be located. Restrictions apply to the subject distinguished name and apply to subject alternative names. Restrictions apply only when the specified name form is present. If no name of the type is in the certificate, the certificate is acceptable.

Technically speaking, name constraints don't apply to Common Name (CN) attributes, only to dNSName and Subject Alt Name (SAN) and such, but since about 2017 most major browsers (Chrome 58+, Firefox 48+) have mandated subjectAltName in certificates:

So at this point in time it would technically be possible for root-CAs to issue intermediate certs to organizations that are limited to the domains that those orgs own.

Written on 22 May 2022.
« Some things that make languages easy (or not) to embed in Unix shell scripts
Systems should expose a (simple) overall health metric as well as specifics »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun May 22 22:33:43 2022
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.