I’m in the middle of switching my DNS servers from Namecheap to Cloudflare, just waiting for the changes to take effect (up to 24 hrs). Plan to try authentication using txt record. Not sure why you’re seeing multiple A records? I have one A record and a couple of CNAME’s. Maybe something due to the changing DNS servers? I do see a bunch of MX records which seems strange since I’m not running any email on this site. Currently just planning to use it for VPN. Maybe the MX records are just placeholders?

thanks for that informative feedback, will pick up some of your suggestions as soon as I find the time to continue that project. Edit: You use SSL-Offloading for all VMs, OK, same as here. My additional wish is to encrypt the traffic from HAproxy to the backends as well, with a separate SSL-cert with long lifetime, ideally also generated/refreshed on pfsense. So the config of these backends is my current issue.

AFAIK the NIST guideline sounded like "Drop the algorithmic complexity song and dance No more arbitrary password complexity requirements needing mixtures of upper case letters, symbols and numbers. Like frequent password changes, it’s been shown repeatedly that these types of restrictions often result in worse passwords." Yes it was about that you can not require a complex password with short length over much more longer password but without any complexity. The length is limited by freeDNS and I am sure in case of limited length complexity always wins  ;)

Nice Jimp!  Quick work, thanks.

I remember posting somewhere on this forum about this ACME package that even a space " " in the name (field) will give a situation were the account key exists, but can't be show or edited anymore …

ACME only updates TXT records, it has nothing to do with dynamic DNS for regular A/AAAA records. The package does not share any code or functionality with dynamic DNS in the base system. The ACME package only asks for what the acme.sh dnsapi script for Route53 wants (dns_aws.sh) and that is only the AWS Access Key ID and secret.

No love. As I mentioned, I confirmed  www.foo.com/.well-known/acme-challenge isn't redirecting, but the renewal is still failing. Oddly, the error.log shows this: AH00112: Warning: DocumentRoot [/var/lib/letsencrypt/tls_sni_01_page/] does not exist [Fri Oct 27 09:47:19.831094 2017] [ssl:warn] [pid 35459] AH01906: b0e858dd145cedac69bf9f2ff813bdce.4aff4cc0f637d578fdb7e19834ea33dc.acme.invalid:443:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?) [Fri Oct 27 09:47:19.831626 2017] [mpm_prefork:notice] [pid 35459] AH00163: Apache/2.4.18 (Ubuntu) OpenSSL/1.0.2g configured – resuming normal operations [Fri Oct 27 09:47:19.831636 2017] [core:notice] [pid 35459] AH00094: Command line: '/usr/sbin/apache2' [Fri Oct 27 09:47:26.617630 2017] [mpm_prefork:notice] [pid 35459] AH00171: Graceful restart requested, doing restart [Fri Oct 27 09:47:26.657069 2017] [mpm_prefork:notice] [pid 35459] AH00163: Apache/2.4.18 (Ubuntu) OpenSSL/1.0.2g configured – resuming normal operations [Fri Oct 27 09:47:26.657091 2017] [core:notice] [pid 35459] AH00094: Command line: '/usr/sbin/apache2' If I can figure out how to force a renewal, I'll test on my other host and see if I can replicate it.

Thank you. And please do not understand me wrong - i'm only want to help community.

What exactly did you enter for the SFTP server? It should be sftp://x.x.x.x not just a bare IP address. See https://doc.pfsense.org/index.php/ACME_package#FTP_Webroot

@doktornotor: https://github.com/pfsense/FreeBSD-ports/pull/420 It says it needs testing. I could do that if someone points me to the documentation on how to do that.

That's great, thanks.

The ACME package is based on acme.sh which already take care of cloudns.net (https://github.com/Neilpang/acme.sh). I am in the same situation but I am using GandiLive. Therefore, would it be possible to bump the ACME package to the latest acme.sh version?

@remis4: So the ACME action section has THE example i was looking for to restart haproxy. That's simple enough of a fix when my cert renews. On another note, I wrote a script that works as a cron job in pfSense to update GoDaddy A records. https://github.com/nkleck/Godaddy-DDNS.git Its a bit simpler than some of the other options out there, but its written with libraries already available in pfsense FreeBSD python. So you dont have to worry about installing requests, its using urllib2  :-X . The usage is pretty straight forward in the cron job. 2 * * * * root /usr/local/bin/python2.7 /home/<your user="">/godaddy-ddns.py hostname.domain.tld It also restarts HAProxy at the end of it if a change was detected. Not sure if its needed, as I found today the 'Reload behaviour' checkbox in HAProxy that might do the same thing.</your> hi, i saw you script for the DNS A record on Godaddy, is it possible to make it work to change the @ record? i'm just to dumb to figure out how to change it :|

Got it :-) Just mkdir /usr/local/www/.well-know/ mkdir /usr/local/www/.well-know/acme-challenge and use stand-alone HTTP server in Domain SAN list

Awesome, thanks! i'll give that a shot and see how that goes.

The actions list will call a shell command as-is. Whether or not that will be able to copy certificates to other hosts depends on the rest of your configuration. You would test/debug that like any other shell script. By default the certificates only exist in the pfSense configuration file. Unless something reads them from there and writes them out, a shell script could not easily obtain them. For example, if you have the certificate set to be used by the GUI and followed the example to have the actions list restart the GUI, it would write the certificate out to /var/etc/cert.crt and a shell script run after that could copy that file. Otherwise it whatever script is run would (probably easiest if it's PHP) would have to parse the config.xml and read the certificate and then write it out somewhere. Eventually we might include something like Anvil to help with this.