The way the web works, any CA (Certificate Authority) can create TLS certificates for almost any website.

This means that the people with these keys could MITM almost any https connection people make, not only the ones that this CA issued.

▲

arcfour 4 hours ago | parent | next [-]

It doesn't have to, you can set X509 name constraints which say "the CA may only issue/may not issue certificates for these Subjects," or you can set CAA in DNS, for example.

(Of course, the former isn't really intended to constrain trusted Root CAs, moreso internal PKIs. But it is an option people should know about!)

▲

eqvinox 4 hours ago | parent [-]

To my knowledge, name constraints are very rare in actual use, and a bunch of implementations don't even support them. Am I wrong?

▲

arcfour 3 hours ago | parent [-]

Rare in public PKIs, yes; not so much in private ones, I would imagine.

From my limited experience (using them at home) they seem to be fairly well supported in client libraries, actually!

- OpenSSL has full support, https://docs.openssl.org/master/man5/x509v3_config/

- GnuTLS has full support, https://www.gnutls.org/manual/html_node/X509-certificate-API...

- go (crypto/x509) supports everything except DirectoryName constraints, https://pkg.go.dev/crypto/x509#Certificate.Verify

- Python (pyca/cryptography) has full support, https://cryptography.io/en/stable/x509/reference/#cryptograp...

- Windows/Schannel has full support, https://learn.microsoft.com/en-us/windows/win32/seccertenrol...

- Java has full support, https://docs.oracle.com/en/java/javase/21/docs/api/java.base...

- I know that NSS also supports them from experience but (sorry!) couldn't find the docs in a few seconds of searching

- I know that Strongswan supports them well because I actually opened an issue about it a few years back and got it fixed :-)

(Just a few off the top of my head)

	▲	eqvinox 3 hours ago \| parent [-]
		Wow, Thanks for digging up/working out that support list! Actually a glint of hope. …but, yeah, the issue is on layer 9. Even just nailing sub-CAs to ccTLDs breaks the moment a marketing person registers a .lol domain. Then again, the CA/B is essentially a layer 9 entity. I just refuse to believe this is an unsolvable problem (though it might need NCv2 with a whole bunch more shit to cover more human creativity in policymaking.)

▲

sandeepkd 3 hours ago | parent | prev | next [-]

Yes and NO. These are intermediate CA's and for them to be recognized by your browser or system, they need to be signed by another CA or root certificate that your system already trusts.

SO, not all CA's are signed by root certificates already on your machine

▲

UltraSane 5 hours ago | parent | prev [-]

"any CA (Certificate Authority) can create TLS certificates for almost any website."

This has always been incredibly stupid.

▲

bombcar 4 hours ago | parent | next [-]

You can pin, but almost nobody does (and half the world that does pin is probably pinned to Let's Encrypt).

Those who manage the root domains should have been able to pin who they trust, and then if you WANTED to you could add someone beyond what .com or .egg or .muffin lists.

▲

ipdashc 4 hours ago | parent [-]

> and half the world that does pin is probably pinned to Let's Encrypt

To be fair, unless I'm misunderstanding, wouldn't this be a good move?

LE has a good security record and takes itself seriously, versus these smaller CAs that seem to mess up regularly.

	▲	bombcar an hour ago \| parent [-]
		All your eggs end up in one basket usually because it's a really good basket. All things turn and curve and degrade; Google used to be the "it's perfect" darling.

▲

binlog 5 hours ago | parent | prev [-]

Why? How do you pin a website to a specific cert provider? And what happens when you want to switch?

	▲	toast0 an hour ago \| parent \| next [-]
		You can pin in software you distribute. If you're big enough (top 100 websites mostly), you can ask browsers to pin certs and they may included it in their preloads. > And what happens when you want to switch? You have to update your pins and then wait long enough that you don't mind losing users who never update their software. When it's just in software you distribute, you can change hostnames in new versions and use the new CA for new versions and the old CA for old versions... For web browsers, there's not a reasonable way to make a nicer transition. You have to serve old certs for old pins, and TLS handshakes from browsers don't include enough information to know if the client has an old pin or a new pin; or at least, mostly they don't --- if you get your pins changed and the browser TLS stack changes so the handshake changes after that, maybe you can use that... when sha1 certs were phased out, it was somewhat popular on high volume sites to look at the TLS Client Hello to decide to serve a sha256 cert or a sha1 cert. DNS CAA only pins issuance, not acceptance; clients can not check if the CA that issued a cert was listed in DNS CAA at the time of issuance, and they do not check if it's listed at time of presentation. I'm pretty sure issuing a cert contrary to a CAA record is a mississuance and would result in sanctions from the CA/Browser forum, but clients would still accept the cert until it's revoked.
	▲	bombcar 4 hours ago \| parent \| prev \| next [-]
		https://kagi.com/search?q=dns+CAA CAA is one way, but you can also pin the actual certificate or certificate chain (which has its downsides, mind you).
	▲	4 hours ago \| parent \| prev \| next [-]
		[deleted]
	▲	UltraSane 4 hours ago \| parent \| prev [-]
		Because it makes you only as secure as the the LEAST secure CA. Such as the really bad ones that don't use Hardware Security Modules.