I don't think you'd typically pin intermediates if that was your goal: you'd pin the site cert you control. It could be as simple as a whitelist of certificate SHAs.
And you've got to be able to do that, in case your key is disclosed or possibly disclosed.
Pinning intermediates doesn't make a lot of sense; unless you have a deep relationship with the CA, they can and do change intermediates, and may not be able to issue from the old intermediate after the change. But, I've been involved in cert pinning where we had to pin intermediates, because that's the only viable information the client API returned we could use for pinning (and really, it was pinning based on the name of the intermediate --- any system trusted Root CA could have made an intermediate specifically to bypass our pinning, but it was the best we could do on that platform; of course, this was also the platform where we ended up with a wrong pin in our final build (platform owner shut down their app signing CA), which meant some ugly workarounds).
Pinning roots makes sense, but you need to pin more than one. And roots from more than one organization. And you need a succession plan. You can't use a new root on an existing hostname until all of the deployed clients with pins that could use that hostname have become irrelevant. If your all your trusted CAs stop issuing, you're pretty screwed.
You can sometimes use an in-house root, which makes continuity easier, but not if you need to share hostnames with browsers. You can't get an entity cert signed by two issuers, so there's no way to present a cert that is trusted by browsers and also signed by your root. You can present alternate paths for the issuers of your cert (and any intermediates) and if the x.509 libraries do the right thing, any valid path is accepted; but not all libraries do the right thing, and again, that doesn't apply to the entity cert.
Pinning is not an effective anti-reverse-engineer technique. It's just annoying obfuscation to anybody who knows what they're doing.
A pinned cert makes it easy to detect these MITMs and refuse to work if they're in place. A dedicated reverse engineer is "just" going to patch out the pin, and go on with their day, no big deal. But ISP MITM or corporate MITM or on device MITM is going to be stopped, and that's worthwhile.
If you're concerned about that and want to pin, why have a chain of trust at all? Couldn't you just embed self-signed certs in the binary at that point?
If you mean preventing users from clicking through the SSL warnings in a browser if they're being MITM'd, that makes sense to me.
Not if you need to serve https traffic to clients and browsers from the same servers / same hostnames.
> If you mean preventing users from clicking through the SSL warnings in a browser if they're being MITM'd, that makes sense to me.
That comes from HSTS, not from cert pinning. Cert pinning in browsers is only available if you can convince the browser to include it in their static lists, which means you've got to be big... so that is what it is.
If you pin keys you can even pin a key you haven't and never plan to use, keeping the corresponding private key in the company safe as a hedge against something going badly wrong.
It's very easy to avoid the pitfall you mentioned by having multiple valid certs with different expiry dates. You can easily use multiple CAs.
Done your way, a single leaked private key means your entire site is compromised indefinitely. That's unacceptable to me.
As long as the private key is stored/handled safely and RSA/ECC is not broken, it is not vulnerable.
I do agree that key rotation is better/recommended practice.
> a single leaked private key means your entire site is compromised
The leak is the actual vulnerability. As long as the leak is still there and you are not aware of the compromised private key, a fresh new private key will probably leak again.
However, the chances of leaking may be greater if a private key has to be used in multiple locations.