@Gertjan thanks for helping.

I deleted and wiped the affected certificate and added everything again from scratch.
The cPanel API now succeded to issue the certificate.

Thanks again

@jimp said in ACME certificate PHP Fatal Error:

When you leave it blank it defaults to using DoH/DoT queries to cloudflare and quad9 IIRC

Aha ... the log tells me just that : it's the local acme.sh that is checking regularly - like some kind of 'active waiting'.
And when found, then it informs Letencrypt to do the file domain name zone TXT verification.

If a local policy forbids DoH activity then 'acme.sh' will fail.

@johnpoz said in ACME pkg v0.7.5:

@jimp hmm - I didn't see this with v0.7.4, I just double checked mine. And I had changed one from being the old rsa type even. Guess I got lucky.

Thanks for the update and info..

I checked a couple of mine and almost all of mine were at the default (RSA, 2048) so they never hit this bug since when it would run it checked that the old key type/length matched and it always did.

The couple I saw that I set differently in ACME were also actually RSA 2048 in the cert manager, not what I picked, but they were fine after updating.

I know I've seen a few other posts over the years about people saying it didn't respect their key choices but at the time I couldn't reproduce it. Not sure what changed/when but either way it should be good all around now.

The ACME settings will stay exactly as they are in the config when you uninstall. "Upgrading" a package in-place is the same as uninstalling and reinstalling it.

Some packages have a special setting to remove their settings on uninstall, but it's usually off by default so settings are retained unless you go out of your way to remove them.

@johnpoz

Yes, exactly this. I noticed in the log the if the secondaries were slow to update and the field for DNS-Sleep is empty, it seems to only try about 10 times with little delay between each attempt and then just stops. This would seem to be different than the expectation stated: "The default behavior is to automatically poll public DNS servers for the records until they are found, rather than waiting a set amount of time."

Having entered a set amount of time, has worked every time with no issue.

It's been a while since I changed this setting and what I can't remember is if I rebooted, (assuming the script was hung, when field was empty) or not. I seem to recall that I did reboot, then entered a sleep value and haven't looked back. Has successfully updated the cert every time since the value was added.

JR

@UHL-Hosting Could you ever get this working?

@rainmakers99_1 not seeing this.. running haproxy 0.7.4 package

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.

Yes, works really well using the various key parameters from dynv6, only issue is that the certbot hooks I was previously using used _acme_challenge.mydomain.dynv6.net for one domain and _acme_challenge_domaina.mydomain.dynv6.net etc for my other domains.

I need to grep the code and see if there is a way of influencing the record being written.

If I was using different domains then I'd be fine.

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