Browser cert error - cert mismatch, but only under certain conditions

Question

Ok bear with me, this is a little out there, and I'm hoping this is the right place to post: I have a client that works for a large company, and we have built a heroku application for them. He can reach the heroku app from his home, but when he connects to his office network from the same laptop, he gets this error message in latest version of Chrome when visiting the site: "This server could not prove that it is foo.bar.com; it's security certificate is from *.herokuapp.com" We have asked heroku and they feel the cert is in order. The user has the exact same version of Chrome that I'm using. I cannot duplicate the error because I am not authorized to connect the same enterprise WiFi network he connects to. I can however connect to that building's guest WiFi network, but would imagine that's not a valid test, since that network is wide open and likely partitioned off from the employee network.

Does anyone have any theories on how an enterprise network could interfere with a browser's ability to interpret a cert? Any other ideas, e.g. maybe there's a tool we can install to diagnose? We are trying to find well qualified internal IT personnel that could assist but this is difficult to do in a large company.

I've added this diagnostic information which may help confirm what's going on here.

When I run openssl on both the 'good' networks and the 'bad' networks, I get a different certificate for the '0' (first) cert in the chain, it's as if there are two certs or we've somehow misconfigured the certs, but we're unsure how they've been misconfigured, and why it would work at all if that was the case. Why would the client see a different cert chain just because they're on a different network?

Some people have said that this is caused by a certificate-rewriting proxy on the corporate network but the client has told me they don't do cert rewriting.

The output of my diagnostic command:

openssl s_client -showcerts -servername foo.bar.com -connect foo.bar.com:443

Here's the output on the 'bad' network (I've redacted specific data):

> CONNECTED(00000003) depth=1 /C=US/O=DigiCert
> Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
> verify error:num=20:unable to get local issuer certificate verify
> return:0
> --- Certificate chain  0 s:/C=US/ST=California/L=San Francisco/O=Heroku, Inc./CN=*.herokuapp.com    i:/C=US/O=DigiCert
> Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
> -----BEGIN CERTIFICATE----- xxxx
> -----END CERTIFICATE-----  1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA 
>   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High
> Assurance EV Root CA
> -----BEGIN CERTIFICATE----- xxxx
> -----END CERTIFICATE-----
> --- Server certificate subject=/C=US/ST=California/L=San Francisco/O=Heroku, Inc./CN=*.herokuapp.com issuer=/C=US/O=DigiCert
> Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
> --- No client certificate CA names sent
> --- SSL handshake has read 2745 bytes and written 458 bytes
> --- New, TLSv1/SSLv3, Cipher is AES128-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion:
> NONE SSL-Session:
>     Protocol  : TLSv1
>     Cipher    : AES128-SHA
>     Session-ID: xxx
>     Session-ID-ctx: 
>     Master-Key: xxx
>     Key-Arg   : None
>     Start Time: 1490624709
>     Timeout   : 300 (sec)
>     Verify return code: 0 (ok)
> --- DONE

Here's the output on the 'good' network:

> CONNECTED(00000003) depth=1 /C=US/O=Symantec Corporation/OU=Symantec
> Trust Network/CN=Symantec Class 3 Secure Server CA - G4 verify
> error:num=20:unable to get local issuer certificate verify return:0
> --- Certificate chain  0 s:/C=US/ST=Maryland/L=xxx/O=xxx/OU=Headquarters/CN=foo.bar.com 
>   i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec
> Class 3 Secure Server CA - G4
> -----BEGIN CERTIFICATE----- xxx
> -----END CERTIFICATE-----  1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure
> Server CA - G4    i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust
> Network/OU=(c) 2006 VeriSign, Inc. - For authorized use
> only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
> -----BEGIN CERTIFICATE----- xxx
> -----END CERTIFICATE-----
> --- Server certificate subject=/C=US/ST=xxx/L=xxx/O=xxx./OU=Headquarters/CN=foo.bar.com
> issuer=/C=US/O=Symantec Corporation/OU=Symantec Trust
> Network/CN=Symantec Class 3 Secure Server CA - G4
> --- No client certificate CA names sent
> --- SSL handshake has read 3069 bytes and written 458 bytes
> --- New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion:
> NONE SSL-Session:
>     Protocol  : TLSv1
>     Cipher    : AES256-SHA
>     Session-ID: xxx
>     Session-ID-ctx: 
>     Master-Key: xxx
>     Key-Arg   : None
>     Start Time: 1490624583
>     Timeout   : 300 (sec)
>     Verify return code: 0 (ok)
> --- DONE

Answer 1

The company is running an SSL intercepting proxy, and it the proxy is issuing its own certificate in place of the official herokuapp.com certificate.

Many large companies have SSL connections terminate at a proxy so that they can inspect the contents to make sure they are OK to enter or leave the network. Then the proxy replaces the certificate with its own certificate. For this to work, any browser or SSL client used in the company must trust the certificate the proxy signs. It would seem to me that that client you are using does not have the company's CA listed as a trusted certificate authority.

The fix is to add the company's CA as a trusted authority to your client, and you should be good. Chrome on Windows is supposed to trust the certificates in your machine's certificate Trusted Root store, so if the computer is correctly set up to trust the proxy, Chrome should work. Firefox maintains its own list of trusted CAs, and the company's CA cert must be added to it somehow. Other applications and tools, such as Java, Gradle, Git, etc,. also may depend on a private internal certificate store and would need to be configured to trust your proxy as a signer.

This picture shows how a typical proxy is set up.