What else did you need to do as I'm about to enable dynv6 too?

@rbron01 I opened a PR with acme.sh which collected dust for 2 years… having grown tired of seeing it in my GitHub dashboard, I deleted my fork and closed the PR a few weeks ago. A bit silly, all it took was a button to get it merged.

Here’s the PR: https://github.com/acmesh-official/acme.sh/pull/3532.

@jpvonhemel said in Fatal Error PHP Acme Certificates in Renew Column:

@kapranos Sorry to hear, but glad it wasn't just me. Unfortunately my post did not gain any traction with Netgate, so I figured it was a problem unique to me. After a few days of frustration with the unstable upgrade, I nuked the firewall install, installed a clean image and reconfigured the firewall.

I was able to import most of the settings from backup. For me, that was mostly DCHP reservations, nat and firewall rules, so it wasn't the end of the world. Going foward, I will be more careful with updates and backups. I believe there is a way to leverage the zfs file system to retain and boot from an old install, so I do need to look into that a bit more.

I honestly do not know how it happened, but chalked it up to some sort of corruption on update or a really odd bug.

Thanks, for the moment I will live with the error, it doesn't bother me so much, I hope it will be solved with an update.

thanks

@wbrown766 - I saw your post and was having the same issue last night. I created a couple of PRs that hopefully head in the right direction for both Google ACME support and GoogleDomain support.

https://github.com/pfsense/FreeBSD-ports/pull/1246 (tested as working) https://github.com/pfsense/FreeBSD-ports/pull/1247 (waiting on upstream)

@gertjan Thanks for the provider info, and also for all of your replies, which were extremely helpful to me! Kind regards.

FYI just today that script gave me hassles until it... just started to work.

Same script by Jan Broer as always, same config as always.

pfsense: 2.6.0-RELEASE (amd64) acme: 0.7.3 haproxy: 0.61_7 Frontend configuration: ACL configuration ACL Name: url_acme_http01 Expression: "Path starts with:" Value: /.well-known/acme-challenge/ Actions Action: http-request lua service Condition acl names: METH_GET url_acme_http01 lua-function: acme-http01

Lua script in case I lose it again:

-- ACME http-01 domain validation plugin for Haproxy 1.6+ -- copyright (C) 2015 Jan Broer -- -- usage: -- -- 1) copy acme-webroot.lua in your haproxy config dir -- -- 2) Invoke the plugin by adding in the 'global' section of haproxy.cfg: -- -- lua-load /etc/haproxy/acme-webroot.lua -- -- 3) insert these two lines in every http frontend that is -- serving domains for which you want to create certificates: -- -- acl url_acme_http01 path_beg /.well-known/acme-challenge/ -- http-request use-service lua.acme-http01 if METH_GET url_acme_http01 -- -- 4) reload haproxy -- -- 5) create a certificate: -- -- ./letsencrypt-auto certonly --text --webroot --webroot-path /var/tmp -d blah.example.com --renew-by-default --agree-tos --email my@email.com -- acme = {} acme.version = "0.1.1" -- -- Configuration -- -- When HAProxy is *not* configured with the 'chroot' option you must set an absolute path here and pass -- that as 'webroot-path' to the letsencrypt client acme.conf = { ["non_chroot_webroot"] = "" } -- -- Startup -- acme.startup = function() core.Info("[acme] http-01 plugin v" .. acme.version); end -- -- ACME http-01 validation endpoint -- acme.http01 = function(applet) local response = "" local reqPath = applet.path local src = applet.sf:src() local token = reqPath:match( ".+/(.*)$" ) if token then token = sanitizeToken(token) end if (token == nil or token == '') then response = "bad request\n" applet:set_status(400) core.Warning("[acme] malformed request (client-ip: " .. tostring(src) .. ")") else auth = getKeyAuth(token) if (auth:len() >= 1) then response = auth .. "\n" applet:set_status(200) core.Info("[acme] served http-01 token: " .. token .. " (client-ip: " .. tostring(src) .. ")") else response = "resource not found\n" applet:set_status(404) core.Warning("[acme] http-01 token not found: " .. token .. " (client-ip: " .. tostring(src) .. ")") end end applet:add_header("Server", "haproxy/acme-http01-authenticator") applet:add_header("Content-Length", string.len(response)) applet:add_header("Content-Type", "text/plain") applet:start_response() applet:send(response) end -- -- strip chars that are not in the URL-safe Base64 alphabet -- see https://github.com/letsencrypt/acme-spec/blob/master/draft-barnes-acme.md -- function sanitizeToken(token) _strip="[^%a%d%+%-%_=]" token = token:gsub(_strip,'') return token end -- -- get key auth from token file -- function getKeyAuth(token) local keyAuth = "" local path = acme.conf.non_chroot_webroot .. "/.well-known/acme-challenge/" .. token local f = io.open(path, "rb") if f ~= nil then keyAuth = f:read("*all") f:close() end return keyAuth end core.register_init(acme.startup) core.register_service("acme-http01", "http", acme.http01)

@svengalh said in SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE after successful cert renewal:

Changing to the recently renewed certificate

You only set this ones, the day you start using the certificate :

307b0fc6-f09c-46ee-b08d-ab03ec260831-image.png

from then on, the acme pfsense package will renew this cert. There is nothing more to do.

If you change the certificate's name/ID, then, yeah, you have to change to that new cert.
But why would you you do that ?

@gertjan said in Issue/Renew does not show "Reload success" screen in 23.01:

@chudak

I've just hit "Renew", and saw the usual :

Thx for the reply.
It's good to know, must be my browser cache then.

@pierrelyon
Yes, you can do that.
It only need to be a server certificate for both operation purposes.

@decidable3195 said in ACME Verify error: 404:

Please check log file for more details: /tmp/acme/Webserver/acme_issuecert.log

The last line shows you where more info can be found :
/tmp/acme/Webserver/acme_issuecert.log
although, even if you don't spot the error, at least you will know now how deep the pool is ;)

Important info is also :

http://www.xxx.com/.well-known/acme-challenge/wCSyAsP9hDHGn7CPmLyEXZd7uuAUlnBgpBrcKZux39M: 404

This means that if Letsencrypt, or me, or you, or who ever, visits this file :
http://www.xxx.com/.well-known/acme-challenge/wCSyAsP9hDHGn7CPmLyEXZd7uuAUlnBgpBrcKZux39M
you ( and I, and everybody, and also LE) should see the secret temporary 'key' (some random asci codes, you can see it in the acme log) that acme.sh put there.

So, http://www.xxx.com/.well-known/acme-challenge/ must be publicly accessible.

So, the question is : is the file there ?
And if so, is the content ok ? Often, if the file was created, the content is also fine.

You already run your own web server on a server, so you know where the web server root folder is.
In that root folder, there must be a sub folder with the name ".well-known/" that contains a subsequent folder called "acme-challenge/".
Is that so ?
Now, create a file called 'hello' and put something in it like "hello again".

Now : test, like me and LE : from the outside ( !! ), use your phone with the wifi de activated , and visit http://www.xxx.com/.well-known/acme-challenge/hello
Does it show "hello again" ?
It should.
If you can't, LE can't do it neither => fail !
Remember : LE told the acme.sh script the file name : in your case, it was "wCSyAsP9hDHGn7CPmLyEXZd7uuAUlnBgpBrcKZux39M" and it also gave a content like "hjgjhghjgqgqjhdqsgqsgd".
That was the "Getting domain auth token for each domain" part.

Then, all acme.sh has to do, using a helper DNS-script like 'webroot' is accessing your web root, create the sub folders and the file with the content.
This must work.
This is the :
Getting webroot for domain='www.xxx.com'
Getting webroot for domain='service.xxx.com'
part.

Btw : if all works well, and the LE check passes, the acme.sh helper script will also remove the wCSyAsP9hDHGn7CPmLyEXZd7uuAUlnBgpBrcKZux39M file.

You use the standalone mode. That's a no-automation-mode.

Read the manual : https://github.com/acmesh-official/acme.sh/wiki/How-to-issue-a-cert

That's strange because you have (you should) access to your web server's root folder.
There is the webrootftp helper mode. You have FTP access, right ?? (ok, 'FTP' was abandoned and shot in the forest last century, but you can still use it locally)

Or far better, as you have a domain name (that you rent annually) : most (the ones that don't are all broke by now) registrars have an API access : use the API access credentials, pick the right helper access, and use one of the DNS helper modes

General comments :
Opening port 80 and or 443 (the webgui) on WAN ?
Your pool is 1 mm deep, and you dive head first in it. We all know what will happen.

You are using floating rules.
Take this advise : don't do that. Live is already hard enough without that "floating" thing.

@jimp Would it be possible to just create another "method" in the UI that simply disables attaching any sort of additional --dns XY parameters, so only the first one (that has to be defined of course) is taken into account? That would already help so much with multi domain SAN / multi wildcard domains that are used in combination with HAproxy and other services!

I just had to manually comb through various customer installations again today because of API/timeout problems caused by needless tries to authenticate additional SAN domains with their own tokens that wouldn't be needed (as all could be tested by using the same).

Cheers

@kenw if your goal is to prevent access to the gui - you would do that in a firewall rule, only allow the IP or vlan you want to be able to access the pfsense web gui.

This is quite often locked down from the default antilock out rule on the lan, by create a management vlan.. And only this vlan has access to the gui via firewall rule. You only put machines on this management vlan that you want to be able to access pfsense web gui.

@johnpoz thank you for your quick reply, the issue was on myside, was using the wrong TOKEN code :)

So I removed the AccountID, ZoneID and the Token from the Cloudflare panel under certificates. After that issuing new certificates started to work just as expected.

@gertjan said in Add SSL DH Parameters:

You can use this script to 'coook' something for yourself.

There is a commented line that shows where I 'cat' the RSA4096 DH file to the cert.pem file.
you can find the latest cert version in a known place.

Btw : some more investigation will be needed, as : where does the HA proxy startup code gets the cert info from when preparing for a HA Proxy start ?

In the past, the trick of modifying the main 'cert.pem' was used by many processes, but these days, as my apache2 example, it has become a separate setting in a config file.

I hope "Domoticz" will also adopt that method.
See the wiki page again : Domoticz has its own deploy script : you can also use that one as an example.

Thanx for the example man, very interesting!
Sadly my linux skills are like "trial and error" ;-)
Especially (secured) SSL is quite difficult to understand

Domoticz has a build-in HTTP (9090) and HTTPS (443) server and also the possibilty to pass the login inside the local network with an option in the settings: 192.168.1.*.
This allows all computers inside the local network, starting with this ip address, to pass the login of domoticz.
The problem with this login pass option is that also the outside world doesn't have to login because of the HTTP connection in the backend of HAproxy. Therfore I currently did not set this option to protect the webapplication.

On the other hand the advantage of the current configuration allows me to turn off the HTTPS 443 ssl connection in the startup file of domoticz (I just figured out). This way I don't get certificate and https errors in domoticz anymore because everything is handled by the HAproxy server and ACME

I have to think about it, thanx anyway for the info!

@gertjan It is more than a GUI error, when I check the certificate using the Certificate Manager, the one I am trying to get an vertificate for only has the private key. No Certificate data.

@johnpoz Ahhh ok! Perfect! Thank you!

@dutsnekcirf said in Is there a DNS-NoIP option?:

My public DNS is provided by No-IP.org and I've managed to get a certificate created using the DNS-Manual method. My understanding is that this verification method does not allow for automatic certificate renewal. Is there one of the automated verification methods that I could use with no-ip.org? Thanks!

I recently went through this same situation. I switched from Dyn-DNS to No-IP only to find out that No-IP does not expose API keys or anything to allow the acme package to perform the DNS changes necessary for automatic renewal.

I ended up canceling no-ip and moving to cloudflare. Cloudflare is actually great once you get it setup and so far, free for what I am doing as well.

Found the solution:

there must be 2 CNAME records according to
https://github.com/acmesh-official/acme.sh/issues/2789

one for _acme-challenge.domain,tld to _acme-challenge.domain.tld
and a second one for _acme-challenge.pfense.domain.tld to _acme-challenge.domain.tld.

@sensewolf

What did the green 'log' in the GUI tell you ?

Or, better : zero the log file I mentioned above.
Do a manual renew.
Look at the file again, it has many lines now.

Upload them to (whatever) => pastebin.org
Past the link here.

Btw : be careful, don't press several times per day at the manual reew button : after 5 times or so, you'll get blacklisted for a day, as the number of times you renew a cert is limited.

@sgw said in Exchange 2016 - pull LE cert from pfsense:

If Exchange should really require 128 GB RAM, that customer is out of the game anyway

That was basically our thought process. I checked around a bit and some people with smaller servers said Exchange 2019 seemed to be OK with 64 or 92 but in the big picture I think Microsoft expects enterprises to run their own servers, and everyone else to use 365.

re: maintenance, Microsoft only releases security updates for supported versions of Exchange which is the last two Cumulative Updates of each version. This MS page is noisy but if you look closely only the Exchange 2016 CU22 and CU23 lines have links because they are supported, and CU21 has no updates after March. Essentially, every 3-6 months one must install a CU which in my experience takes 2-3 hours because it's essentially a full Exchange install each time. If someone isn't installing those, no security updates for Exchange are installed via Windows Update. It just quietly doesn't see any.

Exchange 2016 ends support in Oct. 2025. Microsoft only allows/supports migrations for the prior two versions. So your customer will need to move to Exchange 2019 or "Exchange 2022" or whatever it will be called by 2025.

None of that is anywhere near your question but that's why we moved off local hosting, and none of it is our problem anymore. :)

Hi Everyone,

I asked the same question over in the Let’s Encrypt forums, and I got some great answered and clarification on what I was trying to do. https://community.letsencrypt.org/t/acmev2-ssl-with-google/187727/18

Hopefully Google will do ACME wildcard verification through Google Domains in the future.

I am seeing same issue in 2.6.0-RELEASE with ACME 0.7.3 package.
Provider is Cloudflare in DNS domain alias mode.

Generating cert using 256/384 ECDSA key works, but even after switching to RSA 4096 still gives 2048 bit key cert.

@flemmingss

Aha : You are using the pfSense HAproxy package.

Go back to the

2e218531-a3fd-4bbb-8478-530e10807cc3-image.png

page, and start reading.
This time, up until the bottom.

You will find the very important dns sleep.
That's why it's there.

And also this one :

f3426682-5bbe-4a3e-920a-8bef7be592c6-image.png

as it was made for you.

The certificate name will not change when it is renewed. No need to select 'another' cert in the HA Proxy settings.

Now, when acme.sh successfully renewed the certificate, it will also restart HAproxy. So it takes in account the renewed certificate.
And you can go back to the admin's main task : constantly ( 😊 ) checking if all automated tasks are correctly executed.

@gertjan Don't Worry I bought different domain name from NO-IP and the certificate started working with it.
Thank you for your help.

@ejdesgaard-0 Seeing the same issue - did you ever figure out what went wrong?

@ms264556 said in How do we request a new package release?:

and easy

Before you click on 'get me 2.7.0', read the top most messages from this forum : pfSense® > Software Development > CE 2.7.0 Development Snapshots

Thank you for the explanation.

I don't expose the GUI to the WAN, and frankly I have little need for SSL to my pfSense beyond getting rid of the annoying "Invalid SSL Cert" interstitial page when logging in from an internal machine. Using "dave.duckdns.org" internally works nicely for this, solving my problem.

Has anyone had any luck resolving this issue?

I'm also seeing this exact issue on 2.6.0 with the acme 0.7.1_1 package.

Deleting the CA doesn't seem to work as it just gets re-created.

@gregoinc I just went through this myself. I originally had made all my own certs and added them to clients root cert authority but the self hosted web interface for my home security system doesn't allow for adding of ssl certs. Since I already have a paid for domain name for 10 years and this was so easy I just set it up for all my home private severs on LAN. I know I'm about a month late, but for anyone else maybe it will help. YouTube: How To Create pfsense Let's Encrypt Wildcard Certificates using HAProxy

https://github.com/acmesh-official/acme.sh/wiki/dnssleep

@seanmcb said in ACME renewal timeout and "No doh":

In dns manual mode, after the dns record is added manually, acme.sh will use cloudflare public dns ....

as cloudflare public dns or google dns are only used when dnssleep is not set.
dnssleep is pretty mandatory when using some API/auto mode.
But not for manual mode (human interaction is slow by default ;) )

dnssleep exists because DNS syncing takes an unknown time.
The DNSAPI mode uses a script file and your access credentials so you it can add (and afterwards : remove) one or more TXT records. You will be updating the DNS domain name master DNS only. There should be at least one DNS slave, and it will get signalled 'by the master there is an update' in the zone.
The zone slave can then initiate a zone transfer whenever it wants, it could be right away, or x second / minutes later (the zone master admin determines the sync parameters).

When the zone is synced, LE is signalled to proceed with zone checking. It will locate the domain name servers, pick any of them, and checks the TXT record.
Btw : I thinks it checks all the listed name servers.

When using manual mode, there is no need to wait ..... sleep == dnssleep, as it will take you some time to connect to the GUI that allows you to set the needed TXT records in your domain zone
Because you didn't use dnssleep acme.sh will do now an extra step for you when you proceed : it will do a dns zone check for you by using cloudfare, google DNS etc.
So acme.sh will only signal LE to proceed with the zone checking if it knows that the TXT records are actually set (and the admin who sets the TXT records manually didn't make a mistake).

I don't understand why this check isn't actually made also when DNSAPI mod is used, as an extra local check step before LE is asked to check and deliver a cert.
My for some sites where acme.sh is used there is no google or cloudfaire access ( pfblockerng users ;) )

All this is my opinion of course.

From your https://redmine.pfsense.org/issues/13495

the purpose of the field is not to "configure how much time to wait before attempting verification" but rather it's to disable verification and instead wait the specified numbers of seconds. This is useful for people like me that block access to cloudflare and google DNS.

Well, it is waiting xxx seconds after a "successful TXT field insertion".
During this time, DNS master and slave(s) should do their sync magic.
Then control is given back to LE so it can do its checking, and give you back a cert if it was successful.

I guess this dnssleep parameters serves somehow a double function.
When absent (not set) acme.sh will do a local check using a known DNS resolvers. I tend to say : to inform you that you did your manual work ok.

IMHO :the ddnssleep can be very low, but can't be zero in 99,99 % of all cases.
It should be set to "120" if you didn't modify that setting.

Btw : I'm using nsupdate ( dns_nsupdate.sh ) method as I do not use the API of my registrar : I'm hosting my own domain name master and several domain name slaves (bind). These domain name servers only host my own domain names, so they have not much to do.
I can follow the update process while tracing the logs everywhere = the adding of the two TXT records, the signalling of the master to the slave, the reception of this signal by the slaves, the slaves that call back the master for a zone sync.

One in a while, I also use freedns.afraid.org as an extra dns slave, and the sync back of freedns can take to up to 5 minutes to sync with my master. When I use the dns salves of my registrar, this can even take longer, as they have zillions of zones (domain names) to handle.

nevermind i solved it
didnt have the letsencrypt key.
I thought clicking save would create it

Just a nudge on this question, currently I am having to disable 2FA when I want to renew.

Does anyone know how the he.net integration works, is it simply scraping dns.he.net or is it usign an API?

According to he.net it should be doing something like this ..

curl "https://dyn.dns.he.net/nic/update" -d "hostname=_acme-yourdomain.com" -d "password=txtRecordKey" -d "txt=ACMEChallenge"