Just wanted to add some relevant info to this topic for posterity.

I just moved one of my domains' DNS service to Cloudflare in order to test out their Acme integration.
Worked like a charm.

All I put into the table was the 'Key' and 'Email', leaving all the other fields blank worked a treat.

The ACME package isn't sending you the e-mail, it's from the certificate manager. Only ACME certs are listed in the ACME package.

Check under System > Certificates on the CA and/or Certificates tab and you'll find the entries you are looking for.

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