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 :)