How to set up remote access with cockpit and nginx

[jamminjames]

I am trying to get the cockpit web console working with a remote connection on our server following these instructions. Right now, I can log in remotely only with an HTTP connection using the ip and 9090 port. I want to connect via HTTPS, and using the domain name instead of the ip would be nice, but I'm not sure if it's necessary or even preferable.

I'm confused trying to follow the instructions. Where it says to create a virtual server block, it gives an example line of server_name cockpit.domain.tld; Is "domain.tld" a stand-in for your actual domain, or should I use it exactly like that?

The instructions also say to put this in the the Cockpit config file:

[WebService]
Origins = https://cockpit.domain.tld wss://cockpit.domain.tld
ProtocolHeader = X-Forwarded-Proto

... so would the nginx server block be referring to that, or should I use our actual domain there as well?

If it is our domain, and we're setting up a subdomain name of 'cockpit', does that need to be set up in our DNS records as well?

And as for the certificate, can I just copy over our website's SSL cert, or do I need to come up with a new one?

Thanks for any help!

[martinpitt]

cockpit.domain.tld is a stand-in, i.e. please replace it with your actual server name and domain (FQDN). Perhaps it should say cockpit.example.com?

Wrt. the certificate: The whole idea is that nginx does the reverse proxying and TLS. So from the outside, the browser talks to nginx on the configured domain name. nginx then forwards the requests to cockpit on (usually) http://localhost:9090, so cockpit itself does not speak TLS or even need a certificate. You usually use the same TLS cert for your entire site, including any subdomains (like cockpit.*).

However, cockpit needs to be told what domain name it "appears" to have, so that it can compute correct links and enforce a correct "same origin" policy. It cannot detect that by itself. That's what you do with Origins =.

Does that make sense?

[jamminjames]

A redirect trace shows it's getting redirected to our main domain, showing "X-Redirect-By: WordPress".

However, for it to get to the main domain, since the DNS CNAME file is for cockpit.humortimes.com, it must go through the above .conf file first, right? And the conf file is supposed to proxy it to the localhost 9090 port. So why does it proceed to the main domain? Does this file need tweaking when a CDN like Cloudflare is involved? Maybe the proxy_set_header lines need to be changed? I'm not sure what they do.

How can I troubleshoot this issue?

[martinpitt]

I'm afraid I have no idea how wordpress enters the game here. Maybe that configuration "grabs" all other virtual domains somehow?

[jamminjames]

But what about the CDN (Cloudflare) we're using. Is there something we need to do with our Cockpit setup differently in the case of a CDN?

[martinpitt]

I've never set up cloudflare, I have no idea. My hunch is that it is unrelated, and it's your wordpress configuration which "grabs" the cockpit domain.

[jamminjames]

CDNs are very common though. Is there anyone with this cockpit project that might know for sure if I need to tweak the cockpit server block to deal with the CDN? Again, I don't see how Wordpress could 'grab' it first, it is in the main domain, and the DNS points to cockpit.mywebsite.com.

[jamminjames]

OKAY! Finally figured it out. It was simply that my main server block was more specific than the subdomain server block. It had the IP and the port, whereas the subdomain block only had the port! Nginx will pick the more specific one first, as the request is coming to that IP.

Now it’s working. Thanks for your help and your patience!

[martinpitt]

I'm glad you figured it out!