I totally agree: pinning to a single CA is super-fragile and a terrible idea, and if you don't have a need for public certs, doing a proper private PKI (Small-s

I totally agree: pinning to a single CA is super-fragile and a terrible idea, and if you don't have a need for public certs, doing a proper private PKI (Small-step is a good choice here!) is a good place to go as long as you can run it properly. However, whether you're running your own or pulling public certs, you should go into any PKI setup assuming you'll need to change out all the certs at some point. If you're going private, make sure you have a mechanism to replace everything--yes, including that private root you just created!--in a safe and secure fashion. Preferably, that would include some manner of doing so that doesn't involve blowing everything up and leaving existing clients high and dry...but that's a business decision to make. If you're going with public certs, you still have to make that assumption. I see too many developers still pinning trust to a single root CA like Let's Encrypt or GoDaddy and then being stuck when the CA in question is revoked, replaced, expires, or is booted out of public trust, or just because their business insists they use something different. The solution to this is a trust store, which you can make as minimal as you want to: pick two or three public root CAs, stick them in a blob, and tell your app to accept nothing else. That leaves you an out, for the next time the cert industry has a Symantec-like event and everyone has to get off that train right away, since you can move from one of those to another one without having to change anything in the app.