Hi Mats - I've managed to get a bit further.  I decided to start from fresh. I created 3 backends like so:- ACME active localacmeserv Address+Port: 192.168.50.10 8126 no WebServers active THEMIS Address+Port: 192.168.50.189 80 no WebServers2 active GLAUCUS Address+Port: 192.168.50.185 80 no I created 4 Frontends :- HTTP-Edge Any (IPv4) 80 Any (IPv6) 80 Any (IPv4) 443 Any (IPv6) 443 Use "forwardfor" option - Ticked (Wasn't sure if this is needed or not) WebServers Shared Frontend option - ticked Primary frontend - HTTP-Edge ACL1 Host matches: no www.mywebsite.co.uk Actions Use Backend See below ACL1 Use backend WebServers I then cloned this frontend an setup an ACL for my second website to the Webservers2 backend.  This all seems to work. I created a final frontend for ACME like so:- ACMEFrontend Shared front end - ticked Front end - HTTP-Edge acme Path starts with: yes /.well-known/acme-challenge Use Backend See below acme Backend points to ACME backend. Attempt to renew Exchange 2013 SAN certificate which has enabled mail.mydomain.co.uk standalone HTTP server Port 8126 Enabled autodiscover.mydomain.co.uk standalone HTTP server Port 8126 [Fri Jul 7 00:20:11 BST 2017] Standalone mode. [Fri Jul 7 00:20:12 BST 2017] Standalone mode. [Fri Jul 7 00:20:12 BST 2017] Multi domain='DNS:autodiscover.mydomain.co.uk' [Fri Jul 7 00:20:12 BST 2017] Getting domain auth token for each domain [Fri Jul 7 00:20:12 BST 2017] Getting webroot for domain='mail.mydomain.co.uk' [Fri Jul 7 00:20:12 BST 2017] Getting new-authz for domain='mail.mydomain.co.uk' [Fri Jul 7 00:20:28 BST 2017] The new-authz request is ok. [Fri Jul 7 00:20:28 BST 2017] Getting webroot for domain='autodiscover.mydomain.co.uk' [Fri Jul 7 00:20:28 BST 2017] Getting new-authz for domain='autodiscover.mydomain.co.uk' [Fri Jul 7 00:20:30 BST 2017] The new-authz request is ok. [Fri Jul 7 00:20:30 BST 2017] mail.mydomain.co.uk is already verified, skip http-01. [Fri Jul 7 00:20:30 BST 2017] Verifying:autodiscover.mydomain.co.uk [Fri Jul 7 00:20:30 BST 2017] Standalone mode server [Fri Jul 7 00:20:36 BST 2017] autodiscover.mydomain.co.uk:Verify error:Invalid response from http://autodiscover.mydomain.co.uk/.well-known/acme-challenge/-G-QfC3FZa66VzIHB2rvanHig3CqBxJPONFSdO0QxLs The Exchange 2013 server is running behind the firewall. Any ideas? - This is hurting my brain!

I didn't mean that I submitted the user certificates to acme, I actually had the CA key "intermediate cert I guess" that I had as a result of a previous certificate certificate that acme returned to me for pfSense and about a half dozen other hosts downstream. Valid, no BS, I still have a legit key+cert that I can sign new public certificates with, it expires July 14. Anyway, I am just using self signed for everything.  I managed to find the intermediate and server certs I created in Cert Mgr in freeradius3 /usr/local/etc/raddb/certs. I compared the keys I downloaded from Cert Mgr against the keys there, sure enough. Used intermediate to create new server cert on second box counting down to avoid certs with same serial number. It would sure make things earlier, but I guess that's the point sort of, but if someone is smart enough to gain access to the OS then they are smart enough to find them, it just took me a lot longer because I am not very good at this. I will surface again shortly on free radius post, not having any luck with certificate authentication, pswd auth is good though. See ya there Jimp, thanks for the advice.

#3 - it really depends on the device; Usually it's a swap of the certificate and a graceful reload, but this depends solely on the device. If they're HTTP(s), you can also use HAProxy to do the encryption for you (see [1] below) so you have Clients –https--> HAProxy (PFSense) --http--> internal server This way, you only need to refresh the certificates on haproxy (note that internal communication is then unencrypted, so ensure your network is appropriately protected from sniffers) #4 No -- depends on the way you're doing letsencrypt certs. If you're using the http certbot, then yes you would need them since it requires a specific string at that server, but using Route53 should work without creating a public subdomain. #5 Yes a single certificate can have multiple SANs, but this does leak information. If "https://www.example.com" certificate has SANs for "https://something-secret.example.com" you can read this out of the certificate; I tend to create one cert per subdomain. Also don't forget that as of recently, Chrome is enforcing the RFC such that the CN= must also be in the SAN (so create a certificate for CN=www.example.com with a SAN of www.example.com) [1] http://loredo.me/post/116633549315/geeking-out-with-haproxy-on-pfsense-the-ultimate

it was a really good hint, but I done it in something other way. I has placed the acme rule as the first rule on HAproxy frontend settings and without 'not'. So if a client asks for $whatever/.well-known/acme-challenge then it goes to the local acme server… Now it works with all my ACME domains.

@jimp: You should change those keys ASAP, unless they are dummies. The keys names are valid - do exists. I'll see what happens ;) The password is, of course, a random string - not the real one. The key name can be chosen here : Services => Dynamic DNS => RFC 2136 Clients (the "key name" field) - it would be nice if the acme asked this key name instead of making one up. The acme package auto generates them - and they have to be the same in the config of 'bind' (the remote DNS server). Is it

What "load balancer"? Is it relayd or haproxy? If it is relayd - there is no hope, it cannot be done with ACME/Let's Encrypt. If you use HAProxy, it can be integrated with ACME/Let's Encrypt, there are many threads for this already.

Check the log it mentions in that last line of the output you pasted. It may have more info. I haven't tried making EC certs in ACME, mostly 2048-bit certs and those have always been OK. You could delete both the cert entry and the account key and generate/register new entries to start over.

Not yet, but it's something I'd like to add to the package eventually.

Setting up acme service on fw1 only, and having HA sync the certs to fw2 is working fine now. A few other hints: When adding the TXT records to your DNS, first check that each TXT record is live with these two tools: https://toolbox.googleapps.com/apps/dig/#TXT/     $ dig -t txt _acme-challenge.fw.yourcomain.something Note: it's safest to wait at least as long as the DNS timeout set on the TXT records. For ex. if you set the timeout to 7200, this means 2 hours. Any less than that and the old data may still be cached and cause an Acme verification failure. Once all the TXT records are live, go ahead and hit the Renew button on the acme cert. If the records are not properly set or not live yet you will get an error like this:     Verify error:DNS problem: NXDOMAIN looking up TXT for _acme-challenge.fw.yourcomain.something If you get this error, you'll have to hit Issue on the cert and delete then add the TXT records with their new values given by the acme service and wait long enough for the old TXT records to be deleted from DNS and the new ones to be added. It will not work to hit Renew once you get the verification error. Hitting Renew will just keep generating the error below and eventually you'll be rate limited by the acme web service and have to wait some time before Issuing a new cert. Unable to update challenge :: The challenge is not pending

Yes, that's exactly what I did. Port 80 on Wan nated to 5080 on a virtual IP (10.0.0.1). Wan/443 nated to 10.0.0.1/5443 Firewall rules that allows trafic from / to 10.0.0.1/508080 and 10.0.0.1/5443 Haproxy has listners on 10.0.0.1/508080 and 10.0.0.1/5443 I think you can do it without the nat too but since I had that part since earlier (once upon a time there was an issue getting Squid to bind to ports below 1024, hence a nat to a high port) I used it

Apparently they don't support nsupdate for ACME.  They do support the creation of TXT records, however I've decided to use SFTP instead.

Got it, thanks for the reply!

                $env['ALL_PROXY'] = "1.2.3.4:8888"; Adding the above line to acme_sh.inc in line 40 worked well for me. But since I don't know how to access global config to retrieve the system wide proxy settings, I had to hard code my proxy. Also the script should support wget as well. But this shouldn't be that big a deal for somebody used to pfsense packages. Any idea how to contact the maintainer?

@jimp: There might be some paid DNS providers out there that do RFC2136 but I'm not aware of any specifically. Dyn does… but it's not the easiest thing in the world to get working. At least it wasn't when I last tried it (which was before I started using pfSense, which might have been part of the problem).

What are the prospects for a freeradius3 package?  freeradius2 is already not getting fixes- only critical security patches-  so at some point folks will need to decide whether to create a new package or drop it entirely.

Dear PiBa, Thank you very much for communicating positively instead of just laughing out loud! It is indeed possible to upload any consistent certificate (regardless of CN and the like) to the cert manager and the acme package will overwrite it, if set up correctly, while retaining the private key. Hence, generating certificates suitable for private key pinning is well possible. There is one other issue I am trying to resolve: For some applications, I do need certificates outside pfsense, for example for starttls in my e-mail gateway. Instead of generating separate certificates for those servers via lets encrypt, it is conceivable to reuse the certificates generated and renewed by pfsense there. While I do backup the configuration nightly via ssh which seems to contain the certificates and keys in clear text, is there a convenient way to download (or export) individual certificates and keys via a bash script based on the content of config.xml? Regards, Michael

Or, be patient, there is a pull request pending to bring pfSense up to date with the latest acme.sh. https://github.com/pfsense/FreeBSD-ports/pull/318

Not seeing the same issue as you.  My log is below.  The error seems to be that it is not finding the API Key (Dynamic DNS ID) when connecting to DNSMadeEasy.  I have verified both the ID and Password and they are valid. [Thu Feb 23 09:01:23 AST 2017] Found domain api file: /usr/local/pkg/acme/dnsapi/dns_me.sh [Thu Feb 23 09:01:23 AST 2017] dns_me_add exists=0 [Thu Feb 23 09:01:23 AST 2017] APP [Thu Feb 23 09:01:23 AST 2017] 4:ME_Key='231XXXX' [Thu Feb 23 09:01:23 AST 2017] APP [Thu Feb 23 09:01:23 AST 2017] 5:ME_Secret='testforSecureXXXXX' [Thu Feb 23 09:01:23 AST 2017] First detect the root zone [Thu Feb 23 09:01:23 AST 2017] name?domainname=secure.accra.ca [Thu Feb 23 09:01:23 AST 2017] GET [Thu Feb 23 09:01:23 AST 2017] url='https://api.dnsmadeeasy.com/V2.0/dns/managed/name?domainname=secure.accra.ca' [Thu Feb 23 09:01:23 AST 2017] timeout [Thu Feb 23 09:01:23 AST 2017] curl exists=0 [Thu Feb 23 09:01:23 AST 2017] wget exists=127 [Thu Feb 23 09:01:23 AST 2017] _CURL='curl -L –silent --dump-header /tmp/acme/accra.ca//http.header ' [Thu Feb 23 09:01:24 AST 2017] ret='0' [Thu Feb 23 09:01:24 AST 2017] response='{error: ["API key not found"]}' [Thu Feb 23 09:01:24 AST 2017] name?domainname=accra.ca [Thu Feb 23 09:01:24 AST 2017] GET [Thu Feb 23 09:01:24 AST 2017] url='https://api.dnsmadeeasy.com/V2.0/dns/managed/name?domainname=accra.ca' [Thu Feb 23 09:01:24 AST 2017] timeout [Thu Feb 23 09:01:24 AST 2017] curl exists=0 [Thu Feb 23 09:01:24 AST 2017] wget exists=127 [Thu Feb 23 09:01:24 AST 2017] _CURL='curl -L –silent --dump-header /tmp/acme/accra.ca//http.header ' [Thu Feb 23 09:01:24 AST 2017] ret='0' [Thu Feb 23 09:01:24 AST 2017] response='{error: ["API key not found"]}' [Thu Feb 23 09:01:24 AST 2017] name?domainname=ca [Thu Feb 23 09:01:24 AST 2017] GET [Thu Feb 23 09:01:24 AST 2017] url='https://api.dnsmadeeasy.com/V2.0/dns/managed/name?domainname=ca' [Thu Feb 23 09:01:24 AST 2017] timeout [Thu Feb 23 09:01:24 AST 2017] curl exists=0 [Thu Feb 23 09:01:24 AST 2017] wget exists=127 [Thu Feb 23 09:01:24 AST 2017] _CURL='curl -L –silent --dump-header /tmp/acme/accra.ca//http.header ' [Thu Feb 23 09:01:25 AST 2017] ret='0' [Thu Feb 23 09:01:25 AST 2017] response='{error: ["API key not found"]}' [Thu Feb 23 09:01:25 AST 2017] invalid domain [Thu Feb 23 09:01:25 AST 2017] Error add txt for domain:_acme-challenge.secure.accra.ca [Thu Feb 23 09:01:25 AST 2017] pid [Thu Feb 23 09:01:25 AST 2017] _clearupdns [Thu Feb 23 09:01:25 AST 2017] Dns not added, skip. [Thu Feb 23 09:01:25 AST 2017] _on_issue_err [Thu Feb 23 09:01:25 AST 2017] Please check log file for more details: /tmp/acme/accra.ca/acme_issuecert.log