Let's Encypt support

jimp

That in python and acme.sh is a shell script. It probably would not be viable to include, especially since that is coded as a hook for the Dhydrated script, not acme.sh

Also read the code, it uses the API I mentioned. I'm really not crazy about the idea of a script manipulating the entire set of DNS records for a domain in that way, but that's how Namecheap coded their API…

paulsnoop

Would it be possible to add dns_cloudns.sh to the next version? The API script was recently added acme.sh github page but I wouldn't know where to start modifying the GUI.

Veldkornet

@doktornotor:

If someone really insists on using a local webroot.

…..........................

4/ Use this for your certificate(s) in ACME package:

Point 4's screenshot is missing. Can you re-post? Or at least describe what it was?

doktornotor

Not sure what you mean by screenshot missing, I can see the screenshot perfectly visible directly in what you quoted. Regardless, the webroot method is now supported in the package, no haproxy needed.

Veldkornet

@doktornotor:

Not sure what you mean by screenshot missing, I can see the screenshot perfectly visible directly in what you quoted. Regardless, the webroot method is now supported in the package, no haproxy needed.

Hmm Okay. Seems to be a CloudFare issue. I've tried from a few locations, but it doesn't show.

Anyway, I was just looking here on the wiki which said I should look at that post :)

Loredo

@jimp:

I'm running this on over a dozen firewalls (mix of VMs and real hardware) here locally and haven't had any problems of this nature.

What is the exact procedure you're following?
What sort of hardware are you using this one?

It is a virtual machine running on HyperV but I would face the very same issue on other VMs running on Proxmox/KVM.
However, I do have other servers w/o having those issues.

The key is generated in a second and shown in the webinterface but after clicking on "save" it simply disappears, resp. never appears as a stored item and consequently the list of account keys is simply still empty.

On directory/file level, I can see that this actually differs between a machine that is working and the one that is not:


./_createkey
./_createkey/ca
./_createkey/ca/acme-v01.api.letsencrypt.org
./_createkey/ca/acme-v01.api.letsencrypt.org/account.key
./_createkey/ca/acme-staging.api.letsencrypt.org
./_createkey/ca/acme-staging.api.letsencrypt.org/account.key
./_createkey/accountconf.conf
./_registerkey
./_registerkey/ca
./_registerkey/ca/acme-staging.api.letsencrypt.org
./_registerkey/ca/acme-staging.api.letsencrypt.org/account.key
./_registerkey/ca/acme-staging.api.letsencrypt.org/account.json
./_registerkey/ca/acme-staging.api.letsencrypt.org/ca.conf
./_registerkey/accountconf.conf
./_registerkey/acme_issuecert.log
./_registerkey/http.header

This is after I clicked on "save".

Loredo

Okay, finally identified the root cause: I am normally logged in with my AD admin account, not via local DB authenticated user.
For some reason it does not store the generated account key when logged in via AD account.

jimp

Then your AD group/account must not be configured properly. The package doesn't know or care what type of account it is. Start a new thread for that (though I suspect you have given it the "Deny Config Write" privilege)

ms-kassel

Hello,

we have pfSense 2.3.4 installed and would like to test the acme plugin 0.1.16. I use the nsupdate process with HMAC-MD5 HOST Key. I have some problems with it.

TSIG error with server: tsig indicates error
update failed: NOTAUTH(BADKEY)

I checked every settings and files. In my opinion the acme script is wrong.

In /tmp/acme/<keyname>/<keyname>/nsupdate_acme-challenge.<keyname>.key there is a wrong bit size "_acme-challenge.gw.edu.ksan.de IN KEY 513 3 157 <key>"

wheter with HMAC-MD5 nor any other type of encryption is the correct bit size shown. If i use the HMAC-MD5 HOST Key with 512 bit, the script always added +1. Any solution for us?

Regards
Markus</key></keyname></keyname></keyname>

jimp

I use HMAC-MD5 Host keys on ~20 systems and they work fine. Your error suggests that your key does not match your host. Please start a new thread for your issue rather than adding on this old general thread.

ViniciusBr

Hi all!

My first post on this forum!

I configured everything on the ACME service and I have a few questions:

1- I decided to validate the DNS manually, it means that I try once, it fails but it gives me the contents of the txt file it is looking for on my DNS. I then create the txt with that content. I tried to use the "renew" option on acme console and it worked. IS the txt file content always be the same? So I don't need to worry to update it manually again.

2- After I hit renew (I only hit renew), it works and then I go to SYSTEM -> CERT MANAGER -> CERTIFICATES I can see the new generated certificate, I can no longer see the previous one. But when accessing the web configurator I still see the old one. Does it update automatically or I need to restart a service?

3- In theory I don't have to worry about it anymore? It will renew automatically from time to time?

Thanks in advance!

jimp

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.

ViniciusBr

@jimp:

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?