NET::ERR_CERT_INVALID in Chrome based browsers but NOT Firefox

paulparisi

When connecting to the WebConfigurator UI on several pfSense+ firewalls with Microsoft Edge I get an error:

Attackers might be trying to steal your information from 10.11.12.253 (for 
example, passwords, messages, or credit cards).

NET::ERR_CERT_INVALID
RefreshHide advanced

10.11.12.253 uses encryption to protect your information. When Microsoft Edge
tried to connect to 10.11.12.253 this time, the website sent back unusual and
incorrect credentials. This may happen when an attacker is trying to pretend to
10.11.12.253, or a Wi-Fi sign-in screen has interrupted the connection. Your
information is still secure because Microsoft Edge stopped the connection before
any data was exchanged.

You can't visit 10.11.12.253 right now because the website sent scrambled
credentials that Microsoft Edge can't process. Network errors and attacks are
usually temporary, so this page will probably work later.

I have tried to “Disable HTTP Strict Transport Security” but the error still occurs. I have tried Chrome, Opera, Vivaldi and Flow with the same failure.

Firefox is able to load the page as long as I accept the self-signed cert.

Anyone have any hints on how to get this working for Edge?

Thanks in advance!
Paul.

DaddyGo

@paulparisi said in NET::ERR_CERT_INVALID in Chrome based browsers but NOT Firefox:

Anyone have any hints on how to get this working for Edge?

Hi,

I would never and will never recommend using MS browsers (IE / Edge / Chromium Edge - all the same beast and sorry) to configure a network device(s) - on web interface.
(except for very old NVR, DVR and webcam settings, which are IE dependent)

There are many reasons for this, but this is one of the most important:
https://docs.microsoft.com/en-us/lifecycle/faq/internet-explorer-microsoft-edge

In principle, this is not very encouraging :-).

I would definitely check my windows + browsers configuration first, because this might be an https issue

until you not solve this, you don't have to think about HSTS problems
(https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security)

on spot: https://docs.netgate.com/pfsense/en/latest/config/advanced-admin.html

BTW:

even if you are inside your own network, pls. always try to connect to the box with https and tell your system that this certificate is secure

+++edit:

as I have done before, I recommend configuring sensitive devices using a dedicated web browser
(do not use this browser to access the web)

tastes and slaps, but it can be a good guide:

https://www.expressvpn.com/blog/best-browsers-for-privacy/

paulparisi

@daddygo Thanks for the helpful note. But, sorry this did not answer the question.

I was not asking about which browser to use.

As I said, all Chromium browsers do not work. It is not acceptable to have the worlds most used browsers unable to manage pfSense.

jimp

That isn't a general issue as Chrome has no problem connecting to anything I've tried here, self-signed or not.

There is likely a problem with your GUI certificates. First, make sure you are on a current version of pfSense, and then run the following from the console or SSH shell (not the GUI):

pfSsh.php playback generateguicert

That will make a fresh certificate with the latest known attributes browsers want. Some browsers will reject older server certificates if they fail certain criteria like weak security, reused serial numbers, or validity times that are too long, among others.

paulparisi

@jimp said in NET::ERR_CERT_INVALID in Chrome based browsers but NOT Firefox:

pfSsh.php playback generateguicert

Thank you - that did the trick! Very helpful! Thank you!

One related question - I realized by failure that Unbound DNS uses a Cert which I had deleted because in the Certificate Manager | Certificates it was listed as unused. I deleted it and DNS stopped. But, alas it could not start because I deleted its cert. Should I have generated a dedicated cert for Unbound DNS?

If the cert is in use by DNS (or others) it should say so in Certificates, no?

jimp

@paulparisi said in NET::ERR_CERT_INVALID in Chrome based browsers but NOT Firefox:

One related question - I realized by failure that Unbound DNS uses a Cert which I had deleted because in the Certificate Manager | Certificates it was listed as unused. I deleted it and DNS stopped. But, alas it could not start because I deleted its cert. Should I have generated a dedicated cert for Unbound DNS?
If the cert is in use by DNS (or others) it should say so in Certificates, no?

If you are acting as a DNS over TLS server for clients, then you generally want a cert there. It can be the GUI cert in most cases.

Personally, I have Let's Encrypt setup on mine so it's a real/valid cert I use for the GUI, Unbound, and so on.

If you were running pfSense 2.5.2 the cert should have been marked as used by Unbound. Earlier versions didn't list that. See https://redmine.pfsense.org/issues/11678

DaddyGo

@paulparisi said in NET::ERR_CERT_INVALID in Chrome based browsers but NOT Firefox:

But, sorry this did not answer the question.

Hello,

but I replied and yes this has been confirmed by others below (now it's on top)... :)
-just worded differently.... like by Jimp

paulparisi

@jimp Thank you again!

This is/was on 21.05 -- the cert was deleteable.

How do you get a Lets Encrypt cert working on the inside of the network for the GUI and DNS, etc.

paulparisi

@daddygo Are you Benoit? I met him years ago.

DaddyGo

@paulparisi said in NET::ERR_CERT_INVALID in Chrome based browsers but NOT Firefox:

Are you Benoit? I met him years ago.

no I'm an old hippie from somewhere around 1970 - 75

my favourite subject is maths and I teach it in a couple of places :)

yes and shock the people and then do a study on it
if you search for me on the internet you can see many of my serious theses

if you do not see, ask for my guidance - I have the beard of like R.Stallman :), hahahaha

+++edit:

sorry lately Stallman is not a good guy

paulparisi

So can anyone help with this - it is buried above...

How do you get a Lets Encrypt cert working on the inside of the network for the GUI and DNS, etc.

Gertjan

@paulparisi

No need to install and set up the acme.sh pfSense package.

To use the acme package you need to have a 'real' domain name, one you have to rent from some registrar.
You need to be sure that you can use one of the API's proposed by the acme package that can handle the updates with your registrat.
With little words : there is a learning curve involved here.

Just create 'some ' self generated cert - I use the one that I also use for my OpenVPN server, and have that listed for Unbound, the resolver, also :

Note : "Unbound" isn't actually using the cert right now, because I have not checked "Enable SSL/TLS Service" :

Now, I check "Enable SSL/TLS Service" and save + Apply :

And now the cert is marked as used by unbound :

I guess I couldn't delete it, as it is used by OpenVPN server AND unbound.

paulparisi

@gertjan Ah - this may be a bug...

If you have Enable SSL/TLS Service unchecked and have an SSL/TLS Certificate specified.

You are able to delete that cert, which is fine.

However, in this state - DNS will not start.

Gertjan

@paulparisi said in NET::ERR_CERT_INVALID in Chrome based browsers but NOT Firefox:

@gertjan Ah - this may be a bug...

If you have Enable SSL/TLS Service unchecked and have an SSL/TLS Certificate specified.

You are able to delete that cert, which is fine.

However, in this state - DNS will not start.

I played a bit with the situation.
This is the initial configuration :

The cert "ca-server-openvpn" was never selected by me, it's referenced in my cert list as the first certificate. Like this :

I have to presume that the cert listed on this Services > DNS Resolver General Settings page is just the first one available and usable.

Whhe you Save + Apply, this cert is taken from the pfSense cert storage, and copied by file into the /var/unbound/ folder.
This happens even when these two files are actually NOT used by unbound :
This part :

# TLS Configuration
tls-cert-bundle: "/etc/ssl/cert.pem"
tls-port: 853
tls-service-pem: "/var/unbound/sslcert.crt"
tls-service-key: "/var/unbound/sslcert.key"

will not be present in /var/unbound/unbound.conf if "Enable SSL/TLS Service" is not checked.
This means that unbound can stop start without issues.

It is now ok to delete the referenced cert - in my case "ca-server-openvpn" listed on the System > Certificate Manager > Certificates page.
If I deleted that cert (presume that it was not used elsewhere), and I open the Services > DNS Resolver General Settings page again, it would just how the next available + usable cert.

When I delete the /var/unbound/sslcert.crt (and key file) manually, and "Enable SSL/TLS Service" is not checked, the the /var/unbound/sslcert.crt (and key file) will not get regenerated.

The the /var/unbound/sslcert.crt (and key file) will only get regenerated when I check the "Enable SSL/TLS Service" and do an unbound Save + Apply.

If the cert didn't exist at that moment, and error will get shown.
I wasn't able to create such a situation, as as soon as I open the Services > DNS Resolver General Settings page, an existing (and present and usable) cert will get shown.
After selecting "Enable SSL/TLS Service" a save + apply will prepare the files /var/unbound/sslcert.crt (and key file) AND I would not be able to remove that cert now.

@paulparisi said in NET::ERR_CERT_INVALID in Chrome based browsers but NOT Firefox:

However, in this state - DNS will not start.

My DNS resolver is never in the stopped state.
If it started ones, because I changed settings using the GUI, it did so after a Save + Apply.
This action can change (== preapte !) the cert info, which are the /var/unbound/sslcert.crt (and key file).
unboud can now restart as much as it wants (and some of do so every minute or more) : it will be able to restart as it's settings are still ok.
Even, if for some reason, the used cert was deleted in on the System Certificate Manager Certificates page.

Maybe I'm missing something. can't tell. It's your turn to play with it and proof me wrong ;)

paulparisi

@gertjan ok -thanks, I will see if I can reproduce it.

Here is what happened as best I can remember. Unbound DNS was working just fine. Our webConfigurator cert expired and I thought that was causing my inability to load the GUI in Chrome. So I manually created a new cert and applied that to WC.

Then, looking at the list of certs it said the original WC cert was not user (I did not have SSL enabled on DNS). So I deleted the original WC cert.

My Chrome GUI issue was not solved. So, I said lets try another day.

10 minutes later I get a call from the client that they cannot browse. After some testing, we noticed that the DNS service was not running. Tried to manually start it. Looked at the logs and noticed a certificate error.

/status_services.php: The command '/usr/local/sbin/unbound -c /var/unbound/unbound.conf' returned exit code '1', the output was '[1627508025] unbound[64353:0] error: error for cert file: /var/unbound/sslcert.crt [1627508025] unbound[64353:0] error: error in SSL_CTX use_certificate_chain_file crypto error:0909006C:PEM routines:get_name:no start line [1627508025] unbound[64353:0] error: and additionally crypto error:140DC009:SSL routines:use_certificate_chain_file:PEM lib [1627508025] unbound[64353:0] fatal error: could not set up listen SSL_CTX'

Once I picked the new WC GUI cert DNS was able to start.

Later, I learned of the above,

pfSsh.php playback generateguicert

and that fixed the ability to access the GUI using Chrome.

Gertjan

@paulparisi said in NET::ERR_CERT_INVALID in Chrome based browsers but NOT Firefox:

Unbound DNS was working just fine

With "Enable SSL/TLS Service" activated ? And if so, with what "SSL/TLS Certificate" selected ?

@paulparisi said in NET::ERR_CERT_INVALID in Chrome based browsers but NOT Firefox:

Our webConfigurator cert expired and I thought that was causing my inability to load the GUI in Chrome.

I deleted that "webConfigurator cert" years ago. wasn't that cert valid for 10 years or so ?
=> Be careful : if you manage to break 'NTP' and the date/time of pfSense isn't correct, most cert operations will fail.
I'm using a cert for the GUI that is regenerated by the acme package every 60 days.
My DNS Resolver doesn't use TLS facilities on the local LAN's as I don't think that some one is tapping into my wiring.
I'm certainly not forwarding over TLS neither as that does breaks DNSSEC.
My unbound resolver usage is pretty close to how it was installed by default.

@paulparisi said in NET::ERR_CERT_INVALID in Chrome based browsers but NOT Firefox:

So I manually created a new cert and applied that to WC.

Hummm.
Manually ?

@paulparisi said in NET::ERR_CERT_INVALID in Chrome based browsers but NOT Firefox:

10 minutes later I get a call from the client that they cannot browse. After some testing, we noticed that the DNS service was not running. Tried to manually start it. Looked at the logs and noticed a certificate error.
.
/status_services.php: The command '/usr/local/sbin/unbound -c /var/unbound/unbound.conf' returned exit code '1', the output was '[1627508025] unbound[64353:0] error: error for cert file: /var/unbound/sslcert.crt [1627508025] unbound[64353:0] error: error in SSL_CTX use_certificate_chain_file crypto error:0909006C:PEM routines:get_name:no start line [1627508025] unbound[64353:0] error: and additionally crypto error:140DC009:SSL routines:use_certificate_chain_file:PEM lib [1627508025] unbound[64353:0] fatal error: could not set up listen SSL_CTX'

Aha : You restarted the resolver using the Status > Services page ?
Or, not the same case : it was stopped ? And you had to start it again ?

I imaging this :
When you the Services > DNS Resolver > General Settings page, it will list here :

as cert that is available and usable.
If, by any chance, the cert that is used "right now" doesn't exist any more, like the "webConfigurator cert" that was removed, and recreated some moments before, then that is no issue.
Remember : when you set unbound settings with the Services > DNS Resolver > General Settings page, the files /var/unbound/sslcert.crt and /var/unbound/sslcert.key are created from a cert listed here :

exists.

What I presume :
When you start or restart unbound using the the Status > Services page page, the main config file /var/unbound/unbound.conf is recreated.
Using the stored unbound settings.
The issue is : the cert info that has been stored in the unbound config is still 'pointing' to a cert that doesn't exist any more (you deleted it).

Now, the error message

/status_services.php: The command '/usr/local/sbin/unbound -c /var/unbound/unbound.conf' returned exit code '1', the output was '[1627508025] unbound[64353:0] error: error for cert file: /var/unbound/sslcert.crt [1627508025] unbound[64353:0] error: error in SSL_CTX use_certificate_chain_file crypto error:0909006C:PEM routines:get_name:no start line [1627508025] unbound[64353:0] error: and additionally crypto error:140DC009:SSL routines:use_certificate_chain_file:PEM lib [1627508025] unbound[64353:0] fatal error: could not set up listen SSL_CTX'

is explained.

Full test :

I created a cert called "TEST unbound cert" and started to use it :

and Save + Apply.

Now, unbound uses this cert.
Internally, in the config, this cert is - for me - referenced as :

		<sslcertref>6104f251f0f57</sslcertref>

It's the 'internal name' of the cert.

Now, on the System Certificate > Manager > Certificates page, this cert is marked as in use by "DNS Resolver". You couldn't delete
But I guess that alternative ways to delete this "6104f251f0f57" cert (command line ?) will not update the 'unbound' config, so, when unbound restarts, it will try to copy/use a cert (in this case "6104f251f0f57") that doesn't exists any more.

How did you regenerated the cert (that was used for unbound) if you were not using

pfSsh.php playback generateguicert

?

paulparisi

@gertjan

I manually deleted the cert by clicking on the trash can icon.

I did not know about pfSsh.php so I create a new cert in certificates and assigned that in DNS.

I think the bottom line is I had picked a, now deleted cert in the DNS drop down, which cause the DNS service not to be able to start even though DNS SSL was unchecked. It must, since the cert was specified, check if it exists and since it no longer existed it would not start.