Let's Encypt support

ViniciusBr

1- You must manually renew it by repeating the process and editing the text record with a new value every 60-90 day (I suggest closer to 60)
2- To use the certificate for the GUI you must select it under System > Advanced on the Admin Access tab. Pick the Let's Encrypt certificate you made there.
3- It cannot renew automatically when you use the DNS-manual method. You will have to perform the renew/update txt/renew process every 60-90 days.

That's why the automated DNS methods are so important, it can be 100% automated to where you do not have to think about it much again.

Thanks for your fast reply.

for your answers:

1- I renewed it manually and I didn't change the txt contents, seems that ACME used the previous one. Was it lucky or the txt record will be the same forever?

2- As I mentioned before, when I clicked RENEW it renewed successfully and the certificate used by webconfigurator was automatically updated to the new one, the last one was no longer present there. When I followed your instructions (System > Advanced on the Admin Access tab. Pick the Let's Encrypt certificate you made there) the assigned certificate is already the one I renewed, but when I access the web gui I am still using the old one.

3- If the txt record does not change, why it would not work? there's an automatic process, right? What would fail then?

One update: I ssh into pfsense, chose option 11 (restart WebConfigurator) and voila! the certificate came into production. Is it a bug? Or it would take some time to update automatically?

Thanks in advance for your time!

jimp

The authz value and so on are valid for a few days (currently 7 I think, but I might be wrong). It's only the same because you did it so soon. Try it again in a month.

ViniciusBr

@jimp:

The authz value and so on are valid for a few days (currently 7 I think, but I might be wrong). It's only the same because you did it so soon. Try it again in a month.

Thanks.

Can you check my update I posted?

"One update: I ssh into pfsense, chose option 11 (restart WebConfigurator) and voila! the certificate came into production. Is it a bug? Or it would take some time to update automatically? "

jimp

If you chose the certificate before it was complete, it wouldn't have been used since it was invalid. Refreshing that might have made it pick up the cert once it was complete.

Usually once you choose a valid cert on System > Advanced, it will be activated once you save the settings.

The ACME package does need to restart the GUI after renewing a certificate on future runs, which it can do by defining a command in the certificate entry. There is an example on the page already that tells you what command to run.

ViniciusBr

@jimp:

If you chose the certificate before it was complete, it wouldn't have been used since it was invalid. Refreshing that might have made it pick up the cert once it was complete.

Usually once you choose a valid cert on System > Advanced, it will be activated once you save the settings.

The ACME package does need to restart the GUI after renewing a certificate on future runs, which it can do by defining a command in the certificate entry. There is an example on the page already that tells you what command to run.

OK, so more testings, now I changed to Route53, but looking at the logs seems that it is not even trying to validate the domain again:

[Tue May 9 17:14:51 BRT 2017] Single domain='mydomain.com'
[Tue May 9 17:14:51 BRT 2017] Getting domain auth token for each domain
[Tue May 9 17:14:51 BRT 2017] Getting webroot for domain='mydomain.com'
[Tue May 9 17:14:51 BRT 2017] Getting new-authz for domain='mydomain.com'
[Tue May 9 17:14:58 BRT 2017] The new-authz request is ok.
[Tue May 9 17:14:59 BRT 2017] mydomain.com is already verified, skip dns-01\. <<<<<<==============
[Tue May 9 17:14:59 BRT 2017] Verify finished, start to sign.
[Tue May 9 17:15:00 BRT 2017] Cert success.

This validation also expires after some time?

For your statement:

The ACME package does need to restart the GUI after renewing a certificate on future runs, which it can do by defining a command in the certificate entry. There is an example on the page already that tells you what command to run.

I see this on the log:

[Tue May 9 17:15:01 BRT 2017] Run reload cmd: /tmp/acme/Webgui/reloadcmd.sh

This command must be run manually? I understood you said that the ACME will reload the webconfigurator automatically.

Thanks again!

jimp

Well, the certificate is not yet in need of renewal so it won't try. If you want to experiment, try making a fresh account key against the LE staging system and then a new cert that uses that key. It's a system meant for testing like this.

If you need help with Route53 specifically, please start a new thread.

If you have the renewal command set in the certificate, and it's active, then the package will run it automatically. If that doesn't work, please start a new thread.

Veldkornet

Is there any way to get the Acme script to stop HAProxy before running the script?

I have it restart HAProxy afterwards currently.

Basically I'm using the "local webroot" option, but if my HAProxy is running, it doesn't renew the certificate and I'm not quite sure what's wrong.
The frontend is only listening on 443, but I guess somewhere it's redirecting all 80 traffic to 443, and I'm not sure where, since it gives the error below:


FOUND domainitemwebroot
put token at: /usr/local/www/.well-known/acme-challenge/X8oGDvSMWzmr1-b-IiaxuyGkTdjSBt1kJNpAxnjwCnE
[Mon Jul 31 10:53:52 CEST 2017] Pending
[Mon Jul 31 10:53:55 CEST 2017] Found domain http api file: /tmp/acme/LetsEncryptTest//httpapi/pfSenseacme.sh
[Mon Jul 31 10:53:55 CEST 2017] storm-family.com:Verify error:Fetching https://domain-name.com/.well-known/acme-challenge/X8oGDvSMWzmr1-b-IiaxuyGkTdjSBt1kJNpAxnjwCnE: Timeout
[Mon Jul 31 10:53:56 CEST 2017] Please check log file for more details: /tmp/acme/LetsEncryptTest/acme_issuecert.log

This is how my frontend is configured currently (see attachment).

If I stop HAProxy, then do the certificate renew, it works perfectly.

Untitled.png_thumb

jimp

Let's Encrypt must use port 80 when validating, not 443. That ACME ACL/Action will have no effect on a 443 frontend.

What exactly do you have setup for port 80? Some other frontend? Or something outside of haproxy?

Veldkornet

Nope, nothing on port 80.

I can only think that I had the header "Strict-Transport-Security" on which is still causing some issues even though it's now removed…

jimp

Make sure nothing on the firewall is using port 80 and then use the method mentioned at the top of page 3 of this thread (https://forum.pfsense.org/index.php?topic=101186.30)

renegade

Thanks for the Howto of HAProy and ACME.
There is one caveat you have to remind in 2.4.0:

The Webroot must not be set to "/tmp/haproxy_chroot/haproxywebroot/.well-known/acme-challenge/" as mentionend in the "help" inline. You must set it as described in the HowTo /tmp/haproxy_chroot/well-known/acme-challenge/

One question.
Is this script a security problem? or should i deactivate the HAProxy on 80 after Cert refresh? I normally only use 443 HTTPS.

dragoangel

@doktornotor:

If someone really insists on using a local webroot.

…

When I try to do like in yours manual i have received 404 resource not found.
Can help with that?
Tech part:
pfSense 2.4.0 , haproxy 0.52_14 (1.7.9), acme 0.1.20
HAProxy part:
Created acme-webroot.lua in files tab, created one frontend to all WAN IPs on only 80 port, ACL: url_acme_http01 with value /.well-known/acme-challenge/ and Actions: http-request lua service with value METH_GET url_acme_http01 and function acme-http01

ACME part:
create issue cert to one domain with SAL list:
method webroot local folder: /tmp/haproxy_chroot/.well-known/acme-challenge/, tried to /tmp/haproxy_chroot/haproxywebroot/.well-known/acme-challenge/

dragoangel

I we created by hands folders (think it may can help, but no):
even tried to change permission to folder to 777 /tmp/haproxy_chroot for test purpose.
mkdir -p /tmp/haproxy_chroot/haproxywebroot/.well-known/acme-challenge/
mkdir -p /tmp/haproxy_chroot/.well-known/acme-challenge/
mkdir -p /tmp/haproxy_chroot/well-known/acme-challenge/

and pointed ACME packet to this roots, but there no files in this directories :( after try issue certificate and because of it i get 404 (it response from acme-http01 lua service)
It this needed I can give acme logs

dragoangel

@renegade:

Thanks for the Howto of HAProy and ACME.
There is one caveat you have to remind in 2.4.0:

The Webroot must not be set to "/tmp/haproxy_chroot/haproxywebroot/.well-known/acme-challenge/" as mentionend in the "help" inline. You must set it as described in the HowTo /tmp/haproxy_chroot/well-known/acme-challenge/

One question.
Is this script a security problem? or should i deactivate the HAProxy on 80 after Cert refresh? I normally only use 443 HTTPS.

Hi you successful configured the pfSense 2.4.0 with acme and haproxy?
Because I have troubles with this, can help? My problem discribed in two post above

jimp

Please start separate threads for distinct issues, having multiple unrelated discussions simultaneously in a thread like this is hard for anyone to follow properly.