Certificate pinning is introduced on cisco meeting server starting in CMS 3.0 to help prevent man in the middle attack.
CMS1 CallBridge Configuration.
CMS2 WebBridge Configuration.
But what is the Certificate Pinning?
Traditionally, SSL Handshake consists on the validation of the server’s certificate, let’s say collab.com. The validation is done using the CA’s certificate located in the certificate store of the web browser.
The certificate store contains several CA Certificates, may be more than 100.
If at least one CA delivers by mistake or more likely to conduct an attack a valid certificate for example *.collab.com, attackers are able to launch a Man In The Middle Attack.
In order to prevent this attack, it is possible to use the SSL protocol in another way, by creating an association between the domain name of a site (www.collab.com) and the certificate or certification authority expected. Thus, only the a certificate (of collab.com) signed by one of the specific certification authorities will be accepted and if the certificate of collab.com signed by another CA is presented, it is not trusted.
Certificate pinning can be explained with a simple words: Is this connection secure with a valid certificate and is it signed by the CA I’m expecting?
For Cisco Meeting Server, the C2W connection between the WebBridge and CallBridge uses the concept of certificate pinning to prevent the Man In the Middle Attack.
This is done by the webbridge3 c2W trust < Call Bridge Trust certificate Chain > and callbridge trust c2W < Web Bridge Trust certificate Chain > command.
The webbridge will trust certificates of callbridges that have been signed by one of those in its trust store, set by the < webbridge3 c2W trust < Call Bridge Trust certificate Chain > command.
The callbridge will trust webbridges that have certificates signed by one of those in its trust store, set by the < callbridge trust c2W < Web Bridge Trust certificate Chain > command.
In this scenario two differents CA are used to sign :
- The WebBridge certificate chain WEBBRIDGE-CHAIN.cer is signed by CA-collab.com server.
- The CallBridge certificate CALLBRIDGE.cer is signed by the CA-lab.local server.
Basically:
You tell the CallBridge service —-> trust only the WebBridge’s certificate WEBBRIDGE-CHAIN.cer signed by the certificate WB-C2W-Bundle.cer. It’s enforced with the callbridge trust c2w WB-C2W-Bundle.cer command.
You tell the WebBridge service —-> trust only the CallBridge’s certificate CALLBRIDGE.cer signed by the certificate CB-Bundle.cer. It’s enforced with the webbridge3 c2w trust CB-Bundle.cer command.
Since the CallBridge CMS1 is configured with the callbridge trust c2w WB-C2W-Bundle.cer command. It will trust only the WebBridge’s certificate WEBBRIDGE-CHAIN.cer signed by the certificate WB-C2W-Bundle.cer of the CA server Collab.com. In other words, the callbridge CMS1 will trust webbridges that have certificates signed by one of those in its trust store, set by the < callbridge trust c2W < Web Bridge Trust certificate Chain > command.
As shown below the Rogue WebBridge certificate Rogue-WB-Chain is signed by the WB-C2W-Rogue-Bundle certificate of the Rogue CA Server which is not trusted because the callbridge trust c2w WB-C2W-Bundle.cer command prevent this trust.
Verify the C2W connection status from the CallBridge CMS1 to the WebBridges CMS2 and CMS3.
The c2w connection from the CallBridge CMS1 to the WebBridge CMS2 shows the status Success. This is because the CallBridge CMS1 is configured to trust the certificate WEBBRIDGE-CHAIN signed by WB-C2W-Bundle using the callbridge trust c2w WB-C2W-Bundle.cer command.
The c2w connection from the CallBridge CMS1 to the WebBridge CMS3 shows the status connectionFailure. This is because the CallBridge CMS1 is configured to trust only the certificate WB-C2W-Bundle using the callbridge trust c2w WB-C2W-Bundle.cer command, therefore the WB-C2W-Rogue-Bundle certificate used to sign the Rogue WebBridge CMS3 ‘s certificate Rogue-WB-Chain is not trusted by CMS1.
From Jdoe-PC, open the Web Browser, type the guest URL https://meet.collab.com to access a meeting. The connection is successful. The DNS Server 10.1.5.19 returned the IP address of the legitimate WebBridge CMS2 10.1.5.62.
From Rogue-PC, open the Web Browser, type the guest URL https://meet.collab.com to access a meeting. The connection fails. The DNS Server 10.1.5.20 returned the IP address of the rogue WebBridge CMS3 10.1.5.63. The WebBridge certificate is signed by the CA Server Rogue.com which is not trusted by the CallBridge CMS1.
On CMS1, verify the CallBridge configuration.The CallBridge service trust only the WebBridge’s certificate WEBBRIDGE-CHAIN.cer signed by the certificate WB-C2W-Bundle.cer. It’s enforced with the callbridge trust c2w WB-C2W-Bundle.cer command.
On CMS1, configure the CallBridge service to trust only the WebBridge’s certificate Rogue-WB-Chain.cer signed by the certificate WB-C2W-Rogue-Bundle.cer.
The c2w connection from the CallBridge CMS1 to the WebBridge CMS2 shows the status connectionFailure. This is because the CallBridge CMS1 is configured to trust only the certificate WB-C2W-Rogue-Bundle using the callbridge trust c2w WB-C2W-Rogue-Bundle.cer command, therefore the WB-C2W- -Bundle certificate used to sign the WebBridge CMS2 ‘s certificate WEBBRIDGE-CHAIN is not trusted by CMS1.
The c2w connection from the CallBridge CMS1 to the WebBridge CMS3 shows the status Success. This is because the CallBridge CMS1 is configured to trust the webbridge certificate Rogue-WB-Chain signed by one of those in its trust store which is the certificate WB-C2W-Rogue-Bundle.
On CMS1, the syslog follow command displays a TLS handshake error with the WebBridge CMS2.
From Jdoe-PC, open the Web Browser, type the guest URL https://meet.collab.com to access a meeting. The connection fails. The DNS Server 10.1.5.19 returned the IP address of the WebBridge CMS2 10.1.5.62. The WebBridge certificate is signed by the CA Server collab.com which is not trusted by the CallBridge CMS1.
From Rogue-PC, open the Web Browser, type the guest URL https://meet.collab.com to access a meeting. The connection is successful. The DNS Server 10.1.5.20 returned the IP address of the rogue WebBridge CMS3 10.1.5.63. The connection is successful because the CMS3’s certificate Rogue-WB-Chain is signed by the CA Server rogue.com which is trusted by the CallBridge CMS1.
