Self-signed certificates will cause this, and locally-installed web services that run over https will always use self-signed certificates that are not part of any valid trust chain. It’s expected and normal, nothing to be concerned about.
Ah, OK, on localhost it doesn’t auto-redirect. On public interfaces, it absolutely does, and it will give the warning because of the self-signed certificate. I just tested that with a fresh install of Cockpit on TW, and that is the behavior.
That makes sense, I guess, since a localhost connection is not likely to be sniffed. But regardless, the warning message is due to the certificate being self-signed, and generally isn’t a concern under those circumstances.
One could always set up their own CA, put it in the trust chain, and then sign your own certificates - or get an external domain and get a real certificate, but for admin tools run on a local network only, that’s generally going to be overkill unless those services are exposed on the public Internet.
And the page at https://en.opensuse.org/Main:Cockpit (which they referenced) indicates that as the first of two options (the second is to use localhost).
Thanks for all the replies. I tried accessing cockpit by just typing in localhost:9090 and it worked without giving me that error.
I thought that, when the Cockpit page said “localhost”, I thought it meant the actual hostname on my computer (not the word “localhost”).
I realised I neglected to mention some information about this computer:
It is not public facing (or not intended to be). I have ssh disabled upon install and the firewall enabled with the default settings from the installer. I double checked this with:
The IP address is the one I took from Network Manager that it says is my computer’s IP address under IPv4. It’s the one I used then typed in :9090 after it.
I don’t intend to manage any other machines from this computer.
Given this, did I risk exposing myself to anything when I used the IP address from Network Manager to access cockpit?
I don’t know anything about networking so I try to keep very conservative and minimise what can communicate with my computer (I only need standard Internet access, but no ssh, no hosting anything, etc.).
I’ll have to search what sniffing means too in the sense of networking.
Nope, the firewall was blocked, but the IP address of your network interface is still accessible from the local machine.
For information about network sniffing, have a look at the information for a program called Wireshark. It’s a very good piece of software for that, and if you can find a good explainer, you’ll get a solid foundation in what it is and how it works.
Basically, though, any traffic from your machine to another machine on a network can be listened to (some networking devices) by a device sitting between the source and destination. Encryption with SSL/TLS certificate means the contents of the traffic can’t be read unless the certificate’s private key (which should be kept private) is used to decrypt it.
So using an SSL connection - even with a self-signed certificate - means that the username/password cannot be easily decrypted in transit using a tool like Wireshark - unless the attacker also has the private key for the certificate.
So even if the external port was open and someone would have been able to sniff the data on your network (meaning they were on your network and using a device that could actually listen in - an ethernet hub, a switch with specific functionality to allow it (sometimes called a “monitor” port or setting), or a wifi connection - the use of the certificate would have prevented them from being able to actually see your local username and password.
But I get the point.