Cockpit (252-1)doesn't work with Cloudflare Argo Tunneling

[CharlesGodwin]

Cockpit version: 252-1
OS: Linux ubuntu-02 5.13.0-16-generic #16-Ubuntu SMP Fri Sep 3 14:53:27 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Page: N/A

I'm trying to put Cockpit behind a Cloudflare Tunnel. It sort of works as the login page appears, but then, after I enter my credentials, I get an empty page.

I have set config.yml of cloudflared I use

• hostname: dashboard.mydomain.com
  service: http://localhost:9090
  and then I invoke it using https://dashboard.mydomain.com

This technique is working on other non-standard port tools such as grafana.

cockpit works properly when invoked directly, without Cloudflare tunnelling.

cockpit.log.gz

Steps to reproduce

1. setup a cloudflare tunnel
   I have set config.yml of cloudflared I use

• hostname: dashboard.mydomain.com
  service: http://localhost:9090
  2.try to access using http://dashboard.mydomain.com

[a73x7]

I was able to fix this by telling Cloudflare not to verify the self-signed certificate Cockpit presents by default. I see the same error I got in your logs:

cockpit-tls[7541]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.

Try making the config look like this:

- hostname: cockpit.example.com
  service: https://localhost:9090
  originRequest:
    noTLSVerify: true

Loading a valid certificate into /etc/cockpit/ws-certs.d would probably also work.

[martinpitt]

@a73x7 : Note that @CharlesGodwin used plain http between the proxy and port 9090 for cockpit, which is the recommended iteration. A major reason for using a reverse proxy in the first place is for the proxy to "take over" TLS.

[martinpitt]

@CharlesGodwin , can you please open the JavaScript console (Ctrl+Shift+J) on the login page, and then see if you get some error message?

[a73x7]

The setting still applies, because the first thing cockpit does after you login is make a websocket connection to wss://cockpit.domain.com/cockpit/socket. Note that's the secure websocket wss protocol, if there's a way to get cockpit to use the insecure ws that would probably work but I don't know how.

I would guess if they did that their error would be a failure to connect to wss://cockpit.domain.com/cockpit/socket, same as mine was. I had initially configured it to use HTTP, the difference is without the noTLSVerify setting HTTPS gives a 502 from the beginning while HTTP doesn't fail until you login.

[martinpitt]

You probably forgot to configure cockpit.conf for reverse proxy mode, i.e. Origins= and ProtocolHeader=? See https://github.com/cockpit-project/cockpit/wiki/Proxying-Cockpit-over-Apache-with-LetsEncrypt or https://github.com/cockpit-project/cockpit/wiki/Proxying-Cockpit-over-NGINX

[a73x7]

Nice, I got it working without any TLS settings. I had configured my cockpit.conf following the NGINX guide, hadn't seen the Apache one. The trick seems to be in the AllowUnencrypted = true, that makes it work with the Origins configured like either guide.

[CharlesGodwin]

It is resolved thanks to your help @martinpitt @a73x7
I added this: (I had tried it earlier but saw no change at that time)

- hostname: cockpit.example.com
  service: https://localhost:9090
  originRequest:
    noTLSVerify: true

And then /etc/cockpit/cockpit.conf I had also done that but the filename had a trailing dot that didn't help

Now all is good. I'm delighted.

cat /etc/cockpit/cockpit.conf
[WebService]
Origins = https://dashboard.xxxxx.ca wss://dashboard.xxxxx.ca
ProtocolHeader = X-Forwarded-Proto
AllowUnencrypted = true

[omps]

cat /etc/cockpit/cockpit.conf
[WebService]
Origins = https://dashboard.xxxxx.ca wss://dashboard.xxxxx.ca
ProtocolHeader = X-Forwarded-Proto
AllowUnencrypted = true

Adding the following and restarting the cockpit services fixed the issue