[tialaramex]

These are generally government CAs, so, typically the situation is Microsoft sold the government Windows, and as part of that deal (at least tacitly) agreed to the CA being trusted, and so every system that's trusting these certificates is a Windows PC anyway, running Edge because the whole point was the government will only use Windows and pays Microsoft $$$.

Why bake it into everybody else's Windows? If you make say a Brazil Government-only Windows which trusts this CA instead, I guarantee somebody crucial in Brazil will buy a 3rd party Windows laptop independently and it doesn't work with this CA's certificates and that ends up as Microsoft's problem to fix, so, easier to just have every Windows device trust the CA.

They'll have an assurance from the CA that it won't do this sort of crap, and that's enough, plausible deniability. Microsoft will say they take this "very seriously" and do nothing and it'll blow over. After all this stuff happened before and it'll happen again, and Windows will remain very popular.

[efitz]

Windows CA program is governed by requirements like any other CA. Microsoft has ways to provision machines with enterprise CA roots so there is no advantage, and highly visible disadvantage, to adding a noncompliant CA to your trust store. I think that the theory that Microsoft will included it to sweeten a sale has no merit, unless you have evidence.

Most certificate trust stores have some certs in them that are sketchy, eg a bunch of university certs from all over Europe. These are slowly dropping off, presumably because it costs quite a bit to operate a CA in a compliant fashion and get it professionally audited.

Issuing a fake cert is grounds for removal from every certificate trust program I’m aware of, if it can’t be demonstrated that they found what went wrong and have fixed it so it can never happen again.

[lokar]

IMO, issuing a fake CA for one of the top (and highest risk) domains even once should be the end of that CA (and any other CAs managed by that org)

[amluto]

The solution seems straightforward: limit the trust in the CA to .BR domains.

[domain name typo fixed]

[kelnos]

IIRC name constraints is very poorly supported by client software, so there are likely lots of clients out there that wouldn't even parse that restriction out of the cert, and happy accept anything singed by the CA.

[8organicbits]

I think support for name constraints is much better now, but I think someone needs to correctly audit it. We need near universal adoption for it to be considered a usable tool.

I researched the issue a little here: https://alexsci.com/blog/name-non-constraint/

[amluto]

I’m not talking about a name constraint — that would need to be part of the root certificate. I’m suggesting that MS add a feature to its root store to constrain the usage of the certificates in the store. IIRC Google’s root store has features like this.

[tsimionescu]

The Windows trust store doesn't offer a verification API, I believe it simply lists the trusted certificates so that they can be looked up by verification software. That is, OpenSSL doesn't ask windows "hey, is this certificate with this chain trusted for google.com?" it asks Windows "hey, do you have a cert in the trusted root CAs with this ID? If so give it to me", and then OpenSSL will use that root cert to check if this is the real google.com.

Chrome, which is both the cert store and the client on certain OSs, might implement this limited trust. But Windows can't, except maybe for its own internal services.

Either way, this makes little sense overall. If a CA is trustable, it can be trusted to sign a certificate for any domain. And if it's not trustable, then you can't trust it for any domain. Brazilian companies wishing to use a local CA can own .com domain names, so you'd be preventing a completely legitimate use case. Google almost certainly has a google.br domain, so if the Brazil CA is untrustworthy, they can still be used to attack Google even if you only trust them for .br domain.

[nordsieck]

> Either way, this makes little sense overall. If a CA is trustable, it can be trusted to sign a certificate for any domain. And if it's not trustable, then you can't trust it for any domain.

That's a silly position to take.

When I lived with roommates, I trusted them. But I also locked my bedroom when I went out. Because there's no good reason to rely on trust when you don't have to.

[tsimionescu]

It is given the design of the PKI and DNS. There's no relation between CA and the TLDs on the certificate being signed.

[cvalka]

As of 2024, they are well supported.

[bitwize]

.bz is the TLD for Belize. Brazil is .br.

[awinter-py]

what's the state's interest in having their CA built into windows?

[tptacek]

States are themselves extraordinarily large IT enterprises, they generally want control of traffic and its transparency or protection, and they are large enough to get arrangements for that, though usually not this particular arrangement.

Large enterprises in the US generally have the same capability, but not loaded into operating systems by default (that is: Walmart's ability to do this on its own network in no way impacts you, who have never worked on that network).

[adra]

If you're a large enterprise, then it's trivial to add yourself your own custom CA and save the cost/hassle of needing to deal with outside companies. The tradeoff being you need to manage it yourself vs basically paying this third party company to survive?

[tptacek]

That's true, but in the bad-old-days of the antidiluvian WebPKI it was somewhat routine to sell big companies CA=YES certs simply to allow them to do this universally without pushing out updates to all their endpoints. It was a terrible, bad practice, and so far as I know it's completely dead now --- except for Microsoft, I guess.

[hulitu]

> If you're a large enterprise, then it's trivial to add yourself your own custom CA

The big CA have their own "Boy club". See Ahmed used cars and certificates.

[mnau]

E.g. identity verification. My state has a "qualified" certificate that can be used to sign contracts and basically everything else you can do in-person. When you can transfer you home with that, there are higher requirements on checking the identity of a person who gets the certificate.

That CA is not used for much else and is basically confined to our state. But it has to be in Windows, otherwise no other software could verify the signatures.

See eIDAS and other similar schemes.

[tsimionescu]

Why would you want to mix identity verification with the WebPKI? This makes no sense at all. Just because a CA is trusted for web verification doesn't mean it's trusted for identity verification, machine enrollment, or any other purpose. And vice-versa: a CA for identity verification is not in any way trusted for web verification.

[Muromec]

I think the idea was to use client certs for strong authentication on the government web services, which didn't rally took off, except maybe in Estonia.

[Muromec]

You don't really need your CA doing eIDAS in the system root. This scheme works as a closed system where you need eIDAS app to produce the artifact and another eIDAS app to verify it, when both have their own non-system root.

Ukraine for example successfully operates their own eIDAS-like scheme where everything is based on DSTU+GOST algos not supported by any operating systems a major libraries, the certs are signed by the government root and it doesn't leak into web pki.

[estebarb]

It doesn't have to be. In Costa Rica the Central Bank has their own CA for the same purpose. We need to download the certificates ourselves. It is inconvenient, but an error by that CA won't propagate to the rest of the world.

[efitz]

Getting your CA into a trust store means that every machine using that trust store will accept your certs. It’s not really necessary for a government or corporation to have a public CA in anyone’s trust store unless they want to issue certificates that everyone trusts. If they just need their own machines to trust their certificates, they can use the management utilities that come with Windows and with AD to distribute an “enterprise root”, which only their machines will trust. This is how most large companies and governments do it.

[csomar]

So when they issue their certificates, you don't get that huge red banner? I belong to a small developing country and even with its tech illiteracy it has a CA. Now, of course, because that CA is not trusted by anyone, all government websites are red.

[tsimionescu]

So that they don't depend on anyone else to have proper TLS for their state sites and for companies operating in their state.

Imagine if you don't have a state CA, and your relationship with the USA goes sour, and the USA prohibits all of their major CAs from doing business with your country, including Let's Encrypt. People in your country still use the internet and you still want to protect them from scammers pretending to be local businesses online. So it's important that you as the state can provide CA services and sign those certificates yourself.

Of course, in this scenario you wouldn't want to be relying on Microsoft to help. But the general principle is that any state who can afford it has a strategic interest in having fully self-sufficient Internet infrastructure, including DNS, CAs, IP allocation etc.

[withinboredom]

This seems like a matter of signing a certificate signed by an actual CA with your own CA as well. If the relationship sours, you still have your own CA to vouch for it.

[tsimionescu]

That doesn't achieve anything at a country level if trust stores don't include your CA directly. A country can't just push an update to all its citizens' computers to switch CA, it has to plan ahead for such eventualitites.

[Onavo]

So they can mitm their own employees without annoying TLS warnings.

[throwaway2037]

To be clear, this is bog standard in all mega-corps now. They have a vendor product that provides HTTP Internet proxy, then they perform MitM to decrypt HTTPS traffic and re-sign/encrypt with in-house issued cert. Then, this cert is auto-trusted as part of all base OS installations. To be honest, how else can mega-corps spy on HTTPS traffic without this MitM tactic? I don't know any other way.

[echoangle]

Yes, but normally this is done by making your own CA and installing it into your client devices, not by getting it into every device globally by working with Microsoft.

[hulitu]

> Yes, but normally this is done by making your own CA and installing it into your client devices, not by getting it into every device globally by working with Microsoft.

Google, Facebook, Microsoft, Apple, Cloudfare, Godaddy, Lets encrypt. They all "work with Microsoft".

[echoangle]

Does any employer get a certificate from any of the CAs you listed to MITM their internal networks?

[tsimionescu]

You don't need a publicly trusted CA for that. You just run an internal CA and install its root certificate on your employees' machines, just like you install VPN software or whatever else.

[lazide]

Legitimate, or illegitimate?

[sneak]

Windows is less popular every year.

[saghm]

I feel confident in guessing that any net changes in Windows popularity have close to no relation to Microsoft's policies around trusted CA. The number of users who are worried about sketchy certificates being trusted by default are dwarfed by the number of users who don't have any idea what a "trusted CA" is but care about more "visible" things like UI changes, performance, and how hard Windows is pushing Edge and other things they don't want.

[l33t7332273]

It’s not becoming the users that are the decision makers. A few CTOs could make decisions based on this

[saghm]

If the rationale in the parent comment for this behavior is correct, it sounds like a lot of people making the decision to use Windows are doing it _because_ of behavior like this, not in spite of it.

[notimetorelax]

I looked at the graphs at Statista. I don’t think it’s so clear cut. Mobile OSs have pushed it down, but it seem to dominate PC market. Do you have a graph that shows its decline on computers, not mobile phones? Or in absolute unit counts?

[lysace]

https://gs.statcounter.com/os-market-share/desktop/worldwide...

There's a clear but slow trend on desktop.

Jan 2009: 95.4% Windows

Jan 2016: 85.2% Windows

Jan 2024: 73.0% Windows

In e.g. US it's going down faster, desktop market share now at 62%:

https://gs.statcounter.com/os-market-share/desktop/united-st...

[flir]

I think that might be a bit of an unfair caveat. People do real work on mobile OSes. They shop and communicate on mobile OSes, and occasionally organise revolutions.

(Although I'm not sure why "Netraft confirms, Windows is dying" is a useful comment here anyway. Windows is a behemoth.)

[n144q]

You need to show statistics to prove that, not just throw the statement out there, possibly only based on the vibes on HN.