@Unoptanio said in WEB GUI login using https with public IP address Certificate "Let's Encrypt" not working: using the GUI, I deactivated the admin user. I created a new user "test2023"and gave him administrator privileges. Oho. Seems like a very bad idea to me. Non of the official Netgate docs gives such an advise. pfSEnse is a firewall, not some sort of NAS, or media serving thing with "multiple" users. Ones in a while, the big chief comes in (the admin) does it things, and then he leaves. True : others "users" can be created for OpenVPN purposes, but these do not interact with pfSense GUI, or SSH etc, it's just a means to identify and authorize the (OpenVPN) connection. Another example : captive portal users

Another benefit of using the ACME DNS method is wildcard names. I'd previously been using the http method with my namecheap hosted domain. I could not use their DNS API with my account. I then realised I could switch nameservers, on my namecheap account, to cloudflare and can now use the DNS method with pfSense ACME package.

The package still cant add txt record. You have to add txt manually and then update the cert.

Are you using HTTP challenge, has to be DNS challenge for wildcard. If have domains on dynu and pfSense gets wildcard certs fine with DNS challenge.

@Gertjan Thank you for clarifying that for me

@Gertjan Thanks. Sorry I didn't read your suggestion well. I've just deleted those expired certificates in System-->Certificates. It should be fine now.

@unraveller349 Ah, ok. When you ask for a certicate, like pfsense.abc.net, you have to do this first : [image: 1692170091978-fefe3484-e51f-4ba4-a5b8-abcc744f42a7-image.png] Btw : You've set this : [image: 1692170537119-c051c25c-7adf-4f4d-8df0-250ad459a25f-image.png] ? If a new certificate was obtained, the webconfigurator has to be restarted so it will use the new certificate. That's what the 'action' is for. In your browser, you should from now on using https://pfsense.abc.net because the browser will first resolve 'pfsense.abc.net", it will obtain the pfSense LAN IP. Did you check that ? nslookup pfsense.abc.net returns 192.168.1.1 ? (or whatever your pfSense LAN IP is). Then it connects to 192.168.1.1, using port 443 (because of https). The web server, pfSense GUI, will send a certificate over that says : I'm am "pfsense.abc.net" and because the browser was looking for "pfsense.abc.net" everything is fine. If you were using https://192.168.1.1 then the test will fail. Because "192.168.1.1" isn't part of the name (SAN) of the certificate.

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 [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-----