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