23.1.9 WebGui "not secure"

[hydran]

Hi all,
Before anyone posts the obligatory "this has been answered, use the search function" response: there are numerous posts about this problem with previous versions.  The solutions are never clearly spelled out, and it is still a problem for me in 23.1.9
When logging into opensense via the webGUI, Chrome complains that the connection is "not secure".

It was the same in the previous versions that I have been using.  I just ignore the error and carry on, but it would be nice if it just had a proper certificate.
Is everyone else just living with this, or is there something in the setup that I can change to fix it?
One of the posts said I need a plugin to fix it!
Another said that I need to do a factory restore, which will hose my config presumably (and I really dont want to have to reconfigure this from the ground-up again).
Any constructive suggestions welcome  :)

[seed]

Please spend some time with the basics of TLS and certificates.

I dont like to type too much so thats what chatgpt will explain you:

The problem you're encountering with the "not secure" error in your web browser is likely due to a mismatch between the certificate's Common Name (CN) and the IP address of the website you're trying to access. Let me explain the issue and provide you with a possible solution.
The "not secure" error you're seeing in your web browser means that the website you're trying to visit doesn't have a proper security certificate. This could be because the website address you entered doesn't match the certificate's information. To fix this, make sure you type the correct website address in the browser's address bar, using the name of the website instead of numbers.

----------------
in other words. open the webinterface using the opnsense hostname and import the opnsense CA into your operating system.
The issue is NOT an opnsense problem!

[franco]

Off topic: While I don't doubt that AI will make a significant impact on humanity I can safely say that ChatGPT is like that one know-it-all colleague who mastered the art of bullshitting: just enough knowledge to convince the people who know even less and are afraid to admit it but still off the mark when you start questioning the answer. ;)

On topic: the default GUI certificate is private to your installation and also self-signed, which does not offer default trust. It's basically its own root certificate and that obviously cannot be included in a known root certificate bundle.


Cheers,
Franco

[meyergru]

To be even more specific and beyond "It cannot work like that" (which is correct), you basically have three choices:

1. Accept the self-signed certificate in your browser despite it being "not secure". Franco told you why this is so.

2. Address your OpnSense via a DynDNS name and create a Let's Encrypt or other official certificate whose CA is trusted in your browser. I do not know if a plugin for that exists, but you would need to expose the web GUI to the internet in order to do that. You could do it with HAproxy according to the tutorial give by TheHellSite, offering the advantage that you can re-use the opened port via different DNS names.

3. Create your own CA, sign the certificate for your internal DNS name and/or IP and import that certificate into OpnSense. Import your CA to your browser. That is the only way IMHO that you are able to remove "not secure" for a URL that references an IP.

[julsssark]

@meyergru nicely laid out the 3 options. I'd add that option #2 has many different flavors, not all of which require using DDNS and exposing your web GUI to the Internet. I prefer option #2 using the ACME plugin (LetsEncrypt), CloudFlare, and an API challenge, but it depends on the options your domain registrar provides. I also use the ACME plugin to generate certificates and copy them to other devices on my network that also use self-signed certificates (e.g., UniFi Network App, my NAS, etc.).

As I understand it, even though your browser says the connection is "not secure", it is still encrypted. It is just that accessing a device with a self-signed certificate is not secure because you can't be sure you are actually connecting to the device you think you are. If you are running in your home network, the easiest solution is to use option #1 and add the certificate as trusted on your local machine.

[meyergru]

You are technically correct in saying that you do not need to open your web interface all of the time, the ACME plugin can also take over the port just for the prolongation of certificates. However, the certificates can only be issued for "official" domains and thus, your web interface must be accessible via that name from the LAN side.

The alternative to NAT reflection and opening up the web interfaces would then be to have an internal DNS override for that domain.

Also, right on point w/r to "not secure" vs. "still encrypted". It is quite a leap for a browser to say accessing an RFC1918 IP via https is "not secure", where in most cases, it sure is. I went with #3, mainly because of that: I can even issue a certificate for '*', knowing that the devices that use my own CA are under my own control in my network.

Matter-of-fact, when you do https inspection in order to look at the content of your web traffic in your firewall, you have to do something like this anyway. However, I would advise to really understand what you are doing.

[julsssark]

Thanks @meyergru. I learned something new today.

[CJ]

You are technically correct in saying that you do not need to open your web interface all of the time, the ACME plugin can also take over the port just for the prolongation of certificates. However, the certificates can only be issued for "official" domains and thus, your web interface must be accessible via that name from the LAN side.

The alternative to NAT reflection and opening up the web interfaces would then be to have an internal DNS override for that domain.

You don't need to expose anything to the internet in order to get a certificate.  LE supports DNS challenges and that is also the only way to get a wildcard cert.  Whether the OPNSense ACME implementation supports that is another matter and one I haven't looked into.  But I have both an external and internal only setup getting LE certs through the DNS challenge.

I believe LE now supports a challenge on port 443 but as I use wildcard certs I haven't bothered looking into it.

Also, right on point w/r to "not secure" vs. "still encrypted". It is quite a leap for a browser to say accessing an RFC1918 IP via https is "not secure", where in most cases, it sure is. I went with #3, mainly because of that: I can even issue a certificate for '*', knowing that the devices that use my own CA are under my own control in my network.

Matter-of-fact, when you do https inspection in order to look at the content of your web traffic in your firewall, you have to do something like this anyway. However, I would advise to really understand what you are doing.

I think they went with Not Secure because the vast majority of internet users aren't doing anything with self signed certs and therefore coming across one is more likely an attempted MITM attack.  A lot of things are still holdovers from before things got a lot more magic and accessible to those less knowledgeable.