Status > System Logs, Settings tab. You can reset them all there.
You can reset them individually by clicking the wrench icon on each log tab to open the manage panel for a log and clicking reset there, but it's easier to reset them all.
Again why would you not just use the ACME package? Are you saying your pfsense has no access to internet?
Then why go through all this hassle - every 90 days. Why not just use your own CA, create a cert for 10 years and trust the CA?
Thanks - Not sure the login screen can be 'themed' other than the solid block of colour so it involved a certain amount of 'hacking' to achieve the consistency desired. The hardest bit is converting images to SVG, it was a lot easier in the old days as the images were all PNG's.
@gertjan said in Can TLSv1.1 be disabled?:
So, the PCI compliance test did a good thing : it detected a human - admin -error
Very Very true - but vs fixing the access from the lan they are editing source files.. Which will just revert on the next upgrade, and now 1.1 would be available again..
So yeah the fire the admin is prob a good suggestion ;) Problem is I think that is zonda in this case..
Where are you getting your cert from? Your going to have to give us more details if you want anyone to be able to figure out what your doing wrong.
For what possible reason would you want to use a wildcard cert for the webgui? How many possible fqdn/IPs could you point to the web gui?
The web gui should be accessed by limited number of users. Create as cert with your own ca, have the users that will access it trust your ca. Put in whatever SANs you want to access it by. Done - set the cert to be good for 10 years. Never have to deal with this issue again.
Okay I'm just being stupid. Apparently servers do not send the root certificate. The root certificate comes from the Certificate Store in Windows (which I have added the root certificate via group policy). However Firefox does not trust the Windows Certificate Store and maintains it's own. I needed to add the CA certificate manually into Firefox. Now it works.
@derelict said in Webgui Access Only by FQDN:
Yeah , but once it is connected i want page to be redirected or reloaded as https://pfsense.example.com. i have configured this behavior in my Linux web-servers running with Apache
Doesn't matter if there is a redirect. You will still get the certificate error when you initially connect because the certificate will not match the URL (IP address in this case.)
If you don't like the certificate errors going to https://192.168.1.1/ then don't go to 192.168.1.1, go to the FQDN instead.
Here, do this little experiment:
Click through and see where you end up.
I have now added IP address in certificate and able to access Thanks for your Help.
The pfSense community has been using Zanata to translate text strings and Azerbaijani is already set up as one of the translations. This would be by far the best way to translate and you might even win something.
If you really want to translate in a private environment, however, you can use the .po file here: /usr/local/share/locale/en_US/LC_MESSAGES/pfSense.po
Thanks Pippin, I was able to use the method you mentioned to revoke the cert and then kill the connection. I confirmed that works. I thought there might be a way to disable automatic reconnects. I guess even if it was possible, doing so could cause more harm than good since the connection could get lost in a normal use case and the user would want it to automatically reconnect.
This works fine in the ACME package:
Did you do something different?
Also, you can use the sudo package to grant other users rights to do things. It wouldn't be necessary for ACME, but for your own user it could help you out.
I think I found the problem. Silly me. I entered the command as /etc**.rc.restart_webgui instead of /etc/**rc.restart_webgui
I only realize it after I look into the screenshot.
A couple possibilities here, mostly due to XMLRPC sync.
It sounds to me like you did not import all of the certificates to the primary node. All certificates must be there, so that when you synchronize to the secondary, it also has all certificates. If you only import a cert to the secondary, it will be blown away when the primary synchronizes certificates. So at a minimum, you can solve it by importing the secondary's cert to the primary as well, and then picking it after it synchronizes over.
The easiest thing to do is have your certificate include names for your entire cluster, and use the same certificate on both. I like to have my HA certificates contain:
A SAN for the primary hostname
A SAN for the secondary hostname
A SAN for the CARP VIP hostname(s)
After the primary has performed a configuration sync to the secondary, then go into the secondary's Admin options and pick the correct certificate. Otherwise it may have an incorrect cert reference.
Yes, that is the correct function. If you keep the original file and then make a diff/patch from that to apply your changes, you can use the system patches package to maintain your alterations rather than redoing them after every update.
Understandable. I know this is a low priority, so I wrote teh code myself.
I've submitted a feature request https://redmine.pfsense.org/issues/8418
I've submitted a pull request https://github.com/pfsense/pfsense/pull/3927
O.K. I tried setting both memory limits to 1024M and rebooting. Unfortunately I still get the same PHP error Allowed memory size of 134217728 bytes exhausted on the pfBlockerNG Alerts page. Since PHP is obviously configured for more "Allowed" memory than this, does anyone know where this limit is coming from?
Alright! It is officially confirmed that Suricata inline mode was causing this. I recently had to switch back to Legacy mode due to another odd issue which was impacting my day-to-day. I found it impossible to manage false positives that were not showing up highlighted in the alerts log. How to you create an exception to a blocked IP which you can't even see? Maybe I was doing something wrong? In any case, I switched back to legacy mode with all the same categories and rules selected. Now the legitimate site that was blocked before is not blocked and my WAN out graph is working too. Magic! In the meantime, I'm staying away from inline mode until I grow enough courage to give it another try. I'm pretty sure it's likely a netmap issue. At one point, I couldn't even get Suricata to restart because of some netmap error. I know netmap is not a pfSense or Suricata issue in particular. I believe that's a FreeBSD thing and/or netmap being too young.
The issue has been solved by updating system time manually (was 1 hour ahead of correct time).
Now, all traphic graphs are working fine and they start rendering immediately when opening the dashboard.
Are you saying that the time is off by 1 hour?
That is just showing you when it last checked. What does it show for system time exactly?
Pfsense shows right on the button for me, and it just refreshed checking.. Daylight savings runs from Mar 11 to Nov 4 in US, after Nov 4 it will be standard time or PST in your case or CST in my case. Shows correct for CDT and PDT March 19 as stated already by gjaltemba
One more question: I noticed something about a new Acme API that was rolled out. Is that something I should go do? Does that work on the existing version of pfSense (2.4.2-RELEASE-p1), or would I need to install some sort of update to get that?
When a package update comes out, like 0.2.5 for acme yesterday, you should upgrade.
This newer version includes the possibility to obtain wildcard certs from Let's Encryopt - if you need them. See ACMEv2 is live!
….and even internet works... kind of.
Oh. Let me guess … the quad-8 problem ?
Anyway, glad things worked out.
Never heard… this https://forum.pfsense.org/index.php?topic=145038.0
Thanks, closing this as solved.