curl and openssl see different issuers - ssl

Question

I'm very confused by this, and no doubt this is my misunderstanding or some such, but I'm trying to get my machine to talk to an upstream proxy, i'm using redsocks to transparently redirect to upstream.
Below we can see curl
root#Amachine:/# curl -v -k https://bower.herokuapp.com
* Rebuilt URL to: https://bower.herokuapp.com/
* Hostname was NOT found in DNS cache
* Trying 54.235.187.231...
* Connected to bower.herokuapp.com (54.235.187.231) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-SHA
* Server certificate:
* subject: C=US; ST=California; L=San Francisco; O=Heroku, Inc.; CN=*.herokuapp.com
* start date: 2014-01-21 00:00:00 GMT
* expire date: 2017-05-19 12:00:00 GMT
* issuer: CORPORATE PROXY
Issuer appears to be the corporate proxy. Breaking all ssl comms.
root#machine:/# openssl s_client -connect bower.herokuapp.com:443
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
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
What's baffling me is that they have different issuers. Granted curl seems to hide most of what is going on. I can specify the root ca path and openssl works, and gives me an ok, but curl somehow is using a different path
I'm actually not sure how to debug what on earth is happening in curl. I thought I would get a similar issuer. I may be misunderstanding how s_client works though, does anyone know what is happening?

Answer 1

You have a SSL interception proxy in your network and curl is using it while openssl does not use it, or the proxy does not intercept the connections. It is not clear from your description what the case is exactly, but it might be
that you are using different machines, and from one the connections get intercepted while on the other not
that the intercepting proxy will not intercept connections without server name indication (SNI). Curl does SNI while openssl does not the way you use it. Use the -servername argument to retry with SNI.

Answer 2

1) You used the -k option to curl, which makes it ignore the CA verification - but at least it's showing what would the problem be, an MITM SSL proxy.
Presumably you can't bypass it, in this case a better option might be to retrieve the "CORPORATE PROXY" CA itself, and make it a trusted CA on your workstation. This is generally not a good idea, as it's destroying any effort that the CA's made to verify the certificate subject. On the other hand corporate networks generally make this decision for you anyway.
2) openssl is complaining only because it does not check the CA chain by default. It also seems you're not on the same network and/or use a different set of proxies than with curl. You may learn this if you check the environment for http_proxy or similar:
# printenv|egrep -i '(http|proxy)'
Or, if all else fails, perhaps the curl you're using is hardwired to use a different socks proxy, you can check with strace, what IP address curl and openssl is connecting to. Look for the connect syscall use with:
# strace -f -e connect curl https://www.google.com:443
As you mentioned, openssl needs the -CApath CERTIFICATEDIR option to verify the issuers with the CA certificates specially named in the CERTIFICATEDIR. Apart from CERTIFICATEDIR, it's actually checking the system certificate directory as well which was provided by the distribution - so as a shortcut, something as simple can usually work:
# openssl s_client -CApath 1 -connect bower.herokuapp.com:443
1 will be checked as a directory for certificates, but if it does not exist, the system will be consulted. Other useful options you can find in the manual for s_client
-servername SNI
Will send a hostname option in the initial clienthello packet so that the server (and the corporate proxy) can better decide which certificate to use on the host.
-CAfile FILE
If you know there's only a single acceptable CA for the connection.
-showcerts
If you want to record and analyse all the certificates in PEM format.
-status
It asks the server to provide the OCSP status of its own certificate via OCSP stapling and openssl will verify if it is valid.

Answer 3

In my case I had environment variable https_proxy defining proxy, which curl was fetching and using, while openssl was not using it. Thus, corporate proxy was serving different issuers for the certificate. After adding command parameter -proxy to openssl, both curl and openssl were serving same certificate chains.