fixed! that was fast  ;D

Let's Encrypt certificates are only ever valid for 90 days. The field in the GUI controls how long it will wait to force a renewal, usually it's at 60 days IIRC but you can turn that down. You can't effectively go over 90 since that would mean it never renews.

Looks like upgrading to 0.2.7 fixed the timeout. It works flawlessly now.

The code is fine, it works for me and hundreds, maybe thousands, of others.

Something is wrong in your settings or with your DNS provider.

Just got the new build this morning. We are back in business. It works. Just have to test the nsupdate now.  Thanks 8)

Update to the most recent version of the ACME package, 0.2.6, and try again.

If you do not see that update available, then update pfSense to the most current version first.

;D
That "someone" was me : a certificate for the portal.(mydomane.tld) and another certificate for pfsense.(mydomane.tld) hosted on another NIC.
True, I could have combined these two into one certificate.

These days I simplified maintenance, and I use a (one) wildcard cert.

Btw : not related to acme :
Restarting the GUI is completely harmless - I'm the only "user" anyway.
Restarting the portal does have an impact as explained above.

Hey,

i found some interesting stuff applying some echo lines on datetimes:

Let's encrypt generated certificate is always 90 days valid

pfsense WebUI "Services/Acme/Certificate options/Certificate renewal after" option does not affect certificate lifetime generated by Let's encrypt. It does affect acme_command.sh;

Even a 1 day certificate is valid for 90 days but the option set "Certificate renewal after" correctly set the end date checked by acme_command.sh. So i trust that it could do a good job within 90 days time frame. Any value grater than 90 would let you drop in an unmanged time frame where your certificate is outdated but the script things "Renewal number of days not yet reached".

I would suggest a bug fix in pfsense UI to discard bad values set up in certificate edit page and help users.

Also

You should consider the second gap: since cron job run once a day, you may run the job just 1 hour before a certificate may ends, then you have to wait next job 24 later to get an updated certificate; in the case a webserver's certificate you can get users warned by browser security features for 23/24 hours.

We will plan to examine better the code and patch it with such as a provision feature to issue a new certificate if it will be replaced soon

Easy as we speak

just adding the following line in acme.inc it is possible to renew certificates on the edge of 24 hours

$nextrenewalex = $nextrenewal->sub(new \DateInterval('PT24H'));

in the function issue_certificate right after:

$nextrenewal = $lastrenewal->add(new \DateInterval('P'.$renewafterdays.'D'));

With this patch cron job would be more efficent while renewing certificates giving no downtime of services where certificates are applied to

I'm using webroot ftp….tried to upload using SFTP worked.....I can reach the acme challenge via http....

The challenge is stored and generated correctly.

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.