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

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