[abcd_f]

No, no, no.

It has nothing to do with that. Cert pinning is used to mitigate man-in-the-middle attacks whereby an attacker somehow obtains a valid certificate for peer's ID further down the road. If the certificate is not pinned, then the client will swallow a new cert without a peep, because it tracks back to a trusted CA.

Cert pinning is an equivalent of ~/.ssh/known_hosts. It allows me to pin specific public key to a peer and be notified if that key ever changes.

In your case, you might've gone with self-signed peer certs, but that would've obviously require manual verification of the peer's key on 1st contact. This is a bit of UX issue, because few people would bother to actually verify a string of hex numbers between two computers. So, naturally, you introduce a chaperon entity - your CA - that vouches for peer's credentials. I am willing to trust it, but consider it a "weak" trust that I put in place only for convenience purposes and to get stuff going quickly. Later on I may look and compare the key hashes (one provided by peer in an out of band fashion and the other I compute from my own copy of the key) and if they match only then I will know that I have a truly secure connection with the peer and that you didn't lie in your initial peer introduction. At this point I want to pin peer's key, so to be notified to repeat the manual verification process if/when the key changes.

tl;dr - Just add the cert pinning and display cert's public key hashes (mine and peers) somewhere in the UI.

[rdl]

What would make just as much (or more) sense for most of their enterprise deployments would be to let the enterprise's own PKI take over. A lot of businesses would probably want to be able to silently update keys (although I can see the value in pinning/local cache with notification on change). They may do that as part of the "custom LDAP/AD" tier.