Are you having trouble with SSL on El Capitan (OS X 10.11)?
Here are the things I know about it right now:
- OS X’s OpenSSL is ancient (0.9.8-ish).
SecureTransport (OS X’s replacement for OpenSSL) may fall back to using OpenSSL if the environment variable
- Lots of places are “cross-signing” their intermediate certs to upgrade from SHA-1 to SHA-2 for security reasons.
- OS X’s OpenSSL cannot handle the intermediate cross-signing and report that it cannot verify certificates. SecureTransport handles this just fine.
- HomeBrew applications usually don’t support SecureTransport and instead use HomeBrew’s OpenSSL.
/usr/bin/curluses SecureTransport directly, unless you set
Normally, the above is just fine assuming you don’t set the
However, if you work for a company that uses internal certificates then life begins to suck.
Usually want to set
SSL_CERT_FILE so you can tell OpenSSL about the custom certificates but this
curl and anything else that uses SecureTransport. Like
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.
I don’t have a El Capitan system to try this on, but you might want to try adding the certificate to the SecureTransport System.keychain as seems to be explained here: https://derflounder.wordpress.com/2011/03/13/adding-new-trusted-root-certificates-to-system-keychain/
I would prefer avoiding Apple SecureTransport and the Apple provided curl when possible and use one compiled against libressl.
Apple’s history of contributions to SSL/TLS includes “GOTO FAIL” which isn’t very promising. Also, Tim Cook can say all he wants about how having no back door is a must but when Apple is the last company to revoke bad actors from their root CA then I have a hard time believing they are serious about not having backdoors. For example, leaving DigiNotar trusted for as long as they did still counts as a known backdoor even if not maliciously intended to be. Despite that, they seem to continue that policy of maintaining the root CA file as an OS/firmware update which is only revised when the rest of the update passes QA.
Also, before someone comes back with that anything said bad about Apple is pro-PC, I am NOT saying Microsoft has been better about their SSL and CA handling. Overall, I think the industry has failed in several ways with SSL/TLS. Instead of security, we have been given convenience. PGP’s multi-signer web of trust model should have been part of the design of SSL. Instead, a single CA signer per certificate was selected. A SSH model of defaulting to non-trust and prompting for each new contact should have been considered as well. At the very least, trusting each CA for the first time should have been prompted (“Do you want to trust SuperFish CA? Y/N”).
We are given by the industry both the downside of having over 90% of certificates signed by only four companies (of which some seem to be abusing our trust) while still also having the downside of silently trusting certificates signed by over 200 CAs.
curl also provides the “-k” or “—insecure” option for those that have given up on SSL/TLS providing protection against MiTM attacks anyways. If the connection is going across an internal network physically under your control (or VPN connection), what is the worse that can happen? :P
The identity-trust problem is a sticky one and no OS vendor has done well. I suspect asking users would be useless, too, as users would just stomp on “Yes”.
There are smarter people than me working on it and I don’t think they have a solution.
Re: SecureTransport — That’s where most of Apple’s brain power is aimed at, at the moment. I trust it reasonably well. I like the direction LibreSSL is going.
However, I feel like there should be a common API for looking up trusted CA roots with a never changing API. So Apple can return a certificate from the Keychain while Windows returns it from their Secure Store.
Also: “Hi, Ben!”
I agree that 99% of users would just stomp on “Yes.” I would also understand a web browser having a “Yes to all in the future” check box. The prompts would be to get that last remaining 1% that would ask “What is SuperFish?” and blog about it. Rather than silently trusting all CAs for all users, at least encourage some users to be part of the auditing process.
I would also prefer a common API, CLI and certificate file format. Instead, I feel IPSEC adoption was crippled by the complexity of enrolling certificates. Not only was there the issue that some systems wanted pk12 files and others wanted pem, but the steps taken to enrolled would change even between versions of the same OS.
But did keychain enrollment at least help?
Also: “Hi, Christian!”
I was totally stuck on this. New Macbook. Factory install of El Capitan 10.11. I grabbed cacert.pem from here: http://curl.haxx.se/docs/caextract.html and used that as my SSLCERTFILE. Now system curl works.
Could you provide a reference for your statement (2.) “SecureTransport (OS X’s replacement for OpenSSL) may fall back to using OpenSSL if the environment variable SSLCERTFILE is set.” I cannot find any official documentation describing this.
I updated the article a little. I don’t think pure SecureTransport programs ever fallback, it’s the weird hybrid programs that use Apple’s OpenSSL that have problems.
Thanks, it makes it clearer. Still investigating…