What's "pinned" isn't the site's certificate, but rather the CA's certificate. Or more accurately, the CA's public key.

This is the problem with public key pinning. The site is still vulnerable to a compromise from its own CA, and many sites actually use a number of different CAs for unfortunate reasons. If you check out the list of pins for twitter.com, it's quite large. Still, at least it's not vulnerable to compromise from every CA that exists.

Trevor Perrin and I have been working on something called TACK (http://tack.io) to make all of this easier and more secure. Rather than embedding pin fingerprints into the binaries of web browsers and mobile apps, you can advertise them and update them via a TLS extension. What's pinned is also your site's certificate, not the CA's certificate, making the site additionally immune to compromise from its CA (or list of CAs, as it were).

Just a quick note that there are apps that pin site certs and not just CA certs; if you're implementing your own iOS app, for instance, you can do it either way depending on your margin of error w/r/t certificate revocation and expiration and software update.

In that case, I would generally recommend that you create your own trust root and validate against it, rather than using pinning?

That makes sense if yours is the only client that connects to your endpoint, but less sense if your client shares an endpoint with, say, a web app.

I try and I try to get clients to consider just rolling their own root certificate and eschewing the TLS PKI, but people have an irrational fear of the process of making certificates.

Yes and that's kind of the point.

It's like Firmware in VoIP, although VoIP implementations leave something to be desired. In essence they're doing something similar to a checksum on the certificate such that any change to the certificate causes the transaction to fail.

You would have to hard code the new dates in.