69 ms·

> Doesn't pick up the operating system PKI trust store. This was super frustrating for me. I filed a related bug when loading the CACKey module stopped working

• jiggawatts 4y ago
  They never actually fixed the bug. Notice the word "roots" in "security.enterprise_roots.enabled"? The PKI hierarchy is more than just "roots". A tree is more than just a stump.[1] No amount of begging or pleading with the Mozilla dev team ever succeeded in convincing them to read the Microsoft documentation for how PKI works in Windows. There's a set of constants in the Win32 headers that defines the various certificate trust stores in Windows. You know, "machine", "machine policy", "user", and "user policy" multiplied out to make combinations with "root", "intermediate", "crl", etc... Over 20 years they have slowly, one at a time added a random subset of them. RANDOM. Just... one... at... a time... in some unfathomable order. It was mind-blowing to watch this unfold. The simplest thing they could have done was simply support all of the stores by copy-pasting the whole block of constants and writing a for loop across all of them. Done. Fixed. Close ticket. But noooo... got to keep those tickets open for decades and decades by making sure that whatever is there remains permanently incomplete. It boggles the mind. [1] As a random example of how this can be broken in Firefox is that it is unable to use LDAP to load an intermediate CA certificate. The use of LDAP is common on large Windows-based enterprise networks, because it's the default. It's trivial to "push" these intermediate CA certs into the local trust store of every machine using policy, at which point the protocol support no longer matters. Firefox could have simply picked up the certificate from the local store. It already has the code for doing this for Root certs, but refuses to use identical code for Intermediate certs.
  • torstenvl 4y ago
    I'm a PKI user not a PKI programmer. Please forgive the ignorant question I'm about to ask. How can you have an intermediate certificate in a trust store mean anything? Wouldn't its trust be based on the root that signed it? It seems to me either the intermediate cert is signed by a trusted root (in which case mission accomplished) or it isn't, in which case it's the root (not intermediate) that needs to get added? Again, not anywhere near my area of expertise. Assuming my understanding is wrong, it would be helpful for me to learn how, and id appreciate the guidance.
    • jiggawatts 4y ago
      It's not (just) about trust, it's mostly about how the CA certificate is "obtained". Firefox supports only HTTP for retrieving an intermediate CA certificate, and can only do this "live". Say you have a "leaf" certificate, and you already trust its Root CA, but there is no copy locally of the intermediate CA certificate. What now? Firefox will look for a HTTP URL in the leaf certificate pointing at the intermediate CA's certificate endpoint. It'll download and cache it on the fly. This is fine... on the public internet with public CAs. It's not generally robust on internal networks. For example, many "secure desktops" deployed in the military, security agencies, parliament, etc... don't have unfettered outbound access. They may need to talk to internal HTTPS endpoints but have no access to Internet-hosted CA endpoints publishing the intermediate certificate! Windows solves this by allowing a single machine to download the CA certificates and the associated CRL files, and pushing this out to the workstations via policy. Firefox solves this by timing out and failing. Similarly, HTTPS is the new-kid-on-the-block for PKI infrastructure! Its original use-case was for things like Smart Cards. Windows started out deploying certificates via LDAP, not HTTP! Firefox just does... nothing... if it sees only an LDAP URL in the certificate and you get an error. Last but not least, truly paranoid admins don't just trust every public CA for every purpose. It's possible for a Windows network to deploy updated trust lists that restrict CA purposes. Similarly, it's possible to push out certificates you distrust and have anything using them rejected, whether or not the parent CA has published a CRL entry to revoke the certificate. Right now, there's a lot of admins in Ukraine adding Russian CAs to such rejection lists. Get it? Firefox has it's own unique and special way of managing all of this, and just ignores whatever the operating system tells it... except for a random subset here and there. That's not documented. You have to go read (and understand!) the C++ code to figure out what it does or does not do. Oh, and to add injury to insult, the method for managing the Firefox certificate trust list changes semi-regularly, so most of the URLs in the docs are now 404s. I've given up, and so have millions of other admins. Firefox had a philosophical opposition to supporting enterprise customers on Windows, and they've paid the price for that philosophy with increasing irrelevance of their core product. PS: Chrome / Chromium / Edge have their own issues, but nowhere near as bad. One major concern is that for non-public CAs used at a large scale, it's basically impossible to revoke certificates for any Chromium-based browser on unmanaged networks. It's still very difficult on managed networks. An example would be a University with tens of thousands of unmanaged workstations using an internal CA for things like VPN or WiFi access.