The site works in Chrome, Firefox, etc but times out in Safari on both macOS Sierra and iOS. Here’s the relevant config settings (left out the standard vhost definition). This was working when I initially did it, but then stopped. I adjusted settings to the below in order to get the SSLlabs up to A+ (it was failing before that).
CentOS6, Apache 2.2
SSLEngine on
SSLProtocol ALL -SSLv2 -SSLv3 -TLSv1
SSLHonorCipherOrder on
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
SSLCertificateFile /etc/letsencrypt/live/www.patchvault.org/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.patchvault.org/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/www.patchvault.org/chain.pem
Although your "SSLCipherSuite" settings allow for:
The system seems to only manage:
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES128-SHA256
Try adding ":HIGH" just to test Safari access.
If that does display the site, then try: https://www.ssllabs.com/ssltest/viewMyClient.html
from the Safari clients and see which Ciphers are being used.
Added :HIGH at the end of the chain, and the time out is still occuring. Tried a private window in Safari as well, just to try and ensure that it wasn’t some weird local cache.
The SSLLabs test shows that Safari is using TLS1.2 with spdy and also lists the cipher. :HIGH drops the test quality to an “F” but the test “connects” for either setting. Could this be a mod_pagespeed/spdy issue or is something happening with the handshake (is that the right term?)
Safari 10 / OS X 10.12 R RSA 2048 (SHA256) TLS 1.2 > spdy/3 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
Totally different and unrelated mechanisms. HttpOnly only means that the cookie cannot be accessed by JavaScript. It means "HTTP protocol headers as opposed to scripts", not "HTTP as opposed to HTTPS".
Thanks for that clarification.
Sadly, that leaves me with no reason why this is failing.
Maybe you can see something we have missed…
In the interim, the only thing for me to add is that from an iPhone with Safari: https://patchvault.org works (mostly) https://www.patchvault.org does NOT work - only clue given:
“Safari could not open the page because the server stopped responding.”
The one failure to https://patchvault.org showed: Cannot Verify Server Identty
The Identity of “patchvault.org” cannot
be verified by Safari. Review the
certificate details to continue.
“Continue”
“Details”
“Cancel”
Details showed:
an untrusted cert for “www.patchvault.org” (not patchvault.org)
with Serial Number:
03 A2 DD 16 99 91 1A
8D A6 DE 17 F6 22 EA
66 C2 4A 25
A) You seem to have 3 certificates https://crt.sh/?q=%patchvault.org this is a common issue that you should fix as the certificate you are using does not cover patchvault.org
B) You do have a certificate that covers both
C) run certbot certificates to see the certificates you are currently managing (i believe there should be 3)
D) run certbot delete and remove 2 (the one that has only www. version of your site)
E) Update apache config
Generally have multiple versions of the same certificate is a bad idea as it creates confusion and also may get you in to issue with rate limits
Your assets take a while to load. i am on a slow connection however 7 seconds is quite a long time in the modern web world.
also I would turn off HTTP to HTTPS rewrite/redirection and then test over HTTP as well. If this fails under that condition then you know you have a core protocol issues rather than an SSL issue
so testing steps
A) Turn off HTTP -> HTTPS rediertion (you should be able to browse to http://patchvault.org)
B) test http://patchvault.org in both safari browsers
C) if issues still persist then turn of all spdy related settings
D) test again
E) If things are still not working you can probably narrow it down to another area
I am not sure how easy it is for you to add a DNS record but i would suggest that while you are setting up that you create a testing version of your website.
I usually have alpha.mydomain.tld and beta.mydomain.tld as well as mydomain.tld and www.mydomain.tld
the alpha and beta are testing and staging and it means I can do troubleshooting against those without affecting production (just a thought)
Thanks, Andrei. I’ll look into the 3 certs issue. I’m assuming I’d want to use the cert that covers www and straight up patchvault.org?
As for assets, there’s a large number of productization related tickets in the queue around caching, sprite making, etc. Right now nothing is cached, so it’s going to rails when it should be hitting an eTag’d static file once we’re a little closer to being “real”.
I’m using Safari 10.1.2 on the desktop and the iOS 11 beta on the phone, which do support SPDY. May turn that off just to limit the number of possible issues at this point.
You should remove the ":HIGH" from the SSLCipherSuite line; as shown by the SSL Labs test results = "B" and "DH 1024 bits FS WEAK"
Or append ":!DHE:!SHA1" to bring it back to what I believe you originally intended.
