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.
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.
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.