Our implementation of SSL uses Server Name Indication (SNI), and that allows you to potentially have multiple environments on the same server, each with its own SSL certificate that you have uploaded through our Acquia Cloud web interface.
When making more traditional ssl connections, you use a syntax to connect to the IP of the server.
For example openssl s_client -connect dev.yourdomain.com:443
This will return the SSL certificate that's installed on the server, but since it looks for the certificate by IP - and doesn't pass the -servername argument you get the default certificate (Acquia's certificate) and not the certificate you installed via the Acquia SSL upload tool
and you may get a Certificate Error message that looks like this:
[Thr 140052323628800] Peer not trusted
[Thr 140052323628800] Certificate
[Thr 140052323628800] Certificate
[Thr 140052323628800] Subject :EMAIL=ssl@acquia.com, CN=*.acquia-sites.com, OU=Acquia Hosting, O=Acquia Inc,
[Thr 140052323628800] Issuer :EMAIL=ssl@acquia.com, CN=acquia.com, OU=Hosting, O=Acquia Inc, SP=MA, C=US
[Thr 140052323628800] Serial number :0x06
[Thr 140052323628800] Verification result
[Thr 140052323628800] Status :Not successful
[Thr 140052323628800] SignerStatus :Not successful
[Thr 140052323628800] SignerVerificationResult :None
To be able to successfully negotiate a connection with an SNI type certificate, the -servername argument must be used, this is fundamental to the protocol.
This successful command correctly uses the -servername argument:
openssl s_client -showcerts -servername dev.yourdomain.com -connect dev.yourdomain.com:443 Keep in mind that the SSL negotiation must occur prior to sending the HTTP request through to the remote server. That means that the browser and the server have to do the certificate exchange earlier in the process and the browser wouldn’t get the opportunity to specify which site it’s trying to reach. SNI fixes that by allowing a Host: header type of exchange during the SSL negotiation process.