Apache2 - SSL pages load in Chrome but not Safari

Question

I'm having this unusual SSL issue with Safari. Basically I have a Debian server running Apache 2 (2.4.10) with OpenSSL 1.0.1t on a private network.

I've set up an SSL virtual host in the normal way and I'm using a web server certificate signed with an intermediate which in turn is signed by a private root certificate installed on all machines using an Apple configuration profile and I've verified the root is installed on the keychain.

In Chrome - this setup works fine. The page loads and the SSL certificate chain is good and Chrome reports no errors and the green padlock.

In Safari (10) - but it happened with v9 as well - and on iOS 10 - all I'm getting is "Safari can't open the page xxx because Safari can't establish a secure connection to the server xxx".

Oddly enough if I restart the Apache server it works in Safari for a couple of seconds - enough to get one page load in - before it fails again.

In cURL on the desktop - Unknown SSL protocol error.

In openssl (s_client -connect) - connected OK with Protocol: TLSv1, Cipher: EDH-RSA-DES-CBC3-SHA.

In nscurl -ats-diagnostics - FAIL on every attempt.

---

I thought this must be an issue with the Apache configuration so I've stripped out as much as I can that I think might be causing the issue and now in my ssl.conf I have set SSLProtocol to ALL -SSLv3 and SSLCipherSuite to MEDIUM:!aNull and in the .conf file for the vhost I have got SSLEngine on and the only other SSL configuration in there are for the certificate file, intermediate and key.

---

But still the site stubbornly refuses to open in Safari. What makes it very odd is that Chrome works OK! Any public SSL sites I try to go to in Safari work fine.

Any advice appreciated!

Answer 1

Looking your trace, I think I got it. Seems like the Apache virtualhost replying on IPv6 in port 443 is configured to "speak" HTTP, not HTTPS.

I verified this trying to connect to: https://google.com:80/ (or any other site) while sniffing, and the reply i get is exactly 400 like in your case.

So, check your Apache VirtualHost configuration, or just disable IPv6 in your server if you are not planning to use it.

Answer 2

Anytime I tell a software, such as you've told Apache, a cipher suite string like MEDIUM:!aNULL it works best for me to test it first with openssl ciphers command. This way you can discover many curious behaviors.

openssl ciphers -v 'MEDIUM:!aNULL'
DHE-RSA-SEED-SHA        SSLv3 Kx=DH       Au=RSA  Enc=SEED(128) Mac=SHA1
DHE-DSS-SEED-SHA        SSLv3 Kx=DH       Au=DSS  Enc=SEED(128) Mac=SHA1
SEED-SHA                SSLv3 Kx=RSA      Au=RSA  Enc=SEED(128) Mac=SHA1
IDEA-CBC-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=IDEA(128) Mac=SHA1
IDEA-CBC-MD5            SSLv2 Kx=RSA      Au=RSA  Enc=IDEA(128) Mac=MD5
RC2-CBC-MD5             SSLv2 Kx=RSA      Au=RSA  Enc=RC2(128)  Mac=MD5
KRB5-IDEA-CBC-SHA       SSLv3 Kx=KRB5     Au=KRB5 Enc=IDEA(128) Mac=SHA1
KRB5-IDEA-CBC-MD5       SSLv3 Kx=KRB5     Au=KRB5 Enc=IDEA(128) Mac=MD5
ECDHE-RSA-RC4-SHA       SSLv3 Kx=ECDH     Au=RSA  Enc=RC4(128)  Mac=SHA1
ECDHE-ECDSA-RC4-SHA     SSLv3 Kx=ECDH     Au=ECDSA Enc=RC4(128)  Mac=SHA1
ECDH-RSA-RC4-SHA        SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128)  Mac=SHA1
ECDH-ECDSA-RC4-SHA      SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128)  Mac=SHA1
RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
RC4-MD5                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5
RC4-MD5                 SSLv2 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5
PSK-RC4-SHA             SSLv3 Kx=PSK      Au=PSK  Enc=RC4(128)  Mac=SHA1
KRB5-RC4-SHA            SSLv3 Kx=KRB5     Au=KRB5 Enc=RC4(128)  Mac=SHA1
KRB5-RC4-MD5            SSLv3 Kx=KRB5     Au=KRB5 Enc=RC4(128)  Mac=MD5

What you could deduce from this listing is that, counterintuitively, MEDIUM means you want to exclude HIGH and LOW ciphers. Nowadays, the MEDIUM turns out to be just ancient. You can reasonably expect that any cipher suite which depends on RC4 or MD5 is disabled as insecure by clients. Support for IDEA or SEED could be not very widespread on the clients, as these were never the major ciphers. Support for SHA (old SHA1) would go away in the very near future.

In the openssl ciphers ignore the second column (SSLv3 there doesn't mean you actually use SSLv3, this is just a minimum required SSL level).

I would suggest to use HIGH:-RC4:-MD5:-PSK:-aNULL:-eNULL or, if you want to be super-new/super-secure, use HIGH:-SHA:-RC4:-MD5:-PSK:-aNULL:-eNULL

If you want to use the super-complicated explicit cipher list (like Mozilla's suggested list) be aware that you need to update the list manually with new ciphers from time to time, as you migrate to newer versions of openssl.

If you wish to explicitly give preference to some of the ciphers on Apache, you probably need to SSLHonorCipherOrder off otherwise the client-side ordering will be authoritative.

Answer 3

Using MEDIUM might be problem for modern browsers, because they will forbid many old ciphers.

You may check Mozilla's suggestion about cipher, for example, you can use its "Intermediate compatibility (default)" settings: (it's very long, just copy & paste)

SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS

Answer 4

Thanks for replying. I figured it out in the end by sniffing the connection between Safari and Apache and then Chrome and Apache. The server is on a private network, as I said, and I am using Avahi (zeroconf) to provide name resolution so I can use something like web-server.local and it automatically gets resolved to the correct IP address. Safari was trying to use ipv6 to connect and Chrome was trying to use ipv4.

Wireshark gave me some very unusual results when I tried to connect using Safari - here's a screenshot. It seems like the SSL connection starts being established and then the server sends a 400 error immediately.

Output from Wireshark with Safari

I tried going direct to the IPv4 address in Safari - it worked apart from the obvious certificate mismatch error.

So I disabled IPv6 in Avahi (the zeroconf daemon) and in Apache on the server. Rebooted and it works now.

Any insight as to why it might be behaving like that would be appreciated though!