Open Web Console remotely with https?

How can I open the Web Console remotely with a “https” url? It only opens with http, and I get a security warning.

I’m using the ip address, port 9090 for the url, because when I use the website root (, I get a ‘ERR_CONNECTION_TIMED_OUT’ error.

We use Cloudflare, do I need to set up something there to allow access?

Thanks for any help!

P.S. It works now with the non-SSL ip, eg, (not the real one) but not with the SSL ip, Why would that be?

Does the port need to be set up in the server block with a “listen” line in nginx? If so, would it be added to the same server block with “listen”, or a separate one?

I have explicitly excluded cockpit from all of my systems, so I don’t have verified details about it, but it seems to be/have an implementation of HTTP-server of its own, distinct from Apache and nginx. The cockpit-ws does not depend on the other web server implementations.

Only one service, program, can listen on specific port. One cannot expect both HTTP and HTTPS traffic on same port simultaneously. The default seems to be that cockpit has service listening for HTTP on 9090/tcp and that port is opened in firewall rules for that.

However, the package seems to have more than one service:

 # dnf rq -l cockpit-ws | grep systemd

The firewall-cmd --get-services does show only one service named like “cockpit” – the one that is in zone “public” by default and that opens port 9090/tcp.

I’d guess that one can modify the config of cockpit to run HTTPS-server rather than HTTP-server – on port 9090 (for convenience). For HTTPS you want to set up certificates too.

Yes, the documentation does mention using HTTPS. It doesn’t explain how to set up certificates for cockpit though. Can I somehow use the same certs I have for the website’s SSL 443 port?

But if it is set up for an http connection by default, can I assume it’s safe to use that way?

Successfully set up Cockpit Web Console with Nginx server block for a subdomain, as shown here. Had problems with server block until I realized it needed to be as specific with ‘listen’ directive as other domain server blocks on the system, or it would be ignored. Once I added the complete ip (not just port), it worked fine.