SSL Certificate
-
You need to import the CA that created that cert, not the cert.. And what is the common name on that cert? How are you accessing the pfsense gui via name or IP?
What does it matter why would you not just create a new CA and new Cert and be sure of the info, etc. It really only takes like 2 minutes tops.
-
I believe a cert itself can be imported into the store and will work. But yes, the site would have to be accessed via a matching CN/SAN of the cert.
-
You need to import the CA that created that cert, not the cert.. And what is the common name on that cert? How are you accessing the pfsense gui via name or IP?
What does it matter why would you not just create a new CA and new Cert and be sure of the info, etc. It really only takes like 2 minutes tops.
The cert was created automatically when I installed pfsense. I have no reason to not create a new CA and cert, aside from the perhaps naive assumption that since pfsense created the cert, it must have done so for a reason (i.e., to be used). I posted because I figured I must be doing something wrong.
I was accessing pfsense using the ip address and your comment made me wonder if that was the problem. I tried using the name and that didn't work either.
I've attached a screen capture of the cert and the error, with the cert installed in the trusted root store, which is where chrome said it was supposed to be installed.
-
The reason for the default cert is so that the webGUI connection can be encrypted. Does not mean it is trusted though. It's like creating a self signed cert, in fact it is a self signed cert is it not, it will not be trusted by the browser unless imported to the store and the site accessed via a matching CN/SAN.
-
The reason for the default cert is so that the webGUI connection can be encrypted. Does not mean it is trusted though. It's like creating a self signed cert, in fact it is a self signed cert is it not, it will not be trusted by the browser unless imported to the store and the site accessed via a matching CN/SAN.
I imported this cert into the trusted root store and attempted to access webgui. It didn't make any difference, as noted above. Either I'm doing something wrong or there is something wrong with the cert. I'm inclined to suspect the former. I just don't know what I'm doing wrong, which is why I posted.
-
What is the URL being used in the browser?
What is the CN of the cert?They have to match.
-
What part do you not understand about that error? Says your authority chain is BROKEN ie CA (certificate authority not valid).. You need to trust the CA.. But even if you do.. You sure and the hell are not accessing pfsense via that CN now are you..
So again if you want to have a trusted cert, ie pretty green padlock then create a cert with a valid CN or SAN that you will use to access pfsense with.. Looks your fqdn of pfsense is pfsense.localdomain.. Ie if you ping pfsense.localdomain does it resolve to your pfsense IP address in your lan. Then you can use that in your browser. Once your CN is the same, your cert currently has a CN of (see attached) pfsesnse-57d49515f1288 do you think that resolves to pfsense IP? And you can put that in your browser to access pfsense?
So even if you trusted anything signed by that CA, it would still fail since your not using the CN to access the site - that is how https works.
So create a server cert from a CA in pfsense, either the one that is currently there or create a new one. Download the CA, import that into your trusted root CA store.. Access site via CN on the cert or via the SAN you added to the cert.. There you go shiny green padlock. 30 seconds of time. Now that you trust that CA you could use that CA to create other certs for use in other devices or applications that you use https for, I use for example one for my sg300 cisco switches web gui (3rd attached image)
-
What part do you not understand about that error? Says your authority chain is BROKEN ie CA (certificate authority not valid).. You need to trust the CA.. But even if you do.. You sure and the hell are not accessing pfsense via that CN now are you..
So again if you want to have a trusted cert, ie pretty green padlock then create a cert with a valid CN or SAN that you will use to access pfsense with.. Looks your fqdn of pfsense is pfsense.localdomain.. Ie if you ping pfsense.localdomain does it resolve to your pfsense IP address in your lan. Then you can use that in your browser. Once your CN is the same, your cert currently has a CN of (see attached) pfsesnse-57d49515f1288 do you think that resolves to pfsense IP? And you can put that in your browser to access pfsense?
So even if you trusted anything signed by that CA, it would still fail since your not using the CN to access the site - that is how https works.
So create a server cert from a CA in pfsense, either the one that is currently there or create a new one. Download the CA, import that into your trusted root CA store.. Access site via CN on the cert or via the SAN you added to the cert.. There you go shiny green padlock. 30 seconds of time. Now that you trust that CA you could use that CA to create other certs for use in other devices or applications that you use https for, I use for example one for my sg300 cisco switches web gui (3rd attached image)
Why the sarcasm? Obviously I know there is a problem. If I knew what was causing the problem, I wouldn't be here asking for help! Anyway, I created a CA and a certificate and the problem is fixed. Thank you for the help.
I'm still not clear why the "webConfigurator default" certificate is created by pfsense in the first place, because it's apparently useless due to the CN. Does it have a purpose? If so, what?
-
What part do you not understand about that error? Says your authority chain is BROKEN ie CA (certificate authority not valid).. You need to trust the CA.. But even if you do.. You sure and the hell are not accessing pfsense via that CN now are you..
So again if you want to have a trusted cert, ie pretty green padlock then create a cert with a valid CN or SAN that you will use to access pfsense with.. Looks your fqdn of pfsense is pfsense.localdomain.. Ie if you ping pfsense.localdomain does it resolve to your pfsense IP address in your lan. Then you can use that in your browser. Once your CN is the same, your cert currently has a CN of (see attached) pfsesnse-57d49515f1288 do you think that resolves to pfsense IP? And you can put that in your browser to access pfsense?
So even if you trusted anything signed by that CA, it would still fail since your not using the CN to access the site - that is how https works.
So create a server cert from a CA in pfsense, either the one that is currently there or create a new one. Download the CA, import that into your trusted root CA store.. Access site via CN on the cert or via the SAN you added to the cert.. There you go shiny green padlock. 30 seconds of time. Now that you trust that CA you could use that CA to create other certs for use in other devices or applications that you use https for, I use for example one for my sg300 cisco switches web gui (3rd attached image)
Why the sarcasm? Obviously I know there is a problem. If I knew what was causing the problem, I wouldn't be here asking for help! Anyway, I created a CA and a certificate and the problem is fixed. Thank you for the help.
I'm still not clear why the "webConfigurator default" certificate is created by pfsense in the first place, because it's apparently useless due to the CN. Does it have a purpose? If so, what?
There has to be a server certificate in order to do TLS/SSL connections in the first place, without the self-signed certificate you could only do plain unencrypted HTTP connections to the WebGUI on a newly installed pfSense system. This is just how TLS/SSL works, pfSense can not change that.
It would be of course terribly nice if pfSense could automatically create a trusted server certificate on install but you don't have to be rocket scientist to realize what that would mean for the trustworthiness of the whole certificate system and the trust network.
-
@kpa:
There has to be a server certificate in order to do TLS/SSL connections in the first place, without the self-signed certificate you could only do plain unencrypted HTTP connections to the WebGUI on a newly installed pfSense system. This is just how TLS/SSL works, pfSense can not change that.
It would be of course terribly nice if pfSense could automatically create a trusted server certificate on install but you don't have to be rocket scientist to realize what that would mean for the trustworthiness of the whole certificate system and the trust network.
I reverted to the webConfigurator default certificate and I can see that the connection is still using TLS, so I get your point.
As for pfSense creating the CA, I suppose you would have accept the trustworthiness, but it's still a self-signed certificate generated by pfSense, so there already is an element of trust involved.
-
My main point is that nobody should be expected to accept self-signed certificates under normal conditions, browsers are free to complain about them as they wish. The only reason you should be accepting the self-signed certificate when you connect to your pfSense system is that you know damn well that the system you're connecting to is really the pfSense system you have installed yourself.
Another one is that there's nothing between trust levels "Unknown CA" and "Trusted CA", there is no easy way around the initial trust problem that manifests as the error you see in your browser. You have to at least once accept the untrusted certificate to get past it to be able to continue configuring your newly installed pfSense system.
-
"Obviously I know there is a problem. "
But unable to understand the error that your CA is invalid? This is the frustration part for me, multiple posts telling you how to fix it already and still not getting it. Not that there was an error in the cert, the errors specifically states that the CA is invalid.
First reply, first line of my post
"By importing the CA of your cert into the store and accessing pfsense by a correct fqdn that is the common name on the cert or by the IP address you put in the cert as a SAN.."This is when the thread should of been over ;) Even gave pretty pictures and everything..
If you want to debate or discuss why pfsense issues a selfsigned cert without a valid fqdn (cn) that would be good discussion. But multiple posts stating you need to trust the CA and use a valid CN or SAN to access the site with did not seem to be clicking.. There was no sarcasm in my posts, I honestly have no idea why it was not clicking with you when the answer was given to you in reply 1..
You access the web gui very early in the process of setting up pfsense. Guess they could ask for a fqdn before the webgui portion and offer up link to download the CA before you even hit the webgui. Put in a feature request on redmine. But its pretty common practice on anything that has a web interface and allows for https to use a self signed, that is going to give you errors. Since your the one setting up the device seems logical you would accept these errors until you have time to correctly setup the https to not give you errors, etc.
