Let's Encypt support
-
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.
-
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? "
-
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.
-
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.shThis command must be run manually? I understood you said that the ACME will reload the webconfigurator automatically.
Thanks again!
-
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.
