(Apparent) Certificate Authorities aren't always actual CAs

June 9, 2023

The CA news of the time interval is, to quote Matt Holt (also):

Well, I inadvertently discovered a zero-day RCE in acme.sh and got a Chinese CA to shut down overnight: <github issue link>

The CA in question was called 'HiCA', and even if you keep good track of the (many) TLS Certificate Authorities that your browser or operating system trusts, you may be scratching your head in puzzlement because you've never heard of it before. That's because this (now-ex) 'CA' was not an actual Certificate Authority, and it's far from the only such one.

What's going on is that these days there's a lot of white label reselling of what I could call root CAs, ie the Certificate Authorities that are trusted by browsers and systems. Resellers have their own website and brand, but they don't have a root CA certificate of their own in browsers; instead the TLS certificates they get for you are ultimately signed by someone else. Sometimes this is a very direct relationship, and the TLS certificate visibly belongs to the CA that the reseller is in front of. At other times, the reseller has a TLS intermediate certificate in their own name (for example). As Andrew Ayer explains on HN (I know), sometimes this involves the root CA generating and holding the intermediate CA certificate itself, basically so that the branding in the end TLS certificate can have the reseller's name on it instead of the root CA's name (see also).

Earlier this year, Andrew Ayer wrote a whole post on this complex area, The SSL Certificate Issuer Field is a Lie, which is well worth reading. That some CAs aren't real CAs matters not just because it's confusing at times like this, but also because the situation makes it rather unclear who you should talk to if a TLS certificate needs to be revoked as improperly issued or compromised. If you're lucky and contact a reseller, they will be able to pass your message on; if you're unlucky, you may have no way of doing this, especially on a timely basis (cf). Since such a 'CA' is only a reseller, not an actual root CA, it's not bound by any requirements for reporting certificate problems or having a timely response to reports, unlike actual root CAs.

(To deal with this, crt.sh has a button on each TLS certificate's page to tell you who and how to report problems to. I found this out via Filippo Valsorda. I don't know how you find out if you're not able to use crt.sh.)

There's no particular fix for this; it's just something we have to remember when dealing with the TLS certificate ecology. An organization that you deal with that calls itself a 'Certificate Authority' may or may not actually be one, and it can be hard to tell.

PS: It would be nice if all CA resellers were required to have a clearly accessible way of reporting problems with their resold TLS certificates, especially in the cases where the certificate is issued through an intermediate CA certificate with the reseller's name on it. However, I won't be holding my breath for that being a CA requirement; the current situation has been there for years and years.

Written on 09 June 2023.
« Let's Encrypt (really ACME) has a decent reason for (still) using CSRs
A potential issue with outstanding query limits in your DNS resolver »

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

Last modified: Fri Jun 9 22:56:49 2023
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.