It’s working here with the current version of the ACME package. Make sure you are current and make sure the key in the GUI is correct.
That looks more like a server-side error than a client-side error.
I was able to make it work by adding only one SNI: “.example.com". If both “example.com” and ".example.com” are present in the list, it will fail. I guess this is related to the fact that verification records are to be added and removed on the same domain for both, confusing the client.
I ended up doing this because this is what it was suggested in the the blog post I read. I hope docs will be updated to include clean info on how to deal with this, so it would save others time.
@sgw if you’ve got problem importing certs or CAs into things like switches etc. make sure which format they need. Some won’t like normal PEM style format and want sth like PKCS8 or PKCS12 format. Others want key+cert in the same file.
Thanks for the reply
well-known/acme-challenge/my_token at http://www.mydomain.com/ did not give back the token.
do you mean a token should be returned after the colon in the following example
errordetail='Invalid response from http://www.mydomain.com/.well-known/acme-challenge/F-diHXNvud92akJo7Va8450ZS-6MHt23A9n2KjEBBsFc: '
web root file not present
No file existed at /tmp/haproxy_chroot/.well-known/acme-challenge
Is this an authorization issue
error='"error":{"type":"urn:acme:error:unauthorized"
Why on Earth would you do it that way vs just handling ACME on the server? If the certificate has nothing to do with pfSense, and the proxy or web server is capable of handling the request, just handle it there with a local ACME client (certbot, acme.sh, dehydrated, etc)
Exposing the firewall web server, adding users to scp keys around… Lots of things here are using insecure practices, or at least less-than-ideal ones.
After further diagnosis, this appears to be an upstream routing or firewall issue. pfsense cannot ping route53.amazonaws.com and traceroute gets hung up 1 hop away with our ISP–working with them on that.
Let’s Encrypt certificates are only ever valid for 90 days. The field in the GUI controls how long it will wait to force a renewal, usually it’s at 60 days IIRC but you can turn that down. You can’t effectively go over 90 since that would mean it never renews.
I’m also considering Google Cloud DNS as a possible service to switch to, and based on the claim below that adding a dns api script should be “easy” and the extensive Google Cloud DNS API, I won’t rule out Google Cloud DNS yet. Something I plan on looking into over the next few weeks. I don’t know yet whether the Google Cloud DNS api relies on installing certain Google scripts/libraries which may or may not be feasible to run on pfSense machines.
https://github.com/Neilpang/acme.sh
“If your DNS provider is not on the supported list above, you can write your own DNS API script easily. If you do, please consider submitting a Pull Request and contribute it to the project.”
Update to the most recent version of the ACME package, 0.2.6, and try again.
If you do not see that update available, then update pfSense to the most current version first.
;D
That “someone” was me : a certificate for the portal.(mydomane.tld) and another certificate for pfsense.(mydomane.tld) hosted on another NIC.
True, I could have combined these two into one certificate.
These days I simplified maintenance, and I use a (one) wildcard cert.
Btw : not related to acme :
Restarting the GUI is completely harmless - I’m the only “user” anyway.
Restarting the portal does have an impact as explained above.
@riahc3:
@jimp:
You might need a host override on the firewall to resolve that name to your own local web server.
How do I do this?
Go into the DNS Resolver or DNS Forwarder, whichever you use, and add an override that points that name to your local web server. Then anything local that tries to hit that hostname will go directly and will not need to pass through NAT.
Hey,
i found some interesting stuff applying some echo lines on datetimes:
Let’s encrypt generated certificate is always 90 days valid
pfsense WebUI “Services/Acme/Certificate options/Certificate renewal after” option does not affect certificate lifetime generated by Let’s encrypt. It does affect acme_command.sh;
Even a 1 day certificate is valid for 90 days but the option set “Certificate renewal after” correctly set the end date checked by acme_command.sh. So i trust that it could do a good job within 90 days time frame. Any value grater than 90 would let you drop in an unmanged time frame where your certificate is outdated but the script things “Renewal number of days not yet reached”.
I would suggest a bug fix in pfsense UI to discard bad values set up in certificate edit page and help users.
Also
You should consider the second gap: since cron job run once a day, you may run the job just 1 hour before a certificate may ends, then you have to wait next job 24 later to get an updated certificate; in the case a webserver’s certificate you can get users warned by browser security features for 23/24 hours.
We will plan to examine better the code and patch it with such as a provision feature to issue a new certificate if it will be replaced soon
Easy as we speak
just adding the following line in acme.inc it is possible to renew certificates on the edge of 24 hours
$nextrenewalex = $nextrenewal->sub(new \DateInterval(‘PT24H’));
in the function issue_certificate right after:
$nextrenewal = $lastrenewal->add(new \DateInterval(‘P’.$renewafterdays.‘D’));
With this patch cron job would be more efficent while renewing certificates giving no downtime of services where certificates are applied to
Yes. It requires a real, valid domain name. And using webroot or standalone mode on pfSense requires that the domain name point to your WAN IP address and that your firewall expose port 80 and/or 443 (depending on the mode) to the world, which is not good.
Get a real domain name, pick one of the providers that offers a DNS update method supported by the ACME package (there is a list in the certificate options), and then use that to update. You don’t have to publicly expose anything on your firewall for DNS updates.
Strange.
With :
@MervinCM:
pfSense 2.4.2R-p1
This one
@MervinCM:
acme package installed (v0.1.34)
has been replaced ags ago with
acme package installed (v0.2.2)
Packages like acme should be kept on the latest version - no exceptions.
You have probably upgrade and update problems, handle them asap.
edit : oops : first post dates from 24/11/2017 ….
Any, update, a new one came out
problem solved
You can locate the in the acme_issuecert.log
[Wed Feb 28 18:46:02 CET 2018] consumerKey='[hidden](please add '--output-insecure' to see this value)'
[Wed Feb 28 18:46:02 CET 2018] APP
[Wed Feb 28 18:46:02 CET 2018] 6:OVH_CK='XXXXXXXXXXXXXXXXXXX'
ok I figured out why, somewhere along the way the “renew” action in acme.sh stopped running the reloadcmd.sh script which imports the cert back into pfSense. That particular “renew” action is only invoked for DNS-Manual entries, so I added a check to run it in just that case if it successfully obtained a certificate. It works for me.
I only pushed that change to ACME on 2.4.3 at the moment, it will come to the other branches as soon as I push out this pending major update for ACME v2. I was waiting for Let’s Encrypt’s ACME v2 servers to go online this week but they pushed back that date so shrug
So for now, if you upgrade to 2.4.3 and get ACME package version 0.2.0.4 which will go up with the next snapshot run, it will be fixed. You can try manually applying the changes yourself in the meantime as a quick fix: https://github.com/pfsense/FreeBSD-ports/commit/a6f630edae775ad4b3619858baa910809297c2d0
@breakaway:
As in thread title 2.4.2_1 installed today with latest version of ACME package.
I have it 99% working - I got it integrated with my Route53 account so it can use TXT records to generate certificates but I am finding that the certificate gets acquired, shows up in the list of certificate list but isn’t actually enabled (i.e. webconfigurator default is still enabled).
I have to manually update it to use the LE cert. Did I configure this wrong or is this the expected behaviour?
Or - is this the expected behaviour? I.e. I set the “certificate name”, then this certificate gets generated then subsequent times the certificate is generated, the same certificate will get updated and therefore everything will roll over smoothly?
Once you generate the cert for the first time, goto “System / Advanced / Admin Access” and set the “SSL Certificate” to whatever you generated.
What you will also need to do is in the ACME “Edit Certificate options” section for that cert is make sure you add an “Action” to restart the WebGUI when its renewed. Like in the attached Picture.
Since the OP in this thread is solved and working now, I’m locking this one. There is another open thread to use for similar symptoms here:
https://forum.pfsense.org/index.php?topic=144321.0
Hello matthijs,
I am almost sure I find your solution (I needed it too).
Here is my idea :
run the function which is called when someone presses the ‘save button’ on ‘reverse proxy’ GUI page, but run it from the command line.
and then, restart squid.
And here are commands I came up with:
using php, include ‘squid.inc’ and ‘squid_reverse.inc’ file, launch ‘squid_resync_reverse’ function
php -r “require_once(’/usr/local/pkg/squid.inc’); require_once(’/usr/local/pkg/squid_reverse.inc’); squid_resync_reverse();”
using basic command line, restart squid
/usr/local/etc/rc.d/squid.sh restart
It worked for me once, while pressing ‘Issue / Renwe’ button. I know need to wait for xx days to see if it does it automatically too (but it should).
Hope it will help you (and others ).
Pretty much all decent browsers and other SSL clients send SNI. Lots of webservers running multiple sites and multiple certificates, need it to pick the right certificate to return to the client.
(IE on XP was notorious a few years ago, but that shouldn’t be connected to the internet anyhow these days…)
It should be working OK, if you do experience issues please do tell though.
@-flo-:
Gertjan, can you elaborate on how you set this up?
Never did so myself.
“DNS-Manual” means that you have to go through the same procedure every 90 days or less.
You need a domain name, and you need to have access to “zone information” of this domain name. I guess every registrar gives you this kind of access when you rent a domain name.
So, it’s rather easy to set a TXT record with the key info letsencrypt gave you when asking for a certificate or renewing a certificate.
When you add this key, probably using the GUI used by the registrar to administer your domain name, know that you have to wait several minutes or even more, because the zone info has to be synced among at least one other name server that ‘hosts’ you domain name.
Only when that has been done, you can proceed with the acme interface (pfSense) to ask for a (re) new certificate.
I’m using my own dedicated server, and I’m using my own DNS master server that hosts my domain name (actually more then 10).
acme used by pfSEnse has been set up to “talk” to my DNS server, so it can add these TXT records itself in the zone file (the file with all the info related to a domain name).
This is the so called “nsupdate” method, and is fully automated.
@B-C:
like 8443 - I can create the LE cert for one of these VMs, just not clear on how the VM gets the cert installed to use?
using a Service Desk Plus specifically running on debian.
There is no such thing as a buildin script that copies a certificate (certificate files, or the whole bunch in a ‘chained’ file) from one device, pfSense, to another device, your server.
The files have to get moved over, the service - the web server - has to be restarted.
It is possible of course, but for your setup you need your script.
When I renew my certificate for my pfsense (pfsense.mynetwork.tld) I also renew for diskstation.mynetwork.tld, printer1.mynetwork.tld printer2.mynetwork.tld, etc. I have to copies the needed files over to the diskstation, printer1, printer2 etc - most of them do not even have a telnet or ssh access, so scripting is impossible.
Best is to run some letsenscrypt support from these devices, if it is possible.
Thank you, this seems to have done the trick. A little bit of extra work because manual DNS is a pita and the local http server can’t bind to port 80 becauase of local running ngix - hence a port forwarding is necessary. Also I didn’t think of this thread you’ve mentioned because some renewals still worked with tls, some others didn’t so this made it harder for me to specify an exact error scheme.
Julian
Should that URL be open to the world? I can’t reach it on port 80 over IPv4 or IPv6 right now. Perhaps the validation servers at Let’s Encrypt also can’t reach it?
Since it’s a timeout, I would focus on firewall rules or other access rules, maybe even routing upstream, anything that could prevent LE from reaching your web server on port 80. Maybe you have something like pfBlocker filtering access or geoblocking?
