How does my operating system (Linux) make a Security Certificate invalid?

Question

I'm able to access the site https://ce.uci.edu on non-Linux machines (including my phone) without a problem. But when I browse to it on my Linux computer, in either Chrome or Firefox, I get an error "NET::ERR_CERT_AUTHORITY_INVALID".

Why is my operating system causing this when others aren't? Isn't security certificate validation supposed to be independent of OS?

It makes for an awkward conversation with the IT department because they don't see a problem.

Answer 1

The server isn't sending the "intermediate" certificate (aka the "chain"), so the client simply doesn't have enough information to verify.

Your desktop browser and/or your OS papers over this problem by caching all intermediate certificates it sees. When you visit this site, the browser uses its cache to complete the chain. Mobile browsers and non-browser apps generally don't do that.

It makes for an awkward conversation with the IT department because they don't see a problem.

They don't know how to check properly, beyond just opening the website in a browser. ("If it opens, it works.")

Try giving them e.g. the scan results from https://www.ssllabs.com/ssltest/ which is a widely used website which tries to detect exactly this kind of misconfiguration among others.

Isn't security certificate validation supposed to be independent of OS?

The process itself – yes (mostly; it can get complicated).

(Let's ignore trivial issues like bugs or mismatching clocks.)

"Trusted" root CA lists

The first difference is that many browsers don't use their own lists of "trusted" certificate issuers – they delegate that part to the OS, and each OS might have a different list. Microsoft and Apple certainly have their own trusted issuer programs for their OSes, while most Linux distributions use Mozilla's list. (I believe Google also has its own specifically for Android, but not for desktop Chrome.)

• For example, IE and Edge/UWP always use the Windows 'SChannel' TLS stack including its certificate verification and root CA list.
• Chrome also calls into the Windows TLS certificate functions (and therefore uses Windows CA list) despite using its own 'BoringTLS' library for the rest. However, it applies custom policies on top of basic CA check, e.g. rejecting certain signature types based on issuance date.
• Firefox has the Mozilla CA list built in and does everything internally in its 'NSS' library. Again, it can add policy restrictions beyond standard verification.
  • But on Windows, Firefox can optionally load admin-installed root CAs from the OS list in addition to the built-in list. (Importantly, even if this feature is manually enabled, it still doesn't load the default CAs.)
  • Similarly on Linux, some Linux distributions patch NSS (and thus Firefox) to always use the system-wide CA list instead of the internal list. This does load the default system CAs.
• Most non-browser apps on Windows use SChannel, but some use OpenSSL. It is relatively difficult to make OpenSSL defer to Windows TLS verification the way Chrome does, so those apps frequently bundle their own CA set (a file named curl-ca-bundle.crt, which is a copy of Mozilla's list) and sometimes that file becomes rather outdated.
• Then there's Java...

Caching

There's also the issue of "intermediate caching". Commercial web certificates are always issued using at least a 2-tier system: the root CA is guarded offline and only ever issues "intermediate" certificates, and only those certificates are online and allowed to issue the server certs. To pass verification, the client needs to know the whole "chain".

Usually the client only has the root CAs, and the server sends the intermediate certificates. But sometimes the sysadmin misconfigures the server (or it is impossible to configure correctly) such that the intermediates aren't sent, and the verification chain is broken. For example, your site uses a certificate issued by "InCommon RSA Server CA", which is one level down below a root CA. But it doesn't send the InCommon certificate itself, so it is impossible to match it against the "trusted root CA" list.

To cope with such mistakes, some browsers – and some OSes – build up a cache of previously seen intermediate CAs. (Windows caches those which it had to download on its own; Firefox caches every single intermediate it has seen.) That means if you're visiting a misconfigured website, success/failure can now vary from user to user, as they all have different caches built up.

This becomes especially harmful when the sysadmin's automatic response is "It works fine on my system", because they might have unknowingly made it work on their system only.

Chain building

Sometimes it is possible for multiple chains to be valid for the same certificate, due to "cross-signatures" having been made. For example, Let's Encrypt certificates can be rooted at IdenTrust's "DST Root CA X3" or they can be rooted at their own shiny-new "ISRG Root X1", depending on what the client has, and depending on what intermediates the server sends (it could send more than one).

Some US mil/gov websites use their own Federal PKI certificates, instead of ones from a commercial CA. Windows is the only OS that comes with a "trusted" root CA for this, other browsers won't accept it unless you manually install some root CAs. And depending on which root CAs you install, the same website could have many possible trust paths, sometimes up to 6–7 certificates in the chain.

Different browsers – especially those which offload verification to the OS – might come up with different possible chains in that situation – for example, Windows is very flexible, while OpenSSL used to be very lacking before 1.1.x, and Firefox went through three rewrites of its chaining-building code. (The currently-used library, mozilla::pkix, was in the beginning called "insanity::pkix" and that should give you a hint as to how unnecessarily complex it can be.)

authorityInformationAccess

I mentioned Windows is able to download those missing intermediates by itself – although technically a standard feature, some browsers completely refuse to implement it due to privacy concerns, and others don't bother with it due to additional unnecessary complexity. That makes for yet another difference between Windows and Linux.

(Again, this feature is heavily used in US "federal PKI" where cross-signatures are widespread and the system begins to look more like a mesh than a rooted hierarchy. For example, organization A might recognize the chain A→B→C→D, another might recognize B→A→C→D or B→C→D with exactly the same server certificate D.)