Cert pinning is an anti-pattern. No need for the CA infrastructure if you're going to bypass the CA infrastructure. If you control the software on both sides, which is required for cert pinning, then you can use self-issued certs. Also: roll your certs frequently.<p>Shameless plug for <a href="https://smallstep.com/cli" rel="nofollow">https://smallstep.com/cli</a> which makes the process of issuing and rolling certs (incl. client certs for mutual TLS) easy enough to be workable in a modern application.
>It must be emphasised that if any single CA is breached, then all of TLS breaks. It doesn’t matter what CA you used for your website, it only matters what CA your attacker uses.<p>How is that possible? If a CA is breached, doesn't that just mean it can create certs impersonating other sites? How does that break all of TLS?
Years ago I read a blog that taught the series of steps needed to perform GNUTLS certificate pinning for Emacs use. At the time, it seemed like a convenient way to boost security. After all, services were only renewing their certificates every 2–3 years, so once you set up your configuration, you wouldn't have to change it for a long time.<p>But then Lets Encrypt came along and was widely adopted. LE thinks that it is best that certificates expire after only a few weeks. So, if you have pinned a lot of certificates, you start to feel that it is too much work to manage that configuration, you constantly have to update it.