Yes. It requires a real, valid domain name. And using webroot or standalone mode on pfSense requires that the domain name point to your WAN IP address and that your firewall expose port 80 and/or 443 (depending on the mode) to the world, which is not good.

Get a real domain name, pick one of the providers that offers a DNS update method supported by the ACME package (there is a list in the certificate options), and then use that to update. You don't have to publicly expose anything on your firewall for DNS updates.

problem solved

You can locate the in the acme_issuecert.log

[Wed Feb 28 18:46:02 CET 2018] consumerKey='[hidden](please add '--output-insecure' to see this value)' [Wed Feb 28 18:46:02 CET 2018] APP [Wed Feb 28 18:46:02 CET 2018] 6:OVH_CK='XXXXXXXXXXXXXXXXXXX'

@breakaway:

As in thread title 2.4.2_1 installed today with latest version of ACME package.

I have it 99% working - I got it integrated with my Route53 account so it can use TXT records to generate certificates but I am finding that the certificate gets acquired, shows up in the list of certificate list but isn't actually enabled (i.e. webconfigurator default is still enabled).

I have to manually update it to use the LE cert. Did I configure this wrong or is this the expected behaviour?

Or - is this the expected behaviour? I.e. I set the "certificate name", then this certificate gets generated then subsequent times the certificate is generated, the same certificate will get updated and therefore everything will roll over smoothly?

Once you generate the cert for the first time, goto "System / Advanced / Admin Access" and set the "SSL Certificate" to whatever you generated.

What you will also need to do is in the ACME "Edit Certificate options" section for that cert is make sure you add an "Action" to restart the WebGUI when its renewed. Like in the attached Picture.

Capture.PNG
Capture.PNG_thumb

Sigh.  :-[  Thank you for your patience Jim.

–jason

Hello matthijs,

I am almost sure I find your solution (I needed it too).

Here is my idea :

run the function which is called when someone presses the 'save button' on 'reverse proxy' GUI page, but run it from the command line. and then, restart squid.

And here are commands I came up with:

using php, include 'squid.inc' and 'squid_reverse.inc' file, launch 'squid_resync_reverse' function

php -r "require_once('/usr/local/pkg/squid.inc'); require_once('/usr/local/pkg/squid_reverse.inc'); squid_resync_reverse();"

using basic command line, restart squid

/usr/local/etc/rc.d/squid.sh restart

It worked for me once, while pressing 'Issue / Renwe' button. I know need to wait for xx days to see if it does it automatically too (but it should).

Hope it will help you (and others ;-) ).

They just added it after tagging 2.7.6 so it didn't make it into their newest release. We'll pull it in soonish though.

@-flo-:

Gertjan, can you elaborate on how you set this up?

Never did so myself.
"DNS-Manual" means that you have to go through the same procedure every 90 days or less.

You need a domain name, and you need to have access to "zone information" of this domain name. I guess every registrar gives you this kind of access when you rent a domain name.
So, it's rather easy to set a TXT record with the key info letsencrypt gave you when asking for a certificate or renewing a certificate.
When you add this key, probably using the GUI used by the registrar to administer your domain name, know that you have to wait several minutes or even more, because the zone info has to be synced among at least one other name server that 'hosts' you domain name.
Only when that has been done, you can proceed with the acme interface (pfSense) to ask for a (re) new certificate.

I'm using my own dedicated server, and I'm using my own DNS master server that hosts my domain name (actually more then 10).
acme used by pfSEnse has been set up to "talk" to my DNS server, so it can add these TXT records itself in the zone file (the file with all the info related to a domain name).
This is the so called "nsupdate" method, and is fully automated.

@B-C:

like 8443 - I can create the LE cert for one of these VMs, just not clear on how the VM gets the cert installed to use?
using a Service Desk Plus specifically running on debian.

There is no such thing as a buildin script that copies a certificate (certificate files, or the whole bunch in a 'chained' file) from one device, pfSense, to another device, your server.
The files have to get moved over, the service - the web server - has to be restarted.
It is possible of course, but for your setup you need your script.

When I renew my certificate for my pfsense (pfsense.mynetwork.tld) I also renew for diskstation.mynetwork.tld, printer1.mynetwork.tld printer2.mynetwork.tld, etc. I have to copies the needed  files over to the diskstation, printer1, printer2 etc - most of them do not even have a telnet or ssh access, so scripting is impossible.

Best is to run some letsenscrypt support from these devices, if it is possible.

Thank you, this seems to have done the trick. A little bit of extra work because manual DNS is a pita and the local http server can't bind to port 80 becauase of local running ngix - hence a port forwarding is necessary. Also I didn't think of this thread you've mentioned because some renewals still worked with tls, some others didn't so this made it harder for me to specify an exact error scheme.

Julian

Should that URL be open to the world? I can't reach it on port 80 over IPv4 or IPv6 right now. Perhaps the validation servers at Let's Encrypt also can't reach it?

Since it's a timeout, I would focus on firewall rules or other access rules, maybe even routing upstream, anything that could prevent LE from reaching your web server on port 80. Maybe you have something like pfBlocker filtering access or geoblocking?

Of course this isn't a general discussion thread, my mistake .

Ahh, bummer. Thanks!

Done, thanks: https://redmine.pfsense.org/issues/8211

COMPLETED… TY PiBa