In a concerning development, yet another Certificate Authority (CA) has issued what is likely a man-in-the-middle (MITM) certificate—something strictly prohibited by all root programs. This particular case is unique because the CA is trusted only by Microsoft, making the situation both frustratingly familiar and uniquely problematic. Details are emerging in this Bugzilla thread.
A Familiar Pattern
Back in 2011, I wrote about Microsoft’s trust in government-run CAs and the inherent risks (read here). More than a decade later, it’s clear little has changed. Browser distrust events happen with disappointing regularity—roughly every 1.25 years, according to my analysis (source). While MITM certificate issuance is far rarer, it’s far more serious, and a disturbing trend is evident: Many of the CAs responsible are government-run or affiliated.
Why This Matters to You
For Windows users, this is particularly relevant. Windows browsers like Edge (and others) rely on the Microsoft Root Program, which has unfortunately historically been overly permissive and slow to respond to incidents. You can learn more about the program and its requirements here. In the recent past, I can’t recall a CA responsible for willfully issuing an MITM certificate surviving, but the the timeline for Microsoft’s response is unclear. That said, when Microsoft does act, their AutoRoot Update feature—which I was the product manager for in the early 2000s—allows them to respond swiftly.
In the meantime, you can protect yourself by identifying and distrusting the offending certificate. Enterprises, in particular, can take a proactive stance by using the Microsoft distrust store. Through group policy, IT administrators can preemptively distrust the problematic CA across their organization, mitigating the risk before Microsoft formally acts.
The Lack of Technical Controls
It’s worth noting there are no technical controls that inherently prevent CAs from issuing MiTM certificates (though some browsers do have technical controls for some classes of misissuance). Instead, the WebPKI ecosystem relies on Certificate Transparency (CT) logs and a dedicated community of people closely monitoring CA issuance for violations of requirements. In a way, this incident serves as a smoke test for the system—but when it comes to these MITM certificates, it’s an awfully expensive test, with significant risks both for users of the web and reputational risks for the root programs, as well as questions about the trustworthiness of the WebPKI in general.
Predictable Chaos
If you’re following this story, keep an eye on the Bugzilla thread. Based on past experience, I’d wager the CA in question will bungle its incident response. MITM certificate issuance often reflects systemic issues, and such organizations typically don’t have the maturity to handle these crises well.
If this topic interests you, here’s some further reading:
- Problem report handling times for CAs
- Why WebPKI CAs exist
- Why we trust them
- Certificate Transparency
For a deeper dive, here’s a class I run on the topic of WebPKI incident response and how they’re (mis)handled.
Lessons Unlearned
While it’s comforting to know mechanisms like Certificate Transparency exist to catch these incidents, the recurring nature of these failures raises the question: Are we doing enough to hold CAs accountable?
Trust in the web depends on the reliability of its foundational systems. It’s time we demand higher standards from the organizations entrusted with securing our online world. Until then, stay informed, protect yourself, and let’s hope the next CA at least manages to pass the “Turing Test.”
Too many who take issue with CAs, turn a blind eye to the browsers. Like there is supposed to be implicit trust in them … when their profit model is cataloging customer browseing habits and selling directed, targeted and advertising tracking to anyone with a wallet.
I get where you’re coming from, but its one sided and, dare I say, adversarial, in tone and meaning.
You, of all people, who have worked in the CA space should understand that.
Running a CA is hard, costly work. Building a browser is simple in comparison. Everyone points fingers at CA, but never the browsers.
I openly wonder if you learned nothing from your CA days.
Thank you for your perspective. While I appreciate your acknowledgment of the challenges faced by CAs, as I do, I noticed your response didn’t address the equally critical challenges of root programs—the roles they serve and why they exist. Without root programs, there is no WebPKI. Both parties must fulfill their respective responsibilities, or the system fails.
Your framing suggests you believe I don’t criticize root programs enough for their handling of issues. I encourage you to review my last two posts (https://unmitigatedrisk.com/?p=911 and https://unmitigatedrisk.com/?p=923), where I specifically talk about exactly that.
To be clear, incidents like the one you commented on highlight not just the shortcomings of the CA but also raise questions about the root program’s governance and oversight mechanisms. Both CAs and root programs bear significant responsibilities, and failures on either side can undermine trust.
That said, there’s a spectrum of failures, and CAs that flagrantly ignore the rules and fail to produce a reasonable response or mitigation plan when they mess up really don’t belong in the WebPKI. Unfortunately, that describes far too many of the CAs in the ecosystem today.
As for the claim that “building a browser is simple in comparison” this doesn’t align with reality. For instance, the first version of Chrome was developed by about 20 engineers over the course of a year, but today the team maintaining Chrome is significantly larger—closer to 1,000 engineers than 20. Microsoft, acknowledging the immense effort required, ultimately adopted Chromium instead of maintaining their own browser engine.
In contrast, running a Web PKI CA effectively can be accomplished with a small team of fewer than 15 people. Building a CA to the point where it’s ready for root inclusion typically takes less than a year if the organization is not burdened by a large bureaucracy. While operating a CA involves ongoing responsibilities, the scale and complexity are far smaller compared to what it takes to build and maintain a modern browser.
As someone who has worked on both (contributing to Internet Explorer 3 and 4, collaborating with the Chrome team, and working closely with several WebPKI CAs), I can confidently say the resources and scale required to build a browser far exceed those needed to establish and operate a CA. The comparison doesn’t hold up under scrutiny.
If running a CA takes “a small team of fewer than 15 people” you’re highlighting ISRG. We were both there during their inception. That team did and does great work issuing leaf certs. But cutting publicly trusted Root and Issuing CAs has a tremondoulsy large overhead in resources and Capex and audits. Something ISRG doesn’t have to deal with … leaf certs and all.
True, I have no visibility in a browser team, but their overall lack of transparency is concerning, with exception to Mozilla. Apple, Google, Microsoft are black holes. The community at large has no idea of their decision making or bureaucracy except they unilaterally make decisions outside of CAB/F.
Respectfully, I do believe the comparison does hold up to scrutiny.
Around the same time ISRG was creating their leaf CA, I was standing up another CA in the WebPKI that created four new roots, bought a fifth root from another CA, and stood up intermediate CAs for all five. We did the full gamut of WebTrust audits, including ones we never ended up using like EV Code Signing.
You are correct there are real upfront capital costs to standing up a CA, and the audits are ongoing yearly cost, but it can easily be done with less than 10 people.
I have directly built and managed a number of CAs and worked closely with others, like Let’s Encrypt, as you point out, from its root creation onward. Those team size numbers align with many of the WebPKI CA projects I’ve worked on, again including roots, not just Let’s Encrypt. The largest team I needed was at Google, but that was largely due to the organization’s bureaucracy—for example, strict ratios of on-call personnel required to meet certain service level agreements, an inability to define roles outside of Google’s rigid hierarchy, and the general overhead of operating within a large company.
I suspect the difference in our perspectives comes from how many legacy CAs were designed decades ago around practices that don’t scale and are heavily manual. These same CAs are often drop ding in unresolved technical debt, facades into of facades and duplicate systems glued together. Modern CAs, on the other hand, are engineered with automation, scalability, simplicity of support and minimal maintenance overhead in mind—not just for issuance and inclusion, but for the full lifecycle of the service. This includes automating processes like revoking and replacing all certificates with minimal staff in under 24 hours, dynamically scaling up or down based on demand, elements of CA key and CRL generation, and updating infrastructure automatically to ensure continuous compliance and security. These things significantly reduce operational burdens and the need for large teams.
Of course, these numbers exclude roles like sales, business development, and vetting staff. While these functions may be necessary for a business, they are outside the scope of the core WebPKI infrastructure needs, which exists to deliver secure internet plumbing not revenue. These obligations stem from way the CA has chosen funds its operations, not the and not requirements of the WebPKI itself, so it seems reasonable to leave them out of scope for this discussion.
Another significant factor is the culture of the CA. When engineering neglect is part of the culture, the solution is often to add more staff to compensate for inefficiencies. To my earlier point, you can run a root CA and operations with 15 people or fewer if you design the system that way. However, if you rely on older practices, fail to prioritize automation, or neglect capabilities like dynamic scaling and automated updates, you may require a much larger team. That’s a choice—not a necessity—as demonstrated by the largest and most modern CAs that operate efficiently with small, focused teams.
As for the transparency claims, browsers report their intentions for changes—often years in advance—three times a year at face-to-face CA/Browser Forum meetings. They also participate in public calls and mailing lists, which are only public because browsers have pushed for that transparency. The only reason private lists exist is that some CAs have stated they cannot participate if the lists are public, leading to the creation of two sets of lists.
It is true that some browsers, such as Microsoft and Apple, are far less transparent than Chrome and Mozilla. However, as a whole, the transparency that exists in the WebPKI CA ecosystem is primarily due to the efforts of browsers and root programs—not CAs. That is an objective fact.
For those that are interested in the kind of techniques that give you small teams for at scale services check out : https://sre.google/sre-book/table-of-contents/