Let's Encypt support

cjbujold

Possible bug, one { too much, Please look at:

https://forum.pfsense.org/index.php?topic=125946.0

Thanks

Loredo

I have installed the package on many machines but some of them are unable to store account keys it seems.
They can be generated but clicking on "save" does not seem to make them permanently available.

Is there anything I can do about it?

Regards,
Julian

jimp

@Loredo:

I have installed the package on many machines but some of them are unable to store account keys it seems.
They can be generated but clicking on "save" does not seem to make them permanently available.

Is there anything I can do about it?

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?

I have noticed that slower hardware can take longer to generate keys on so you might have to really be patient and wait for things to complete.

Worst case for the account keys, generate a new key on another box, then copy/paste it over to a slow one, save, then register it via the slow one.

cabalist

Hey there,

I'm following the guide here: https://doc.pfsense.org/index.php/ACME_package but I've gotten hung up on the following statement in the recommended setup:

Before starting, an appropriate DNS key and settings must be in place in the DNS infrastructure for the domain to allow the host to update a TXT DNS record for _acme-challenge.<domain name="">.</domain>

Right now I access our router from 10.0.0.1 and have not assigned it a domain name. My questions are:

What are the appropriate DNS key and settings? Where do I find those?
What DNS infrastructure do I add them to?
What does 'domain' refer to here?

I realize these are rather naive questions but I hope they can clarify the documentation at the very least. If there is specific Let's Encrypt documentation I should be reading I'd love a link to that as well.

Thanks! :)

jimp

If you don't know, then that method is probably not for you. :-)

They are set on your DNS server for your domain, nothing to do with pfSense. It's an nsupdate/RFC 2136 style setup. If you run your own DNS server, search for the name of your DNS host or software along with RFC2136 you might find some info.

cabalist

Gotcha. Thanks. :) I'll do the reading and see if I can make sense of it. The other methods all made sense to me but this one was unfamiliar and also labeled 'recommended' which is why I started to investigate.

We have pfSense in a small office primarily use it for security and performance, not web hosting. We have an internal DNS but not one accessible from the outside world. I had understood Let's Encrypt support as providing a valid SSL certificate for the WebUI but now as I am typing I am questioning that assumption. Ah well.

blarg3891

Does anyone know if they(pfsense) are working to add Namecheap support for dns validation? I'm surprised that this is not in the list.

jimp

@blarg3891:

Does anyone know if they(pfsense) are working to add Namecheap support for dns validation? I'm surprised that this is not in the list.

Namecheap does not have a good API for updating just TXT records or single records.

The normal DynDNS method does not support TXT records. Their other API requires you to read out all of the records, update, and then submit the entire set of records back to them. To me that seems like too much of a risk to mess with.

If the upstream acme.sh project picks up support for it then we'll add the GUI parts but I'm not sure I'd recommend it.

I have a bunch of domains with Namecheap and I'd love to see it work, but I can't imagine Namecheap making it easy to do since they also sell SSL certs and this would cut into their business.

blarg3891

Godaddy does SSL certs as well, but yeah I get your point. Well I'm still on godaddy for the domain i'm using for this effort for the next 2 years…we shall see what happens in that time.

Thanks for the reply.

yodaphone

@jimp:

@blarg3891:

Does anyone know if they(pfsense) are working to add Namecheap support for dns validation? I'm surprised that this is not in the list.

Namecheap does not have a good API for updating just TXT records or single records.

The normal DynDNS method does not support TXT records. Their other API requires you to read out all of the records, update, and then submit the entire set of records back to them. To me that seems like too much of a risk to mess with.

If the upstream acme.sh project picks up support for it then we'll add the GUI parts but I'm not sure I'd recommend it.

I have a bunch of domains with Namecheap and I'd love to see it work, but I can't imagine Namecheap making it easy to do since they also sell SSL certs and this would cut into their business.

Hi jimp

Is this something that can be used to include namecheap support?

https://github.com/h3/letsencrypt-namecheap-hook

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.