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

[tptacek]

This feels a little bit like doubling down to find ways to implicate the actual CA instead of the reseller. It's clear how mismanagement by a real CA would make a more interesting story than by this random no-longer-existing pseudo-reseller, but I don't think there's evidence to support that story yet.

[0x0]

But it's not a random pseudo-reseller? The one github comment from "the founder of Quantum CA" seems to say they are also the creator of HiCA, which is the entity that was exploiting the 0day in acme.sh. And the crt.sh link shows an intermediate CA cert named "QuantumCA", signed by ssl.com.

So QuantumCA == HiCA == exploiters of the acme.sh 0day, it's all the same entity? The intermediate CA could just as well be named "0dayexploitersCA"? Why is it not a huge concern that ssl.com is fine with operating such a "0dayexploitersCA" intermediate?

Am I missing something here?

[zhfliz]

Quantum CA (brand, not operator)/HiCA still can't issue certs for domains they don't "control" by having RCE on the systems they point to.

all CA requirements for validation still need to be fulfilled for issued certificates, as ssl.com, the Quantum CA operator, which exclusively holds the private keys, is a "proper" CA.

this does not affect the trust in the CA infrastructure or ssl.com itself; while this is morally questionable to keep the business relationship, it does not mean the CA is not following the signing requirements.

[mholt]

I honestly don't think anyone else knew about the RCE until yesterday.