Safari Incompatability #3640

Open
nrotschafer opened this Issue Jan 29, 2016 · 10 comments

Projects

None yet

7 participants

@nrotschafer

I have tried to access the Cockpit web interface from multiple versions of Safari and keep getting the message "Server has closed the connection". This same behavior occurs on OSX 10.11 El Capitan both on version 10.11.3 and 10.11.4beta. This also happens on an iPhone 6S Plus on iOS 9.2.1 and an iPad Pro on 9.3 beta 2. However on the 2 Macs tested, switching to Chrome resolved the issue. On the two iOS devices using Chrome didn't affect the outcome (Chrome on iOS is required to use the Safari Web View...so this was expected).

@Endogen
Endogen commented Feb 5, 2016

I have the same problem. Would like to use cockpit with Safari but since i have installed version 0.77 (on CentOS 7 from extras repo) and there is something wrong with the https stuff, i can only connect to cockpit via Chrome. I think Safari blocks non https connections in this case(?).

It should be possible to disable SSL for cockpit if you with to use it with Safari. See here

@stefwalter stefwalter self-assigned this Feb 9, 2016
@petervo
Contributor
petervo commented Feb 17, 2016

Safari doesn't support self-signed certificates over wss. Users need to either install a known ca issued certificate or disable tls.

@andreasn do we think we should design a message for this or just document it clearly somewhere?

@andreasn
Contributor

We might as well document there and then in the browser if we can.
Do they have to disable tls alltogether, or only for that particular address/port?

@petervo
Contributor
petervo commented Feb 17, 2016

They need to disable tls in cockpit, the --no-tls flag. But really a proper certificate is the better fix.

@Endogen
Endogen commented Feb 17, 2016

I have a free Let's Encrypt certificate and have that problem with Safari. Is that normal? I would expect cockpit to work with that.

@petervo
Contributor
petervo commented Feb 17, 2016

@Endogen, is it trusted by your system and did you include the chain in the certificate file?

@Endogen
Endogen commented Feb 17, 2016

I honestly have to say that i don't know. All i know is that my server is now accessible via https and i followed the Let's Encrypt install guide. Meaning, i got this message No installers are available on your OS yet; try running "letsencrypt-auto certonly" to get a cert you can install manually which is ok because i use CentOS and there is no automatic installer. So i executed letsencrypt-auto certonly, configured virtual hosts, restarted the apache service and that's it.

@igorSmirnovPlexi

Is any solution for this behaviour, except --no-tls flag?

@petervo
Contributor
petervo commented Jul 18, 2016

The solution should be to use a valid trusted certificate. @igorSmirnovPlexi are you trying with a self-signed cert or Let's Encrypt?

@rhwood
rhwood commented Aug 13, 2016 edited

If it's of any interest, I created certificates using Let's Encrypt using the following commands:

sudo firewall-cmd --add-port=443/tcp
sudo letsencrypt certonly --standalone -d $( hostname )
sudo cat /etc/letsencrypt/live/$( hostname )/fullchain.pem /etc/letsencrypt/live/$( hostname )/privkey.pem > $( hostname ).cert
sudo cp $( hostname ).cert /etc/cockpit/ws-certs.d/
sudo chown root:cockpit-ws /etc/cockpit/ws-certs.d/$( hostname ).cert 
sudo chmod 640 /etc/cockpit/ws-certs.d/$( hostname ).cert
sudo firewall-cmd --remove-port=443/tcp

Some notes:

  • I use Safari as my primary browser
  • The system I use is not running a service on port 443. If you have a service running on that port, stop and start that service instead of enabling/disabling the firewall
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment