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
SSLProtocol ALL -SSLv2 -SSLv3 -TLSv1
It appeared to be similar to this issue ([solved] Safari fails to talk to LE-powered website, other browsers are fine) but it DOES work with
Although your “SSLCipherSuite” settings allow for:
The system seems to only manage:
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.
: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
Well you can remove the test “:HIGH”.
If SSL Labs has no issue with the cert then this problem is not cert related.
Nonetheless, I would rerun both SSL Labs tests.
For the server (https://www.ssllabs.com/ssltest/) and look at:
- Supported Named Groups
- Everything within the “HTTP Requests” section (near the bottom)
For the client (https://www.ssllabs.com/ssltest/viewMyClient.html)
- Ensure that your particular Safari client supports at least one of the “Supported Named Groups” seen on the server.
Most likely the problem will be found somewhere within server line 2 results.
Maybe you can post that entire section here.
From the browser (named groups):
secp256r1, secp384r1, secp521r1
Cert named group:
So that’s covered. Here’s the HTTP REquest dump:
Date Fri, 21 Jul 2017 01:58:58 GMT.
Server Apache/2.2.22 (@RELEASE@)
Cache-Control max-age=0, private, must-revalidate
Strict-Transport-Security max-age=15552000; includeSubDomains
X-XSS-Protection 1; mode=block
X-Powered-By Phusion Passenger 5.1.2
Set-Cookie _patch_vault_session=QTMvQ29JZVJoY08xZ0x0UzhhZ250VXNZTTZKMGpDc3hvamgxT1NSZ3JnQ0JsNi84N1VYQzBuOFp2SzNJT3FaaFRLNDRiYmZMN0JJZk5lQ01ZSDBxWEFhSkNLb3N6YVIzYWgrTVlmMlcvN2xwOWZ4TFpsRUdNTVE3UmZxeXRweTZvUlVlK1UxTUVSV01kcm9waVduZ05FUXZSYVcrSDdaSG5TQzcyUXgyOVQzY3BsMjlsL292bTZtc2NLenNTSWY0LS1yRTNVQXpLVFljWmpuRkZrV2FYdkxnPT0%3D--0562ffee34fa85b430ad4134bac74d9d551ef248; path=/; secure; HttpOnly
Status 200 OK
Cache-Control max-age=0, no-cache, s-maxage=10
Content-Type text/html; charset=utf-8
not sure if this even matters but your using HSTS and the cookie ends with “HttpOnly” - maybe Safari doesn’t like that?
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
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.
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
–hopefully this will help you figure it out–
I think maybe you are looking at the wrong areas
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.
I also noticed that you are using SPDY3 https://spdycheck.org/#www.patchvault.org. What version of Safari are you using your devices?
Try turning the SPDY settings off and testing with the two browsers you have
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
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.
I would see how the performance goes over HTTP I would expect the loads to be faster
You have quite large assets being downloaded so it couldn’t be a mobile browser not waiting long enough for your CSS and JS files to load.
It’s a weird problem but my thinking it’s a web related one not an SSL one.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.