@sdowling said in Cannot Renew LetsEncrypt Cert: Wait a bit of time (5 mins), then hit the 'Renew' button and ..... wrong ^^ Why passively wait ? Make it an active wait. You add the TXT record with the google domain record GUI. Now, start polling it : have pfSense ask for that TXT record : dig @127.0.0.1 _acme-challenge.your-domain.tld TXT and repeat this until you get your -correct - TXT record back. Now you know the TXT is valid for you, and also for Letsenscrypt. This is the moment you can proceed. Btw : the DNS propagation time is somewhat random. Do the check yourself : As for all the DNS name servers of your domain : dig @127.0.0.1 your-domain.tld NS You get a list back with all the DNS servers for your domain. dig @ns1.your-domain.tld _acme-challenge.your-domain.tld TXT dig @ns2.your-domain.tld _acme-challenge.your-domain.tld TXT dig @ns3.your-domain.tld _acme-challenge.your-domain.tld TXT etc. (there should be at least two NS servers) They all have to return the valid TXT record. Btw : the acme DNSAPI automates this adding (and deleting !) of these records. Authentication will be needed of course, as you have to ID yourself to get access to the GUI to modify a DNS record yourself, and when that's done, it's a pretty straightforward process.

@regexaurus Alternative ways to kill the duck-bug : Instead of the always needed SSH - so ok to have it set up ones : use the classic console access, as this should work to. Or : install the System_Patches pfSense package, which exists for doing just that. Now, if we can get our hand on raw the diff file (and get the paths correctly) its just a question of copying the commit ID URL and two more clicks (patching without a keyboard).

@lftiv Thanks so much for that! I had renamed the keys at some point since last renewal and was at my wits end why it wasn't working. So sad that this is still a problem!

@jimp Thanks for the suggestion. I do get the following error on reboot with filesystem check, even after uninstalling the haproxy package in the GUI. 11:24:34 PHP ERROR: Type: 64, File: Standard input code, Line: 4, Message: require_once(): Failed opening required 'haproxy/haproxy.inc' (include_path='.:/etc/inc:/etc/inc/web:/usr/local/www:/usr/local/captiveportal:/usr/local/pkg:/usr/local/www/classes:/usr/local/www/classes/Form:/usr/local/share/pear:/usr/local/share/openssl_x509_crl/') I just updated from 2.4.5 to 21.02 with an image from Netgate. I will try reinstalling it.

@appollonius333 said in Using ACME with Bind9 package and Cloudflare: You think it will do any harm to use a public domain for my private network? As long as the you own (= rented) the domain name : you have no choice. You can only asks for certs for domain names for which you can prove that you control. @appollonius333 said in Using ACME with Bind9 package and Cloudflare: I hear people saying yes because it increases your attack surface but others also say no because they do not know where the 'domain' is aiming to. Also nobody knows the domain exempt me. Yeah, there are also people that want phones without numbers. An cars without licence plates. Etc. If you want to use a public 'thing', you have to conform to the usage rules of the public thing. IP addresses and host names can't really be hidden. Asking a cert from Letsencrypt for a domain name doesn't make that domain name publicly known, although it will figure on yet another (huge !) list ^^ Your domain name doesn't have to point to the IP of your WAN, or something like that. But that's what I'm doing : I have this my-domaine.net that I'm actually using just for my LAN, like pfSense, my NASes, printers and such. I'm not really using this domain name on the net. I have acme.sh asking for a wild car cert, so I can create host names with a cert like pfsense.my-domaine.net, nas .my-domaine.net, printer1.my-domaine.net, printer2.my-domaine.net, airco.my-domaine.net etc. Now all these devices have https access. I did create a sub domain like home.my-domaine.net on the name server (my own 'bind' based name servers) on the internet, have this sub domain pointing to my WAN IP (using DDNS if it's not static) so I can access my pfsense from else here, using OpenVPN. this is what I'm doing (and not related to acme). Btw : lab.nl is a domain that is owned (rented) by some one. You can't use it.

[image: 1614800931694-aa4ad270-b4a6-4a6e-adf7-7d7d66ba2bda-image.png] As discussed here a month ago : Let's Encrypt Certificate Authority Expiring soon : do what has been suggested over there. We have 2.5.0 now, the GUI warns us. Still, up to use to use the buttons : [image: 1614801043540-353c0e68-9a66-4784-92f2-2fde461dc2dd-image.png]

@gschmidt i would go for the haproxy-devel one.. that would be the 0.62 at this moment.

@flemmingss Hi Flemmings, I do the same and worked. After you can change again to cname *.duckdns.org and renew certificate again. now is working fine. thanks to all

@mbentley said in Let's Encrypt Certificate Authority Expiring soon: It doesn't have anything to do with a pfSense version or a plugin version - the timing is just a coincidence. The only strange thing is that on 2.5.0 this causes a notification, but on 2.4.5 not. Maybe is something that they added in the new version and that i haven't read yet in the changelog. @gertjan said in Let's Encrypt Certificate Authority Expiring soon: https://letsencrypt.org/certificates/ I literally just finished reading it! So the "old" one is safe to delete it, that's the important thing! Thanks to everyone!

@foolish86 :)Who gave me that tip was @Gertjan, thanks to him we both got our certificates.

Just to revisit this thread.... I was having problems renewing my Namecheap Let's Encrypt certificate using the manual method so figured I would give this a try. It was all quite easy - the request in namecheap for API key was instant so seemingly automatic. You do have to whitelist the IP of the pfSense machine though... without having that IP in the whitelisted section of the namecheap API page results in an error when trying to issue the certificate. Other than that... all seems to work well - Thanks.

The HAProxy hint did the trick. For others searching, here is what I did on HAProxy config: Defined a specific backend pointing on 127.0.0.1 with the port defined on ACME config On the frontend added an ACL to forward the requests for which path starts with /.well-know/... onto the previous backend Seems to work fine. Don't hesitate to suggest any improvement though. In another hand I saw that it could be a small security breach, but I don't see the issue, I'd be interested to know. Thanks for the help.

@tlex forget it I found it :P [image: 1611251759218-2c8dc80d-eb3a-429c-8b8a-fecf788629d8-image.png] [image: 1611251720049-0f3482cf-3a71-4a17-82d4-5da3ab20a12b-image.png]