4 ms·

DigiCert miss-issued thousands of certs. Certificate authorities are required by contract (the CA/Browser Forum Baseline Requirements is a contract they agree

DigiCert miss-issued thousands of certs. Certificate authorities are required by contract (the CA/Browser Forum Baseline Requirements is a contract they agree to when being granted trust as a CA) to revoke miss-issued certificates within 24 hours of the time they learn of the miss-issuance. One of their customers filed a court case & got a temporary restraining order (TRO) preventing DigiCert from revoking ≈70 of those certs within 24 hours. DigiCert then proceeded to delay revocation beyond the 24 hour limit *for all the certs, not just the ≈70 that the TRO covered. That is a violation of the CA/Browser Forum Baseline Requirements. Failure to revoke ≈70 certs because of a court order could be accepted, but failure to revoke thousands of other certs (putting customers at risk) should not be.

genewitch 2y ago
DigiCert said they could not extricate the TRO from "critical infrastructure" Whether you believe them, or not, there was a valid reason given. They also said they fixed this particular issue internally, so I guess we'll see. DigiCert had over two million certs issued per the "businessEntity" case sensitivity bug thread, which was 2023. They revoked ~84,000 out of an abundance of caution - my read was they revoked every cert issued from the (now defunct) system digicert called "OEM" - which had the bug where it wasn't prepending an underscore. I just read the entirety of the underscore and the case sensitivity threads.
- SAI_Peregrinus 2y ago
  Mostly correct. The issue is that only about 70 certs out of those 84k were actually covered by the TRO. They could have revoked the rest, as they were obligated to do by the Baseline Requirements. They didn't, they delayed.
  - genewitch 2y ago
    Right, the "reason" for that in the report was they couldn't extricate the 70 certs from the critical infra from the other 80k OEM certs. I'm trying very hard to be charitable. I don't know anything about digikey. But it could be incompetence; legal dept getting cold feet because someone filed a TRO in a court against the company; malice?
    - SAI_Peregrinus 2y ago
      Incompetence from a CA isn't an excuse, it's a breach of the contract (the baseline requirements) & a reason to distrust them. Likewise for malice. The legal department getting cold feet would be a really bad reason to risk the entire business by violating the contract, only an incompetent legal department would recommend breaking the contract that the business depends on to exist. DigiCert (not DigiKey, they're an unrelated electronics component supplier) is in the business of selling certificates; that depends entirely on them remaining trusted to issue certificates.
      - genewitch 2y ago
        i merely typoed, i'm your GGP to your comment \^ i don't disagree with what you're saying, either; digicert never really answered why they couldn't get the other 83k revocations done faster, hoping "we couldn't do it, sorry" in the revocation bug report would suffice.
      - 5minime 2y ago
        I fully agree. Malice and trust are fundamentally incompatible.
- 5minime 2y ago
  I'm not sure you can fully trust what's in the report. A lot of it seems like an attempt to obscure the truth by using internal jargon and vague statements like "Engineer did engineering stuff"—which ultimately means nothing.

genewitch 2y ago

DigiCert said they could not extricate the TRO from "critical infrastructure" Whether you believe them, or not, there was a valid reason given. They also said they fixed this particular issue internally, so I guess we'll see. DigiCert had over two million certs issued per the "businessEntity" case sensitivity bug thread, which was 2023. They revoked ~84,000 out of an abundance of caution - my read was they revoked every cert issued from the (now defunct) system digicert called "OEM" - which had the bug where it wasn't prepending an underscore. I just read the entirety of the underscore and the case sensitivity threads.

SAI_Peregrinus 2y ago
Mostly correct. The issue is that only about 70 certs out of those 84k were actually covered by the TRO. They could have revoked the rest, as they were obligated to do by the Baseline Requirements. They didn't, they delayed.
- genewitch 2y ago
  Right, the "reason" for that in the report was they couldn't extricate the 70 certs from the critical infra from the other 80k OEM certs. I'm trying very hard to be charitable. I don't know anything about digikey. But it could be incompetence; legal dept getting cold feet because someone filed a TRO in a court against the company; malice?
  - SAI_Peregrinus 2y ago
    Incompetence from a CA isn't an excuse, it's a breach of the contract (the baseline requirements) & a reason to distrust them. Likewise for malice. The legal department getting cold feet would be a really bad reason to risk the entire business by violating the contract, only an incompetent legal department would recommend breaking the contract that the business depends on to exist. DigiCert (not DigiKey, they're an unrelated electronics component supplier) is in the business of selling certificates; that depends entirely on them remaining trusted to issue certificates.
    - genewitch 2y ago
      i merely typoed, i'm your GGP to your comment \^ i don't disagree with what you're saying, either; digicert never really answered why they couldn't get the other 83k revocations done faster, hoping "we couldn't do it, sorry" in the revocation bug report would suffice.
    - 5minime 2y ago
      I fully agree. Malice and trust are fundamentally incompatible.
5minime 2y ago
I'm not sure you can fully trust what's in the report. A lot of it seems like an attempt to obscure the truth by using internal jargon and vague statements like "Engineer did engineering stuff"—which ultimately means nothing.