4 ms·

Should count as probable cause for revoking the remaining 27k certificates then, no? It's not unreasonable to think someone has been exploiting this for years,

• cesarb 9y ago
  The remaining 27k certificates are probably the ones which were generated on and which never left the customer's premises. The only thing which could be siphoned in these cases is the CSR, which is harmless (it contains essentially the same info as the certificate, which is public).
  • 0x0 9y ago
    If the server was rooted, couldn't an attacker silently intercept and swap out a csr with their own during domain validation, and thus get certificates approved based on fraudulent csr where the corresponding private keys are controlled by the attacker? Maybe even throw in a few "oops, please retry validation" to hide the fact that a different public key was signed in the certificate and the real customer would be none the wiser (except for perhaps looking at CT logs)?
    • Xylakant 9y ago
      No. The CSR is tied to the key and the resulting certificate as well. Verifying that the CSR belongs to the key would be he CAs job, not the servers. If the server was rooted, an attacker could probably just use it to create an arbitrary new certificate - but revoking the legitimate cert won’t fix that.
      • 0x0 9y ago
        1. User validates domain and submits csr 2. Rootkit swaps out csr with one of its own whose private key is under its control and submits upstream to the CA 3. CA signs a cert because the domain was validated 4. Rootkit receives valid cert for its own private key 5. Rootkit presents a bogus error to enduser 6. Enduser tries again and rootkit lets it through End-result: there are now two certs and private keys for the domain, one of which is compromised? Just a though experiment. I'm not familiar with the domain validation flow this reseller site was using.
        • Xylakant 9y ago
          Like I said: If you compromise the Trustico servers which are a reseller, you could trick the CA into believing that a CSR is valid for a domain. This would get you a certificate with a key under your control. But revoking the certificate with the key under the owners control won’t fix this. The illegitimate certificate would still be under the attackers control and remain valid.
          • 0x0 9y ago
            Unless you revoke all the certs issued through that channel/reseller - the legitimates would be collateral damage but you'd also get rid of any illegitimate ones?
            • Xylakant 9y ago
              If you compromised the reseller, would you have the reseller keep a list of illegitimate certificates that you issued via that channel?
              • 0x0 9y ago
                Surely the actual CA has a database of certificates it has issued and by which reseller?
        • pixl97 9y ago
          Certificate transparency logs would out that pretty quickly.
        • zaarn 9y ago
          1. Rootkit issues cert and sends to hacker I find this plan to be much much easier.
          • 0x0 9y ago
            Presumably, even if you had root on the reseller website, you would need to wait for the domain owner to actually perform a domain validation before the actual CA's system would deliver any certificates?
    • wolfgang42 9y ago
      Wouldn't that attack mean that the cert the domain owner got wouldn't work on their webserver, since they didn't have the correct private key for it?
      • 0x0 9y ago
        Yes, but you could fool the user with an error message so the user tries again and let it through unmodified? (Hide the fact that a cert was actually issued already)