Hacker News Reader

Comment by tptacek | Hacker News Reader

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.

View on HN

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?

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.

Reply on news.ycombinator.com