El Capitan and the evils of OpenSSL

Are you having trouble with SSL on El Capitan (OS X 10.11)?

Me too.

Here are the things I know about it right now:

1. OS X’s OpenSSL is ancient (0.9.8-ish).
2. OS X’s preferred SSL library is SecureTransport which is modern and secure.
3. Some programs compiled with OpenSSL seem to use SecureTransport unless an OpenSSL-specific feature is requested (e.g. SSL_CERT_FILE or SSL_CERT_DIR is set).
4. SecureTransport (OS X’s replacement for OpenSSL) may fall back to using OpenSSL if the environment variable SSL_CERT_FILE is set.
5. Lots of places are “cross-signing” their intermediate certs to upgrade from SHA-1 to SHA-2 for security reasons.
6. OS X’s OpenSSL cannot handle the intermediate cross-signing and report that it cannot verify certificates. SecureTransport handles this just fine.
7. HomeBrew applications usually don’t support SecureTransport and instead use HomeBrew’s OpenSSL.
8. /usr/bin/curl uses SecureTransport directly, unless you set SSL_CERT_FILE (see above).

Normally, the above is just fine assuming you don’t set the SSL_CERT_FILE environment variable.

However, if you work for a company that uses internal certificates then life begins to suck.

Usually you want to set SSL_CERT_FILE so you can tell OpenSSL about the custom certificates but this will break curl and anything else that uses SecureTransport. Like curl.

I think the work-around is to not use SSL_CERT_FILE to update all the cert.pem files the various OpenSSL versions use:

• /usr/local/etc/libressl/cert.pem — HomeBrew’d LibreSSL
• /usr/local/etc/openssl/cert.pem — HomeBrew’d OpenSSL
• /opt/chefdk/embedded/ssl/cert.pem — ChefDK’s OpenSSL (installed via BrewCask)
• /opt/vagrant/embedded/cacert.pem — Vagrant’s OpenSSL (installed via BrewCask)

This is frustrating.