[0x0]

Looks like they are issuing under a sub-CA of "ssl.com" according to https://github.com/acmesh-official/acme.sh/issues/4659#issue...

Interestingly, the mozilla dev-security-policy group seems to contain a recent discussion about including "ssl.com" in the root store here https://groups.google.com/a/mozilla.org/g/dev-security-polic...

Curious to know if this could, maybe it should, have ripple effects to the various SSL Root CA programs. Having someone run a subCA that actually exploits an RCE against ACME clients doesn't seem very trustworthy, and any CA enabling this behaviour should probably be kicked out of the trust stores?

[agwa]

The sub CA is operated by ssl.com, not HiCA (which is not a trusted certificate authority). HiCA is relaying the certificate requests to ssl.com, which is properly validating the requests in accordance with all the requirements. ssl.com isn't doing anything wrong. That's why HiCA needs to exploit an RCE in acme.sh - ACME doesn't support relaying certificate requests to other CAs like this.

[0x0]

Someone posted a comment on github claiming they are the founder of Quantum (the sub CA of ssl.com - see https://crt.sh/?caid=200960 ) and that they are the provider of the HiCA service. So it does sound like there is a closer link here than your comment would indicate:

https://github.com/acmesh-official/acme.sh/issues/4659#issue...

[agwa]

Quantum is not a trusted CA. ssl.com has a white-labeled intermediate CA with the name "Quantum" in it, but this intermediate CA is operated by ssl.com under all the same controls as ssl.com's other intermediate CAs. Quantum has no ability to issue trusted certificates themselves.

[0x0]

So the person claiming to be the founder of "QuantumCA" does not possess the private key corresponding to https://crt.sh/?caid=200960 - can we be sure the private key is only accessible by ssl.com's CA system? So the certificates listed here aren't issued by this person, but by the ssl.com's system? https://crt.sh/?Identity=%25&iCAID=200960&exclude=expired&de...

Also, why would ssl.com even create a subCA named "QuantumCA"? Are they in business with this person claiming to be the founder of "QuantumCA" who appears to be responsible for exploiting this acme.sh 0day? What does this say about ssl.com's trustworthiness? Or is the person in the github comments lying?

[agwa]

> So the person claiming to be the founder of "QuantumCA" does not possess the private key corresponding to https://crt.sh/?caid=200960 - can we be sure the private key is only accessible by ssl.com's CA system? So the certificates listed here aren't issued by this person, but by the ssl.com's system? https://crt.sh/?Identity=%25&iCAID=200960&exclude=expired&de...

Correct. You can see the Quantum intermediates listed in ssl.com's most recent audit statement, meaning an auditor has verified that ssl.com has controls to protect the private key: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?at...

(The audit could be flawed, but it's the same amount of assurance we have for any intermediate CA's private key - the fact that "QuantumCA" is in the name does not change the risk calculus)

> Also, why would ssl.com even create a subCA named "QuantumCA"? Are they in business with this person claiming to be the founder of "QuantumCA" who appears to be responsible for exploiting this acme.sh 0day? What does this say about ssl.com's trustworthiness? Or is the person in the github comments lying?

There is a business relationship between QuantumCA and ssl.com. QuantumCA is a reseller of ssl.com, and they've paid extra to ssl.com so that the certificates they purchase get issued from an intermediate CA named "QuantumCA" rather than one of ssl.com's usual intermediate CAs which have "ssl.com" in the name. This lets QuantumCA pretend to be a real CA. This is a common practice in the industry, and I don't think it says anything about the trustworthiness of ssl.com, because the business relationship with QuantumCA doesn't in any way subvert the integrity of the WebPKI since ssl.com retains control of the issuance. Still, I wish intermediate CA white-labeling were banned because it causes terrible confusion about who is and isn't a CA.

[0x0]

I find it troubling that a root CA (ssl.com) is apparently OK with lending their name in a business relationship with an actor that is actively exploiting an acme.sh 0day.