MacOS – tlsv1 alert protocol version when connecting via SSL to OS X Server

macososx-serverssl

How can I re-enable TLS 1.1 and 1.0 on server 5.3 with macOS 10.12.4 in the short term while I evaluate all the clients that aren't ready for TLS 1.2?

If you jump to the bottom, attempts to change comfiguration files have failed so far to restore backwards compatibility

SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2

After having updated our server to macOS 12.4 and the Server app to version 5.3, using curl to connect to a macOS server https site from a Linux machine ceased to work, issuing the following messages on the client side:

$ curl -v --insecure -o "output.file" https://myserver.domain/path/page.php
* About to connect() to myserver.domain port 443 (#0)
*   Trying 192.168.xxx.xxx... connected
* Connected to myserver.domain (192.168.xxx.xxx) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs/
* SSLv3, TLS handshake, Client hello (1):
} [data not shown]
* error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
* Closing connection #0

The connection worked well before the update of the macOS server. So it seems that the update switched off a connection option which curl relies on. I googled a lot, but I am still uncertain about what exactly the cause is.

The same curlcommand works when issued from another Mac. The linux machine has

$ curl --version
curl 7.19.0 (x86_64-suse-linux-gnu) libcurl/7.19.0 OpenSSL/0.9.8h zlib/1.2.3 libidn/1.10
Protocols: tftp ftp telnet dict ldap http file https ftps 
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz 

while on the Mac client

$ curl --version
curl 7.51.0 (x86_64-apple-darwin16.0) libcurl/7.51.0 SecureTransport zlib/1.2.8
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 

Unfortunately, it is not an option to try updating curlon the Linux machine.

Some resources claim incompatible cipher suites to be the cause, but after some testing, I haven't been able to find a solution using the --ciphers option, and also I am not sure how to find a compatible cipher suite.

I have tried to find out what changed with macOS Server 5.3, but the Apple change log does not give me any hint about it. So the question is:

What has changed in macOS 12.4 and/or macOS Server 5.3 and how can I re-configure my macOS server so the curlconnection works again?

Update 1:

I have temporarily exposed port 443 to the public, so I could perform the SSL Labs tests. The results show that my macOS server supports only TLS 1.2 and nothing else any more. For several simulated clients, the test report Server sent fatal alert: protocol_version – including, for example, IE8-10/Win7 and Java7u25.

I have tried to reactivate TLS 1 and 1.1 in

  • /library/server/web/config/apache2/sites/0000_127.0.0.1_34543_myserver.domain.conf
  • /library/server/web/config/apache2/httpd.conf
  • /library/server/web/config/apache2/httpd_server_app.conf
  • /library/server/web/config/proxy/apache_serviceproxy.conf (multiple instances here)

changing

SSLProtocol -all +TLSv1.2

into

SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2

or even

SSLProtocol All

but it did not make a difference when fetching the URL with curl.

Update 2:

The service proxy error log shows

[datetime] [ssl:info] [pid n] [client x.x.x.x:38805] AH02008: SSL library error 1 in handshake (server myserver.domain:443)
[datetime] [ssl:info] [pid n] SSL Library Error: error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number
[datetime] [ssl:info] [pid n] [client x.x.x.x:38805] AH01998: Connection closed to child 11 with abortive shutdown (server myserver.domain:443)

To me, it looks as if my attempts to activate TLS v1 do not work.

So the question is: How can I reactivate TLS v1 in macOS Server Apache?

Best Answer

curl 7.19.0 ... OpenSSL/0.9.8h

This is a very old (and unsupported) version of OpenSSL you are using here which has no support for modern protocols like TLS 1.2 and modern ECDHE ciphers. Chances are high that after the upgrade your server now requires such protocol and/or cipher and thus connecting with your old OpenSSL version will fail.

* SSLv3, TLS handshake, Client hello (1):

This might also indicate that your client is trying to use SSL 3.0, which is usually disabled today because it is an insecure protocol. You might try to enforce to use TLS 1.0 (which is supported by OpenSSL 0.9.8) by using curl -1 or curl --tls1 in the hope that the server still supports TLS 1.0 and has ciphers configured to be usable by the old OpenSSL version.