-
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.
-
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.
-
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.
-
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.
-
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.
-
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
-
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…
-
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.
-
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?
-
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.
-
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 :)
-
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.headerThis is after I clicked on "save".
-
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. -
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)
-
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> -
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.
-
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!
-
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.
-
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!
-
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.
