NET::ERR_CERT_INVALID in Chrome based browsers but NOT Firefox
-
@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 -
@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.
-
@daddygo Are you Benoit? I met him years ago.
-
@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 thesesif 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
-
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.
-
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.
-
@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.
-
@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 ;)
-
@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.
-
@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
?
-
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.