36 ms·

Why do you all think DigiCert handled this badly? 1. Bugs happen. Critical ones, too. They didn't try to brush this under the carpet, but admitted to it, acted

Why do you all think DigiCert handled this badly? 1. Bugs happen. Critical ones, too. They didn't try to brush this under the carpet, but admitted to it, acted to resolve it and were transparent about it. 2. They worked quickly to make it happen. Would 24h been nice? Sure, but 24h is not much shorter than 120h. In general, 24h is plenty of time for some exploits and 120h doesn't open the window to many more. It would have been very different if it took them months or years to resolve it. 3. They genuinely engaged with the critics on bugzilla, even after Sectigo's CCO went completely off the rails with trying to strip customers off legal recourse and demanding to blacklist those who try to make use of it. 4. They could have taken legal actions against Sectigo's CCO directly but took the extra step to ask them to stop this nonsense. They didn't demand anything more and even outlined steps Sectigo needed to take to prevent any legal problems down the line, like affirming that their CCO did not make these statements on behalf of Sectigo, an affirmation that they would notify their employees to not make any actions that would violate the laws mentioned in their letter, affirm that their CCO would be instructed not to violate any of the laws outlined in their letter and lastly confirm that, upon consulting with their CCO, they were able to conclude that his statements were not meant to harm DigiCert. The only ick is the short timeframe they expect a reply within, but that's sadly usual corporate US law practice... Basically that letter is the result of asking an US law firm for help and telling them to be nice about it and helping their opponent through the process.

deleted 2y ago
[deleted]
SAI_Peregrinus 2y ago
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.
aaronmdjones 2y ago
Yes, bugs happen. However, DigiCert could have handled these incidents a lot better. For example, in the first issue (delayed revocation after incorrect capitalisation), DigiCert chose to not revoke several thousand certificates within the required 5-day window for reasons ranging from "is in use in embedded devices and can't be replaced in a timely fashion" (this is a failure of the customer's automation and planning, not a failure of DigiCert, and is not a reason for DigiCert to not revoke) to "is being pinned in a mobile app and the app needs to be rebuilt and pushed to app stores" (this is again a failure of the customer; the customer should have foreseen the event that their certificate would be revoked, and, if they really wanted to pin, should have also had a hot standby certificate from another CA pinned, for example). Further, DigiCert's own certificate policy at time included the following text (in section 1.4.2): DigiCert strongly discourages key pinning and shall not consider it a sufficient reason to delay revocation. DigiCert chose to ignore their own policy, and allowed this decision to delay revocation. That was entirely their own choice, to appease their own customers at the expense of complying with both their own policy and the Baseline Requirements. The other more recent incident (the TRO) would have restrained DigiCert from revoking approximately 70 certificates. DigiCert chose to extend this delay to tens of thousands of certificates, issued to other customers who sought no restraining orders. DigiCert chose to ignore their own policy, and allowed this decision to delay revocation. That was entirely their own choice, to appease their own customers at the expense of complying with both their own policy and the Baseline Requirements. Are you starting to see a pattern?
- GreatAmus 2y ago
  [dead]
- 5minime 2y ago
  Yes, they're really good at making excuses. It seems like they could get away with anything.
darkarmani 2y ago
> They could have taken legal actions against Sectigo's CCO directly You are only suggesting they could have handled it worse. Why would they take legal action against the CCO for statements on a bug report other than to squash transparency?
coldpie 2y ago
> Sectigo's CCO went completely off the rails with trying to strip customers off legal recourse and demanding to blacklist those who try to make use of it Can you provide a link to this? I looked Callan's comments on the cited bug[1] and none of it struck me as being even a little off the rails. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1910322 https://bugzilla.mozilla.org/show_bug.cgi?id=1910322
- DeepPPP 2y ago
  CNAME bug must have had something so bad DigiCert didn't want people poking around. Perhaps it's worth taking a closer look at the bug thread. They were also pressing really hard to close it. Something smells.
  - 128bitz 2y ago
    [dead]
  - GreatAmus 2y ago
    [dead]
- DeepSeaTortoise 2y ago
  From here on: https://bugzilla.mozilla.org/show_bug.cgi?id=1910805#c30 https://bugzilla.mozilla.org/show_bug.cgi?id=1910805#c30

deleted 2y ago

[deleted]

SAI_Peregrinus 2y ago

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.

aaronmdjones 2y ago

Yes, bugs happen. However, DigiCert could have handled these incidents a lot better. For example, in the first issue (delayed revocation after incorrect capitalisation), DigiCert chose to not revoke several thousand certificates within the required 5-day window for reasons ranging from "is in use in embedded devices and can't be replaced in a timely fashion" (this is a failure of the customer's automation and planning, not a failure of DigiCert, and is not a reason for DigiCert to not revoke) to "is being pinned in a mobile app and the app needs to be rebuilt and pushed to app stores" (this is again a failure of the customer; the customer should have foreseen the event that their certificate would be revoked, and, if they really wanted to pin, should have also had a hot standby certificate from another CA pinned, for example). Further, DigiCert's own certificate policy at time included the following text (in section 1.4.2): DigiCert strongly discourages key pinning and shall not consider it a sufficient reason to delay revocation. DigiCert chose to ignore their own policy, and allowed this decision to delay revocation. That was entirely their own choice, to appease their own customers at the expense of complying with both their own policy and the Baseline Requirements. The other more recent incident (the TRO) would have restrained DigiCert from revoking approximately 70 certificates. DigiCert chose to extend this delay to tens of thousands of certificates, issued to other customers who sought no restraining orders. DigiCert chose to ignore their own policy, and allowed this decision to delay revocation. That was entirely their own choice, to appease their own customers at the expense of complying with both their own policy and the Baseline Requirements. Are you starting to see a pattern?

GreatAmus 2y ago
[dead]
5minime 2y ago
Yes, they're really good at making excuses. It seems like they could get away with anything.

darkarmani 2y ago

> They could have taken legal actions against Sectigo's CCO directly You are only suggesting they could have handled it worse. Why would they take legal action against the CCO for statements on a bug report other than to squash transparency?

coldpie 2y ago

> Sectigo's CCO went completely off the rails with trying to strip customers off legal recourse and demanding to blacklist those who try to make use of it Can you provide a link to this? I looked Callan's comments on the cited bug[1] and none of it struck me as being even a little off the rails. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1910322 https://bugzilla.mozilla.org/show_bug.cgi?id=1910322

DeepPPP 2y ago
CNAME bug must have had something so bad DigiCert didn't want people poking around. Perhaps it's worth taking a closer look at the bug thread. They were also pressing really hard to close it. Something smells.
- 128bitz 2y ago
  [dead]
- GreatAmus 2y ago
  [dead]
DeepSeaTortoise 2y ago
From here on: https://bugzilla.mozilla.org/show_bug.cgi?id=1910805#c30 https://bugzilla.mozilla.org/show_bug.cgi?id=1910805#c30