>especially around legacy platforms that may have been hardcoded to use certificates from a specific issuer (not that I have ever seen that before, no one would be that foolish right? :/)
D'ya know, I would have naively assumed this wasn't technically possible. I shudder not only to think of the code, but also of the thought process that could compel someone to undergo the effort of bricking themselves into this corner because honestly, that sounds a lot harder than doing it right.
It happened to me - I was working on an application for the pre-paid electricty system in Texas: the server-side code connects to a data-source over a TLS connection (complete with client-side certificates too), except the server-side used a self-signed certificate, and my code didn't have admin/root rights on the client hardware so it had to use in-app certification verification code. I had to hard-code the root CA's fingerprints directly into my code so it would be baked into the signed binary (this was a project requirement). That thing is going to fall-apart if the root CA ever changes - fortunately it won't expire until 2099.
(Yes, I gave the client a strongly worded statement of my misgivings - and all the other bad code-smells in the project)
Pinning is a good thing, assuming you have built in a reliable upgrade path (oh hey, browsers update themselves automagically now so yay!) but when you have occasionally connected devices that have low bandwidth that have a long deploy lifecycle, it's not always feasible, or even a good idea.
It's even worse if said device is embedded and has severe hardware constraints for compliance and regulatory reasons, and those same reasons prevent you from deploying patches on the regular.
Layer in some "built by the lowest bidder" and "accumulation of 30-odd years of poor practices for smart payment cards" and you have a big mess of a situation to unravel.
Oh yeah, and lest you think this is not an issue because this is browser related, may I introduce you to the world of services that proxy legacy green terminal applications into web front ends, ranging from IBM HATS to bespoke AJAXy things that unwrap screen scraped terminal emultor content from XMLHttpRequests.
Jeez. Remembering why I used to drink more when I worked in fintech :)
Except that that likely ended up baked into a system that is hard or impossible to upgrade. So when the certificate is revoked or changed the system stops working.
This is essentially what HTTP Public Key Pinning (HPKP) does [0]. HPKP is a header your web server responds with that tells the client's browser, "Only trust my domain if the certificate presented is in a chain that goes up through one of these CA public keys". This is so an attacker can't go buy a certificate from a less-diligent CA and use that to MITM HTTPS traffic between clients and your domain.
You pick two or more CAs you trust, and brick yourself into a corner saying "these are the only CAs you should ever trust w.r.t. this domain".
Hardcoding certificates is actually way too easy. SSL libraries don't necessarily use the system ca store or even know about it. OpenSSL has the option of disabling certifcate validation, providing your own certificate list or pointing to some system-supplied certificates which you need to find first. So in a way you even have to count yourself lucky if the hardcoded one instead of choosing to just disabling validation.
It's pretty common in the embedded world where you don't have enough flash space-- or don't want to use what flash you have-- to hold a root CA store.
Such devices are usually great targets for learning how not to secure things, because when they care that little they often don't get anything else right either.
D'ya know, I would have naively assumed this wasn't technically possible. I shudder not only to think of the code, but also of the thought process that could compel someone to undergo the effort of bricking themselves into this corner because honestly, that sounds a lot harder than doing it right.