DigiCert: Threat of legal action to stifle Bugzilla discourse
200 comments
·February 25, 2025nneonneo
jeroenhd
Reads to me like Digicert is hiding behind the TRO to protect themselves from upset customers over following the procedures they should have followed. I don't think they want to update their legal work to prevent customers from legal action over revocation, legal action has been working in their favor so far.
For a company whose entire business is verifying company names and handling the CA process, Digicert seems rather unwilling to actually stick to the process. They can't help having a TRO filed against them by customers with incompetent tech such as Alegeus Technologies LLC, but this isn't the first time they've failed to follow the appropriate processes.
Going through the courts to stop negative discourse seems rather crass for a CA. I don't understand why a company that has been subject of suspicion and doubt lime Digicert would do such a thing unless it's a last-ditch effort to get the heat off their backs.
I'm sure their clients love Digicert for not forcing them to replace their certificates at the appropriate times, but they're in for a surprise when this whole thing blows up and they suddenly need to find another cert vendor when Digicert gets delisted.
hmmm-i-wonder
This seems like a misunderstanding of the TRO.
Alegeus, a client of DigiCert, filed a court motion to stop DigiCert from revoking their certificate. The courts granted the temporary restraining order.
There is no "update their legal work to prevent customers from legal action" that can avoid a temporary restraining order that is ordered by the courts to provide time to establish facts. Its simply how the legal process works. "they can't help but" seems unfair as the issue was the client Alegeus was unable to replace their certificates in the revocation timeline.
Further "Going through the courts", they didn't go to the courts a client of theirs did.
Digicert is absolutely not blameless. Outside of the TRO, they have failed to meet revocation windows before and yes, are likely using the TRO in this instance as a shield for that.
However the TRO itself is a concerning development that all CA's need to consider depending on their legal jurisdiction, as it could put companies in a bind of being legally ordered to not to complete something they are contractually and legally required to do within the required timeline and interrupt standard security practices in cases like this.
lokar
Would a judge not consider potential harm to each party if the TRO is granted or not?
If the CA could credibly point out they would face severe consequences for failure to revoke, could that have an impact on?
michaelt
I dunno, seems to me in the TRO case there wasn't anything wrong with the certificates that had been issued. There wasn't any suggestion the the certificates had been issued to the wrong party or anything like that.
When performing DNS verification there's supposed to be an underscore in a record, which protects sites that let their users control arbitrary subdomains - you know, dyndns and things like that. Digicert mistakenly didn't ask the customer to include an underscore. Could have been a problem, if Alegeus was a dyndns provider - but they aren't.
Then Digicert spent a load of the 24 hour disclosure window checking things on their end, then e-mailed the customers after office hours so when they get in the next day they barely had any time to respond.
The only "incompetent tech" here is the assholes who decided on the policy that certificates be urgently revoked, as if they'd been issued to the wrong person, when they hadn't been issued to the wrong customer.
hmmm-i-wonder
The middle ground here is DigiCert should have been able and continued with the revocation of all the other certificates not impacted by the TRO within the policies and contractual agreements it has.
The policy and its designers aren't incompetent, the intention is to ensure security first when fact-finding can take time to establish a subset of actual abuse. This is common in IT/Security and is clearly communicated in the policy customers agree to as well as something agreed on by all CA's. Security > Uptime is the baseline, and while you may disagree with that and have good arguments for the contrary, the argument is much wider than us and has been extensively hashed out in the working groups and discussions around this and other similar issues and is implemented this way by consensus while weighing valid arguments for different approaches and pros and cons.
Thorrez
>Could have been a problem, if Alegeus was a dyndns provider - but they aren't.
AFAIUI, Alegeus was just 1 customer of Digicert. But Digicert has tons of customers. Just because there wasn't a problem for Alegeus (due to Alegeus not being a dyndns provider), doesn't mean there weren't problems for other Digicert customers.
crote
Revocation rules are intentionally very strict, in order to prevent CAs from weaseling out of them. If you leave open any possibility of a CA delaying or refusing revocation because of some form of "it's an administrative issue, it isn't that serious anyways", every incident will inevitably result in a weeks-long discussion about the real impact of the incident and whether this one is "serious enough" to require immediate action.
In the past CAs have been more than happy to lie and downplay incidents, because they know their customers don't like revocations and are going to consider switching to a competitor. Maybe not a big deal in practice for a technicality, but it does mean that CAs can not be trusted to always be truthful - and that in turn extends to serious incidents. This is obviously really bad for the web PKI as a whole, so the rule is that any violation of the rules, no matter how small or nitpicky, must be treated as if it were a serious security incident. Don't agree with the rules or think the rule is interpreted the wrong way? File a report afterwards to review the rules.
The entire business of a CA is to be a trusted third party. If you can't be trusted to always follow the rules exactly to the letter, you shouldn't be a CA. Behaving predictably is more important than being right about some technical minutiae regarding the security impact of some incident.
wbl
There was something wrong. They hadn't been issued in accordance with the baseline requirements.
cjbprime
The fact that those certificates had been issued without a secure method of verification is the thing that was wrong with those certificates.
Dyndns is not the only use case for having someone control a subdomain without having the full trust of the root domain.
12_throw_away
No. Our cert infrastructure needs to meet the highest standards possible, this is not an area where "welp, no harm done, don't worry about it" is acceptable.
e40
Here is the last reply from Callan:
https://bugzilla.mozilla.org/show_bug.cgi?id=1910322#c73
Seems extremely reasonable to me.
RHSeeger
What is the correct action when a TRO says a company cannot revoke the cert? Is it that the company will delay revocation, but will push the judicial system to resolve the issue as fast as possible?
nneonneo
DigiCert probably should have revoked every cert they could within 24 hours. Instead they just pushed the revocation of all 80,000+ certs out to five days.
It's quite likely that many of their other clients pushed back on the 24-hour timeline (similar to what happened in their previous incident); I believe the delayed revocation issue (https://bugzilla.mozilla.org/show_bug.cgi?id=1910322) hints at this. The TRO gave them a convenient excuse to delay all revocations without having to explain all over again why they made exemptions for their special clients.
Heck, their status page (https://status.digicert.com/incidents/3sccz3v31lc9) even gives instructions for how to request a delayed revocation - even though the initial incident page (https://www.digicert.com/support/certificate-revocation-inci...) says clearly:
"Any issue with domain validation is considered a serious issue by CABF and requires immediate action. Failure to comply can result in a distrust of the Certificate Authority. As such, we must revoke all impacted certificates within 24 hours of discovery. No extensions or delays are permitted. We apologize if this causes a business disruption to you and are standing by to assist you with validating your domain and issuing replacement certificates immediately."
Dylan16807
I think the eventual correct option is pretty clear.
A TRO like that is based on the company loudly declaring that revoking will cause real damage. That means their use of certificates is incompatible with the web PKI rules and ecosystem. That means they need to be migrated out ASAP, with every certificate authority refusing to take their business.
Make that series of consequences clear, and companies will stop trying that trick.
hmmm-i-wonder
DigiCert and other CA's need to write in their terms that failure to follow the policies and revocation timelines can/will result in termination of the contract. Alegeus should have been dropped as a customer as soon as the incident was resolved and refused further products/renewals.
Use of a TRO protects you short term, but results in having to migrate to a new CA medium term. You can't stop them from using TRO's but you can make it not worth it.
asmor
I think that's pretty unrealistic, considering that X.509 is a de-facto and de-jure standard in a lot of places that also ignore that requirement. It's not always up to that company to make it possible to replace certificates easily, it's an entire chain of vendors (I know at least Salesforce's process would fail here). Unless you want those people to run self-signed/private CA certs.
The other option would be building in a way to revoke other CA's individual certificates if there's some consensus on them being compelled to not revoke them. Not sure if the status quo or this would be more dangerous, but if a TRO can compel a CA to not sign a revocation, can it also compel to sign a certificate?
kevin_thibedeau
How can a court inhibit revocation when every CA declares their right to do so when you purchase a certificate?
AnthonyMouse
The better question is, how do you prevent this tactic from working?
For example, suppose there were required to be multiple parties who could issue a revocation, each in a different jurisdiction, and if any of them was ordered not to do it then the others would be required to do it, and would have the technical capacity to do it but not be subject to the jurisdiction of that court.
michaelt
It’s Saturday and the courts are closed. You park in a car park I own.
I have put up a sign saying I can instantly crush any crossover vehicles I like, as I consider them ugly and lacking in character.
As I load your car into my crusher, you dispute the legality of my sign. But the court is closed until Monday, and the sign says I can crush your car instantly, no waiting.
Should I be allowed to crush your car today? Or should I have to wait until Monday, so the disputed legality can be resolved?
saurik
I can declare my right to do something as much as I want... that doesn't mean I get to do it, certainly not if a judge decides I can't.
dragonwriter
> How can a court inhibit revocation when every CA declares their right to do so when you purchase a certificate?
A court can rule that a term of a contract is void because it contradicts public policy, and it certainly can issue a TRO pausing an action which would otherwise be allowed by a contract while resolving a dispute related to it.
thayne
Because the judge doesn't know the details of how PKI works, and either the ToS for digicert doesn't spell out that they can revoke certs at any time (which would be problematic for a CA), or the judge didn't read, or didn't understand the ToS.
null
rlpb
The order would normally be a matter of public record, and the ecosystem should follow these events carefully and ensure never to issue a certificate to such a company again as it undermines the entire system.
jchw
Web PKI drama is always astonishing to me because it is one of the only areas of the entire world where a corporation's "fucking around" is seldom ever not followed by a sobering "finding out" period. The various entities that decide what CAs to trust can effectively dismantle any CA business in the world, basically at the drop of a hat. If DigiCert decides to play this game and lose, it would make them the biggest such loser so far. DigiCert is, as far as I know, the largest CA on the Internet. It would certainly send a strong message, and cause a lot of chaos, if the biggest CA on the Internet found itself being removed from trust stores. Yet, there's no particular reason it couldn't happen. How exciting.
Of course, I think that is unlikely, but on the other hand, it's just as cathartic to imagine whatever idiot at DigiCert thought it was a good idea to engage legal here to have the dressing down of a lifetime. I read the thread in question. It doesn't make DigiCert look good, but this action definitely is more damning to them than anything Collan said in my opinion.
chicom_malware
> It would certainly send a strong message, and cause a lot of chaos, if the biggest CA on the Internet found itself being removed from trust stores
Their customers would be forced to give their business to Honest Achmed[1].
bigfatfrock
Thank you, that was an awesome laugh this morning, that request was genius:
> 2. Sub CAs Operated by 3rd Parties
> Honest Achmed's uncles may invite some of their friends to issue certificates as well, in particular their cousins Refik and Abdi or "RA" as they're known. Honest Achmed's uncles assure us that their RA can be trusted, apart from that one time when they lent them the keys to the car, but that was a one-off that won't happen again.
skissane
Someone should start a real CA business, complete with all the proper audits and everything to get it into the browser trust stores… and call it “Honest Achmed’s Used Cars and Certificates” (have it buy some random used car dealership in the middle of nowhere so the name is not a lie)
Where’s a billionaire troll when you need one? (And a form of billionaire trolling that would upset a lot less people than Musk’s version of it.)
Would be even funnier if the billionaire’s name actually was Achmed
justahuman74
What has prevented this (a good legit CA co) from happening before now?
justahuman74
I'm actually curious why that wasn't approved
woodruffw
To my understanding, the point of Honest Achmed was to demonstrate that it was possible to write a facially reasonable and compliant CA inclusion request that was also intuitively unacceptable. It successfully demonstrated that the inclusion policies at the time needed to be made more rigorous, which they were.
urig
[flagged]
account42
> It would certainly send a strong message, and cause a lot of chaos, if the biggest CA on the Internet found itself being removed from trust stores. Yet, there's no particular reason it couldn't happen. How exciting.
Trust stores and Browsers specifically have more options than simply remove a CA. A more reasonable approach for distrust process of a CA this size would be to stop accepting any new certificates issued after a certain date. Then existing customers will have a heads up and even if asleep will find out the bad news during scheduled renewal rather than while the responsible employees are on vacation.
twisteriffic
It's refreshing to see folks who're obviously used to hiding behind clouds of bullshit get skewered by people who both know enough to see through it and have the time and energy to follow every thread to completion.
The most recent digicert thread smells suspiciously similar to those that lead up to the Entrust debacle.
axus
Is there any option to turn off trust for all certificates generated after a certain date? The ideal would be to let old certificates keep working, and not trust new ones.
duskwuff
It's been done previously, e.g. for Symantec:
https://security.googleblog.com/2017/09/chromes-plan-to-dist...
wolrah
Yes, this has been done a few times in the past. It's unfortunate that "distrust after X date" and "distrust now" are the only penalties that currently exist but that's the reality of the current PKI world.
There are a lot of efforts to get name constraints widely supported, so a given CA can only issue for certain TLDs or even domains, but it's still not there. That could be a viable punishment for misbehaving CAs in the future, or even an intentionally chosen restriction for CAs that want less strict requirements. Government CAs could be a very useful application, if a CA cert could be name constrained to only issue for .gov.cctld at that point we could basically just let them do whatever they want without concern. Likewise for any small regional CAs, if they could be limited to only regional TLDs their blast radius is reduced which also could mean less strict requirements than those applied to CAs able to sign for .com.
thayne
It would also be really useful if I could add a "root" CA for my employer's private CA to sign certificates for say .internal or .example.com, but not allow them to sign certs for any arbitrary domain. There's decent support for constraints on intermediate certs, but then you have to trust the root won't ever be used to sign unconstrained intermediates.
It would also be useful for localhost. Create a private CA that is constrained to localhost and *.local, and you don't have to worry about it being used to MitM other sites if it gets compromised.
userbinator
It would certainly send a strong message, and cause a lot of chaos, if the biggest CA on the Internet found itself being removed from trust stores.
How many will agree to that removal? How many will see one more reason to forever turn off automatic updates and decide what to trust themselves, having seen yet another way some faceless entity they never knew about can break things?
It will certainly send a strong message, but likely not the intended one. All it will do is increase the lack of trust in centralised PKI in general.
jchw
I'm not sure how to put this nicely, but I'll try my best: The normal people, who account for 99% of the end users of DigiCert's customers, are not going to disable updates on their web browser or their OS to "take a stand" against this decision. (And corporate users can't do this anyways, since it's not in their hands, and keeping things out of date is not a reasonable option for an organization that has security standards.) Most of them won't know what is going on here, and if they hear about it, probably won't care or know what to do about it. That's the Web PKI infrastructure working as intended, because it would be infeasible for billions of people to properly understand the gravity of all of these decisions. In order to ensure that TLS connections are at least minimally safe, it's pretty much necessary for things to work this way.
I'm not arguing that it's good that a relatively small number of entities (mainly Google, Microsoft and Mozilla) decide which CAs are trustworthy, but that's all the more reason that it's important for all of this Web PKI work to happen completely in the open, so that the few who can spare the time and effort to scrutinize what is going on can help the rest of us have a safer Internet. We don't have a better solution. That's also why DigiCert issuing legal threats because they don't like how one of these issue reports makes them look is a serious problem that can't be tolerated.
LegionMammal978
> The normal people, who account for 99% of the end users of DigiCert's customers, are not going to disable updates on their web browser or their OS to "take a stand" against this decision.
I'd imagine that they wouldn't do it to "take a stand" so much as "avoid the risk of getting their stuff broken in the short term" in this scenario, regardless of whichever party loses the blame game. See: the recent WordPress drama, which has turned customers away from both parties involved.
userbinator
The normal people, who account for 99% of the end users of DigiCert's customers, are not going to disable updates on their web browser or their OS to "take a stand" against this decision.
...unless they notice the breakage, and you tell them to do so to stop it.
cortesoft
> mainly Google, Microsoft and Mozilla
They don't have free rein to do whatever they want. If they chose to remove them, they are going to have to be ready to defend themselves in court.
woodruffw
> All it will do is increase the lack of trust in centralised PKI in general.
“In general” is a broad statement, given that the overwhelming majority of people using the Web PKI have no idea that they’re doing so. DigiCert is not a legible part of the value chain for the average users; they won’t notice that the sites they use switch CAs. This strong disfavoritism towards vendors is arguably one of the Web PKI’s greatest strengths.
edelbitter
Many systems do not fetch updates from the Mozilla root store, but from their (possibly Debian-derived) stable distribution of it. Meaning two highly respected entities, known for being well aware of the wider impact of their careful enforcement of strict policies, need to agree to cause any major breakage. When that happens, I can blindly trust they did the thing needed to keep the unaffected parts of that weird system working as intended.. and then still head to bugzilla and read about the background - to laugh at whoever triggered the mess.
SkiFire13
> Meaning two highly respected entities, known for being well aware of the wider impact of their careful enforcement of strict policies, need to agree to cause any major breakage.
Note that this is not a "both" but a "any of them". One can disagree with the other on this and still cause wide breakage.
pilif
If DigiCert were to lose browser trust (at this point, that's still a big if), it would happen the same way it happened with prior CAs, some of which were pretty big themselves (Symantec): all certificates issued after some date would not be trusted, yes. But all existing certificates would remain valid.
This gives certificate owners ample time to look for a different issuer and no certificate buyer would deliberately purchase a certificate from an issuer when they know some percentage of users will not trust that cert.
So for the end users, everything will keep working: the existing digicert certs stay valid and newly refreshed certs will be signed by a different authority. There is no need to turn off automatic updates over this.
Between Entrust and Symantec, we've already seen this happen to large well-known CAs and everything remained fine (not for the offenders, but, hey, that's the system working as intended)
null
DarkmSparks
From the bugzilla
"The actual reason for the underscore is so that services which allow users to create DNS records at subdomains (e.g. dynamic DNS services) can block users from registering subdomains starting with an underscore and be safe from unwanted certificate issuance. It serves the same purpose that /.well-known does for Agreed-Upon Change To Website, and that admin/administrator/webmaster/hostmaster/postmaster do for Constructed Email to Domain Contact. By using DNS records without underscores, DigiCert has violated a security-critical assumption that these services have made.
Therefore, this is truly a security-critical incident, "
That is a pretty brutal f' up of epic proportions... not sure any digicert cert should be trusted after that.
mtlynch
Direct link to the comment: https://bugzilla.mozilla.org/show_bug.cgi?id=1910322#c10
The author of that comment is Andrew Ayer, who also does great writeups about CA incidents and processes on his blog:
kevincox
My bigger concern is that what percentage of people will realize when delegating subdomains that having a leading underscore is a security vulnerability?
webprofusion
Always two sides to a story but the guy who caused the validation bug at DigiCert already resigned because of it (which is extreme), the Sectigo guy wanted to prevent the bug being closed so he could keep pushing them (in a subjectively prickly fashion) for more answers about their general responsiveness.
A bit of back and forth discourse is fine and expected, but if you keep pushing someone who has their own legal dept they're eventually going to wander over to the coffee machine and have a chat about it with them, then they're going to take a look and it becomes their problem.
So the number one rule would be don't even breath the word "legal" unless you want to invoke them. This particular response is just a letter telling them to back off and it's why you have a legal dept, so they can argue with each other. This one has just found it's way into the open.
There is a understandable perspective that says CAs shouldn't be burdened with legal risk in their discussions, but that's contrary to the fact these guys are commercial entities protecting their interests, so you don't get it both ways unless all your CAs are non-commercial, and even then that would only extend so far.
account42
Perhaps they should have also had a chat with their PR departement. And anyone responsible for company strategy. Becose the actions of the legal department just backfired.
willvarfar
You've given a detailed rundown like you've been following, so what is your sense about the resignation? Did the guy resign willingly, or is Digicert the kind of management that likely scapegoated him?
braiamp
He assumed personal responsibility rather than institutional. At the time, everyone in the community expressed alarm that that happened, because 1) and this is obvious, there's no way a single guy would be responsible for the entire fallout and 2) because it sets a bad precedent about what companies can do with their PoC wrt web PKI. It also meant a loss in institutional knowledge about how things worked.
smithcoin
Do you have any resources regarding the resignation I could read?
thayne
> It also meant a loss in institutional knowledge about how things worked.
And the experience earned from the mistake.
DeepPPP
He is still here. Far from a scapegoat. Wait and see. He will be back in no time.
128bitz
[dead]
DeepPPP
No he didn't truly resign. Retained as contractor and most likely waiting to be reinstated. You got misled.
infogulch
This is shocking to read. Even attempting to choke the legal speech of web PKI contributors with legalistic bullying is a gross inversion of the purpose and goals of the organization, and IMO warrants revoking everything to do with DigiCert on the spot.
terminalbraid
> IMO warrants revoking everything to do with DigiCert on the spot
This is pretty heavy handed and I don't think you've thought through what the consequences of that may look like. The historic way to deal with a problematic CA is to prevent them from issuing new certificates or renewing certificates (after taking care of immediate damage, of course). There are lots of legitimate companies that use Digicert and they should have an expectation of being able to continue business in the short term while they find a different certificate provider.
infogulch
I agree. "Revoking everything digicert" is a bit imprecise, "preventing digicert from issuing new certificates" is a more reasonable measure that actually only damages the parties that deserve it (digicert) and spares innocent bystanders (their customers).
DeepPPP
Are you saying it was okay to distrust EnTrust but DigiCert is too big to fail?
terminalbraid
No, and I'm deeply confused how you drew this conclusion from what was written.
I specifically say the historical way to deprecate a certificate authority is to prevent them from issuing new certificates. Since certificates have a finite lifetime, the certificate authority would as well and would have immediately no further revenue from certificates.
I am saying "pulling the plug" without notice is going to take down tens of thousands of bystanders and anyone using those certificates for business would be unable to conduct business securely online, which would be disastrous. For example amazon.com has a DigiCert-issued certificate.
xmodem
Looking at the original report ( https://bugzilla.mozilla.org/show_bug.cgi?id=1910322 ) I can see a couple of questions that DigiCert appears to be avoiding:
> The public record of Alegeus Technologies LLC v. DigiCert shows no attempt by DigiCert to contest the court’s order prior to the end of its preferred period of nearly 120 hours, even though such a motion could have freed DigiCert to revoke the certificates days earlier.
and
> The other question in comment 28 was for the language establishing DigiCert’s right to revoke Alegeus Technologies certificates. DigiCert has waffled on this point, first implying that this language was to be found on its website but later refusing to confirm that the language on the site applied to Alegeus Technologies at the time.
SPECULATION: Digicert may have offered special terms to Alegeus, and possibly other customers. They may have chosen not to dispute the TRO in court because they did not have grounds to do so under those agreements. They may also have included confidentiality terms in those contracts that prevented them from speaking about it.
OPINION: I am surprised that the forum allowed the issue to be closed without the above quoted questions being satisfied, though it is possible they are addressed elsewhere, I have not done a complete reading of all the linked issues.
EDIT to add: DigiCert has a response in a different thread here: https://bugzilla.mozilla.org/show_bug.cgi?id=1910805#c43 that would appear to contradict my speculation. Specifically
> Even though DigiCert’s TOU and MSA prohibited Alegeus from taking the action it did, once it filed for a TRO and the court almost immediately granted it, DigiCert’s hands were tied
thayne
> Even though DigiCert’s TOU and MSA prohibited Alegeus from taking the action it did, once it filed for a TRO and the court almost immediately granted it, DigiCert’s hands were tied
So did the judge just not read the TOU before signing the TRO?
I wonder if the CAB forum would have standing to sue Alegeus and/or that judge for interfering with the PKI process with an invalid TRO.
tbrownaw
So what's happened in the ... two months and a bit since the dates mentioned for the letters that this is apparently in reference to?
nneonneo
DigiCert posted a message fifteen days ago saying that "We have not used a legal team as a shield against accountability." (https://bugzilla.mozilla.org/show_bug.cgi?id=1910322#c74). This is clearly contradicted by their legal threat against Sectigo. Hence, Sectigo decided to post the "Threat of legal action" bug to make the community aware of what DigiCert actually did.
Maybe if DigiCert had not decided to make that comment, Sectigo would have been willing to stay quiet...
nickburns
Continued back-and-forth on Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1910322#c63
aaronmdjones
Certificate authorities have enormous trust placed upon them by every Internet user (whether they know it or not). Commensurate with this trust, they have enormous responsibilities. As the name implies, the Baseline Requirements are the minimum standard they should achieve. If they can't even do this (being unable or unwilling to revoke issued certificates within the required time-frame), then they do not deserve this trust, and it should be removed.
I understand that the TRO prevented them from revoking approximately 70 certificates, and there really is nothing they could have done differently in that case. Their other revocation failings are inexcusable.
ziddoap
Bug has been updated with a DigiCert response.
Obviously draw your own conclusions, but I actually laughed out loud at the following statement from DigiCert:
"In reality, our letter to you was consistent with our desire to promote open and honest dialogue."
Arnavion
Even taking the (one-sided) depiction of the conversations in DigiCert's letter at face value, maybe Sectigo's guy was being a git at best and intentionally trolling at worst. (I don't think he was, but let's play devil's advocate.) But even then, how did DigiCert think getting legal involved would possibly go well? Sectigo stands to gain publicity and lose nothing by going public with it to the CAB as they did here, and it's not like the CAB is going to play marriage counselor and get the two companies to make up because one of them got their feefees hurt.
Besides, this kind of hyper-polite passive-aggressive "erm akchually" conversation happens in every CAB incident discussion. I don't know why DigiCert got particularly upset about this one.
akerl_
> Besides, this kind of hyper-polite passive-aggressive "erm akchually" conversation happens in every CAB incident discussion.
As somebody who doesn't spend much time scrolling CAB reports, this was jarring to me.
Digicert's legal action seems nuts, and there seems like a real, risky issue in the idea that a company's customers can use the legal system to block the company from complying with its obligations to other entities, but it's hard to see any way that could be productively addressed given the back and forth in the thread. It's like I'm watching a theatrical production staring the most stereotypical corporate drones trading comments with the most stereotypical IRC nerds, both sides doing circles around an interesting topic but too busy trading blows to ever really get to it.
joshuaissac
> but it's hard to see any way that could be productively addressed given the back and forth in the thread
Another commenter mentioned in a sibling thread the possibility of using future-dated revocations. The CA could be mandated to publish such a revocation immediately, such that it takes effect by the 24-hour deadline. Once published, the revocations themselves should be irrevocable. This would also need to be accounted for in the CA's customer contracts.
akerl_
As the comment you linked to notes, that doesn't really fix the problem so much as it ensures that the CA's legal team gets to work nights and weekends for the next year.
The legal system is almost certainly going to view future-dating and immediately publishing revocations poorly in any civil action where a customer claims harm.
thayne
> but it's hard to see any way that could be productively addressed
It sounds to me there are things digicert could have done better, without violating the court order:
- they could have revoked all the other certs that weren't protected by the TRO. They did not.
- they could have contested the TRO sooner. But they didn't.
- Possibly, they could have given customers more warning, since they didn't notify customers until much of the 24 hours was gone
That said, IMO I don't what they did is necessarily irredeemable. But they need to come up with, and execute on, a plan to make sure something like this doesn't happen again. And threatening legal action is really not a good way to re-establish trust.
SpicyLemonZest
> there seems like a real, risky issue in the idea that a company's customers can use the legal system to block the company from complying with its obligations to other entities
As Digicert has repeatedly explained, this is simply how the United States legal system works. Courts have broad and indisputable power to issue temporary restraining orders, and the parties to a case must comply even if doing so violates some promise they made to a third party. (The point of the TRO is to maintain the status quo while the court figures out details like what promises have been made to who.) People in the PKI community who believe that some carefully written policy would enable CAs to reject an invalidation TRO, or convince a court that they cannot issue it, are wrong.
The reason it's never come up before is that no CA had previously attempted to enforce a widespread 24 hour revocation caused by its own error.
cjbprime
(I think Sectigo's argument is that Digicert did not even attempt to convince the court that it should be allowed to revoke those certificates in the mandated timeframe. If they had attempted and failed, I don't think they would be receiving criticism.)
akerl_
I don't think I disagree with you about what courts can do. And (as shown by all the back and forth in the CAB thread, and now here), it is risky: we currently have a situation where CAs can find themselves in a position where taking court-mandated actions (or lack of actions) puts them in jeopardy with the CAB, and violating court orders puts them in jeopardy with the government.
For all the back and forth in the CAB thread, it doesn't seem we're any closer to finding an escape valve for that, which seemingly would have to come from the CAB because there isn't even really a mechanism for courts to decide not to issue TROs about cert revocation, short of somehow taking a case around this to the Supreme Court (which isn't going to happen).
terom
It's fascinating that we've built a system that has expended perhaps several million dollars of engineering, legal and admin etc time over the issue of a single letter not being capitalized [1], without any demonstrable impact beyond a failure to meet ambiguous specifications.
I do hope that dealing with all of the underlying issues around revocation etc makes the time and effort spent useful, and the Web PKI doesn't just mire itself in squabbling that blocks progress on actually meaningful issues.
ajb
The bug that prompted this was more serious: https://bugzilla.mozilla.org/show_bug.cgi?id=1910322#c74
Basically the missing '_' was supposed to allow DNS providers who allow programmatic DNS record creation to filter out unauthorised certificate creation. So the certificates created without it could have been unauthorized by the owner of the domain they claim to certify.
xmodem
I think that the Van Halen Brown M&M anecdote is relevant here.
> and the Web PKI doesn't just mire itself in squabbling that blocks progress on actually meaningful issues.
In your view, are there any meaningful issues going un-addressed currently?
ocdtrekkie
Entrust got torpedoed basically for deploying an improvement to the requirements for its certificates slightly before the improvement got officially approved, and the browser people collectively lost their crud over the concept that Entrust didn't immediately revoke all of their... perfectly valid, secure certificates immediately.
Fundamentally, there is no accountability in the web PKI stewards. You want to talk about utter waste and incredible damage to the Internet, you can see it right here, in the people determining who is allowed to issue you sets of magic numbers that browsers have agreed are trustworthy, despite everyone involved behaving like complete children.
And of course, the browser operators all have their own root CAs, so basically have extremely motivated reasons to want to eliminate every commercial provider that isn't one of the monopoly companies.
Meanwhile:
- Compromised certificates are basically a non-issue from a threat model standpoint, every certificate error people hit are just... expired certificates people didn't rotate yet.
- Expired certificates cause issues for the majority of businesses at some point or another, making the internet increasingly fragile and unreliable.
drudgemetal
Entrust didn’t get nuked over a single incident, they were nuked because of a pattern of behavior that extended back several years. https://webpki.substack.com/p/entrust-considered-harmful-par...
null
In a nutshell:
DigiCert has delayed revocation beyond what's allowed in the Baseline Requirements a few times; most recently, https://bugzilla.mozilla.org/show_bug.cgi?id=1896053 and https://bugzilla.mozilla.org/show_bug.cgi?id=1910805. In the former case, it seems DigiCert chose to delay revocation to appease certain clients; in the latter case they were prohibited by a Temporary Restraining Order (TRO) from performing timely revocation.
Tim Callan from Sectigo has publicly lambasted DigiCert for these delays, since in both cases it seems DigiCert hasn't pushed back hard enough on its clients. In the latter case, there's concern that measures like TROs might be employed more often to stall revocation. Sectigo (and others in the WebPKI ecosystem) seem to want DigiCert to make the revocation policies very clear to clients and to ensure that clients can actually replace their certificates in a timely manner.
Sectigo is clearly the most vocal but they don't seem to be the only ones telling DigiCert to get their delayed revocation under control. So the escalation to legal threats is really uncalled for, and DigiCert could face some very significant pushback for trying this tactic.