I don't exactly have a solution, but I can explain what is the reason behind this and what you may have to double check on your side.
So, in short, this is happening because of SNI (Server Name Indication) and because of the client's inability to support SNI.
Check this answer for some insight into this issue https://serverfault.com/questions/594368/openssl-returns-different-ssl-certificate-to-that-shown-by-chrome
In this case, the same IP is hosting a bunch of domains and certificates. Most of the modern browsers support SNI and will be able to detect this and show you the right certificate (try firefox).
However, when the SSL client of a server is trying to do a handshake (without specifying 'server name'/'host name') it doesn't know which certificate to fetch, and hence fetches the core certificate.
Solution?
The client should 'indicate' that this is the host name and then it'll fetch the right certificate.
Example:
openssl s_client -connect dev.botframework.com:443
VS
openssl s_client -servername dev.botframework.com -connect dev.botframework.com:443
How to Solve this?
Skip the host name verification phase. Disabling SSL Certificate Validation in Spring RestTemplate or another Example:
Registry<ConnectionSocketFactory> registry = RegistryBuilder. <ConnectionSocketFactory>create()
.register("http", PlainConnectionSocketFactory.getSocketFactory()).register("https", new SSLConnectionSocketFactory(SSLContexts.createDefault(), new HostnameVerifier() {
@Override
public boolean verify(String hostname, SSLSession session) {
return true;
}
})).build();
