3

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
|improve this question
  • Can you please edit your post and add some details: what network is the heroku app located on? Does the cert look exactly the same from the client's home network, work network, and your network? – PwdRsch Mar 9 '17 at 18:01
  • 1
    This could be related to SNI: if the company uses an SSL interception system which can not deal properly with SNI then it will get the default certificate (*.herokuapp.com) and not the site-specific certificate. But this is just a guess based on the few details available. – Steffen Ullrich Mar 9 '17 at 18:41
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.

enter image description here

|improve this answer
  • actually before I assume this, can you check the ssl fingerprint that your client sees when accessing from the company and let me know if it is the same that you see when accessing outside of the network. – MikeSchem Mar 9 '17 at 17:56
  • Thanks this sounds promising, the SHA fingerprints do NOT match. If indeed this means there is cert re-signing happening, do you know if organizations make a practice of maintaining a URL whitelist (allowing us to register our URL as 'ok') in the appliance that is doing the re-signing, or, are we likely stuck with this problem. Or any other advice is appreciated. Thanks! – bethesdaboys Mar 9 '17 at 18:58
  • Lol, interesting that I get a down vote when I'm pretty sure I know what's going on. – MikeSchem Mar 9 '17 at 19:30
  • I'll add details – MikeSchem Mar 9 '17 at 19:30
  • 1
    You were most likely downvoted because you created a stub of an answer, which isn't what we want here. You can certainly edit in more details later if needed, but your initial answer should be complete. Otherwise wait to answer until you have all the information you need. – PwdRsch Mar 9 '17 at 19:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.