Testing, especially the automated variety is very effective.

But you need consistent tooling :O)

Don’t fall into the trap of using non-openssl CURL, if you are using OSX.

I fell into just this.

I was testing an API endpoint, and the testing was working just fine, on a PC :)

If took a while to identify the issue, which confirmed that the installed CURL was not using OpenSSL (but rather SecureTransport):

curl --version
curl 7.43.0 (x86_64-apple-darwin15.0) libcurl/7.43.0 SecureTransport zlib/1.2.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz UnixSockets

I then checked the endpoint I was hitting. Apache was reporting the following:

==> /var/log/httpd/error_log <==
[Fri Jan 13 16:27:08.383282 2017] [ssl:error] [pid 16785:tid 139863856736000] [client ??.??.??.??:61387] AH02261: Re-negotiation handshake failed: Not accepted by client!?

I resolved this pesky situation by installing the OpenSSL version of CURL:

$ brew install curl --with-openssl

And then checking the OpenSSL support:

$ /usr/local/Cellar/curl/7.52.1/bin/curl --version
curl 7.52.1 (x86_64-apple-darwin15.6.0) libcurl/7.52.1 OpenSSL/1.0.2j zlib/1.2.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP UnixSockets HTTPS-proxy

OpenSSL/1.0.2j instead of SecureTransport.

Testing was now consistent with the Windows boxes :)