@UHL-Hosting Could you ever get this working?

@rainmakers99_1 not seeing this.. running haproxy 0.7.4 package [image: 1687386278163-haproxy.jpg] ash-4.4# openssl s_client -showcerts -connect overseerr.snipped.tld:443 CONNECTED(00000003) depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = overseerr.snipped.tld verify return:1 --- Certificate chain 0 s:CN = overseerr.snipped.tld i:C = US, O = Let's Encrypt, CN = R3 -----BEGIN CERTIFICATE----- MIIEeTCCA2GgAwIBAgISAy/wlx0VeNdy7MasuMlgMXWIMA0GCSqGSIb3DQEBCwUA MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD <snipped> f3GCqxYB7VjcmcDqbPMIvM8JKOH2BxLDnwuZUnDyQ1Uqk/0/4DCZJX48hXUK5aN/ 57JVAeK0ztxWV0syfCVotX0n+sqs4BVKojx71e06jUmECOdP5p3W0Ka9y5t1gIAK f1CpjOjLdxXSyE4IKVknSkZs3N0GTVEkdeje/rcllAtr2Y84894xFcZGNIUf -----END CERTIFICATE----- 1 s:C = US, O = Let's Encrypt, CN = R3 i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 -----BEGIN CERTIFICATE----- MIIFFjCCAv6gAwIBAgIRAJErCErPDBinU/bWLiWnX1owDQYJKoZIhvcNAQELBQAw TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMjAwOTA0MDAwMDAw <snipped> hCExroL1+7mryIkXPeFM5TgO9r0rvZaBFOvV2z0gp35Z0+L4WPlbuEjN/lxPFin+ HlUjr8gRsI3qfJOQFy/9rKIJR0Y/8Omwt/8oTWgy1mdeHmmjk7j1nYsvC9JSQ6Zv MldlTTKB3zhThV1+XWYp6rjd5JW1zbVWEkLNxE7GJThEUG3szgBVGP7pSWTUTsqX nLRbwHOoq7hHwg== -----END CERTIFICATE----- 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1 i:O = Digital Signature Trust Co., CN = DST Root CA X3 -----BEGIN CERTIFICATE----- MIIFYDCCBEigAwIBAgIQQAF3ITfU6UK47naqPGQKtzANBgkqhkiG9w0BAQsFADA/ MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT DkRTVCBSb290IENBIFgzMB4XDTIxMDEyMDE5MTQwM1oXDTI0MDkzMDE4MTQwM1ow TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwggIiMA0GCSqGSIb3DQEB <snipped> WCLKTVXkcGdtwlfFRjlBz4pYg1htmf5X6DYO8A4jqv2Il9DjXA6USbW1FzXSLr9O he8Y4IWS6wY7bCkjCWDcRQJMEhg76fsO3txE+FiYruq9RUWhiF1myv4Q6W+CyBFC Dfvp7OOGAN6dEOM4+qR9sdjoSYKEBpsr6GtPAQw4dy753ec5 -----END CERTIFICATE-----

@NollipfSense said in Error adding txt (Solved): Set DNS-sleep to 5 mins/300sec has no effect, and took ONE SECOND see below... Setting up the zone just before verification doesn't need any delays. When the account has been verified and all 'add TXT' records have been successfully to the zone added (no errors) then a "DNS Sleep" is introduced, because you've update the DNS master, and this one has to signal all the DNS slaves, so they can get back to the master to sync up the zone. This important DNS mechanism is important, and completely out of our control. A safety delay is needed. Glad you worked it out.

@AMG-A35 well test it.. simple enough to allow http access to your gui, then delete your external cert. Can you still get to the https? If not either get a new cert, or put your externals back. But deleting the acme certs - guess what, when you run acme again more than likely it will just put its cas back.

The issue maybe just pfsense prepending _acme-challenge. to the challenge fqdn in the filename when "Enable DNS domain alias mode" is ticked

Problem continues after upgrading to Pfsense 23.05 and ACME 0.7.3_2, I haven't had any response in the Redmine thread either :( Crash report begins. Anonymous machine information: amd64 14.0-CURRENT FreeBSD 14.0-CURRENT #1 plus-RELENG_23_05-n256102-7cd3d043045: Mon May 22 06:35:01 UTC 2023 root@freebsd:/var/jenkins/workspace/pfSense-Plus-snapshots-23_05-main/obj/amd64/LkEyii3W/var/jenkins/workspace/pfSense-Plus-snapshots-23_05-main/sources/FreeBS Crash report details: PHP Errors: [03-Jun-2023 14:28:36 Europe/Madrid] PHP Fatal error: Uncaught TypeError: Cannot access offset of type string on string in /usr/local/www/acme/acme_certificates.php:261 Stack trace: #0 {main} thrown in /usr/local/www/acme/acme_certificates.php on line 261 No FreeBSD crash data found.

@jrey thanks for the quick reply. In my case exporting with "Low" and no password worked (for a Windows Server 2016 Exchange).

@jimp How can one request a new type of provider? Please can support for FreeIPA be added to the list of providers? It would ease the management of 'corporate' internal certificates. Especially as pfSense doesn't have an API for making configuration changes and updating certificates.

@ivanildolb a domain can be had for very cheap, most registrars have sales so you could get somedomain.tld for like 88 cents for a year sometimes.. or 2$ etc.. that normally will go up after year 1, etc. but typically a domain only costs like 10$ a year. But yeah it is just not possible for some browser to auto trust some cert without it being public domain.. You can use any domain you want and create certs your browser will trust - but you have to have enough control over the browser to install the CA cert as trusted source.. I do this for all my services I run locally that I access, the unifi controller web gui, my nas gui, pfsense gui, my printers gui, my switches web gui... For these I use either local.lan as the domain, or home.arpa - you can use any domain you want and your browser will trust it, as long as you tell the browser to trust the CA.. But if its just some random browser out of the box on someones machine - no they will not trust anything other than some public CA, and for this you have to have a public domain.

@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.

@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 : [image: 1678087161659-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.