Method = Restart Local Service, Command = ipsec (This may be enough to refresh the IPsec config, but it's not a full restart)
Method = PHP Command, Command = ipsec_configure(true) (This may fail since it may not have the right required libraries)
Method = Shell Command, Command = /usr/local/sbin/pfSsh.php playback restartipsec (This may fail since the ACME script which starts the command is PHP, and launching pfSsh.php from within PHP doesn't always work)
Method = PHP Command, Command = file_get_contents("/etc/phpshellsessions/restartipsec") (If the shell command fails, this should work instead)
Update: When I try to setup Dynmaic DNS RFC 2136 updates (just to test) I noticed this error:
/services_rfc2136_edit.php: The command '/usr/local/bin/nsupdate -k /var/etc/nsupdatekey0 /var/etc/nsupdatecmds0' returned exit code '1', the output was 'check-names failed: bad owner '_acme-challenge.<doamin.com>' syntax error'
I briefly looked up solutions but then mentioned puny-code and I still don't quite understand. Going to keep looking into this.
CodenSnap, (I now this is an old thread but in case this might help others)
I'm working on a similar setup (domain registered with Google and hosting DNS with either CloudFlare or AWS Route53). In domain.google.com there is an option to switch your DNS to "manual". Once switched to manual you have the option to entered to DNS servers for for your domain. I can enter either Route53 or ClouldFlare. In either service I then add my DNS instance and create my Zone. From there I was able to use Dynamic DNS, add A, AAAA, & TXT, records ,etc, with either DNS provider. Have not yet got the ACME client to work. But best-I-can-tell there is no negative with registering a domain with Google and then hosting your DNS with another provider.
DNSSEC is not working for your domain : check http://dnsviz.net/d/poblacionqueretaro.gob.mx/dnssec/ or https://dnssec-analyzer.verisignlabs.com/
Btw : you are updating against Cloudfare, and using "bind" locally. Why ? Is bind a master name server for your zone ? Slave name server ? I don't understand the relation.
edit : I looked at your message again.
You 'bind' is set up as a master for your domain .... but you disallow zone transfers. Wtf ??
How can a slave sync then ? Do you have just one name server for your domain ? That can't be true, you break everything then, 2 is the minimum.
This is resolved. The cause was a DNS configuration error outside the scope of Acme - sorry. I have had difficulties setting up dnssec. In so doing, I did modify the SOA entry. As a consequence, my slave DNS servers did not track master DNS server changes. Hence, Acme verification had no chance to work.
at least not in my case ;-) This pfsense box works as server in my network and not as router/firewall. But fully agree that Cert/Key handling should not take place on a firewall.
I use acme.sh on my servers for quite a while now. Works like charm, but I like the GUI to manage the LE stuff ;-)
You could write up a feature request https://redmine.pfsense.org/projects/pfsense/issues?set_filter=1&tracker_id=2
I opened a feature request: https://redmine.pfsense.org/issues/9725
I've completed my small php script and it seems to work well.
This is the result in case anyone needs it:
// -- CONFIG
$certname = 'lan.domain.com'; //a registered FQDN in cPanel with acme let's encrypt enabled (wildcard cert)
$pfsense_cert_id = 1; // certificate id in pfsense to overwrite. (The correct ID can be found by hovering over an icon in the cert manager or by looking in the config file.
$ftp_server = 'ftp.domain.com'; //ftps location to your domain (cpanel).
$ftp_user_name = '';
$ftp_user_pass = '';
$server_file = '/.cpanel/nvdata/letsencrypt-cpanel'; //download file used by cPanel holding every certificate (in JSON format).
// -- PROGRAM
$conn_id = ftp_ssl_connect($ftp_server);
$login_result = ftp_login($conn_id, $ftp_user_name, $ftp_user_pass);
$dataLoaded = ftp_get($conn_id, "php://output", $server_file, FTP_BINARY);
$data = ob_get_contents();
die("There was a problem downloading the json data from $ftp_server");
$jsonData = json_decode($data, true);
$cert = $jsonData['certs'][$certname];
die("Certificate with name $certname not found");
$config['cert'][$pfsense_cert_id ]['prv'] = base64_encode($cert['key']);
$config['cert'][$pfsense_cert_id ]['crt'] = base64_encode($cert['cert']);
//echo 'Certificate:', PHP_EOL, $cert['cert'], PHP_EOL;
//echo 'Key:', PHP_EOL, $cert['key'], PHP_EOL;
echo 'New certificate for ', $certname, ' is valid untill ', gmdate('r',$cert['cert_expiry']), PHP_EOL;
I've uploaded the file (named sslupdate) to the /etc/phpshellsessions directory in pfsense and I added the following cron job (through the cron package):
I just reverted back from Version "2.5.0.a.20190806.1707 i" to the snapshot using 2.4.4-RELEASE-p3 (amd64) version. I upgraded the acme to version 0.6_1 and tried to issue a certificate with the staging servers of letsencript. Everything works well without no problem at all !!!
Then i tired a copy of some file to the tmp of PfSense i.e.
scp test1.txt email@example.com:/tmp/
the file got copies and its content to tmp. All good there.
Now i need to upgrade to 2.5.0.a.20190806.1707 again and see if i will be able to replicate the problem with the file copy.
@kiokoman Yeah, you're right =) But anyway, I wasn't able to make some reasonable solution, so I've just created tiny VM guest with alpine linux, lighttpd and nfs-client, and I'm passing my .well-known challenge through "local webroot", but I'm putting there appropiate path for my NFS share + ballast ( </path/to/share>/.well-known/acme-challenge/ ). pfSense comes already preloaded with nfs, all I needed was just enable it through /etc/rc.d.local. HAProxy does rest of the job ( frontend for path match looks like that ---v )
HAProxy Frontend rules ( I've got it implemented with http->https redirect, except for .well-known =3 I was pretty suprised it came on my mind )
HAProxy Frontend rules
So that's my hotfix solution, but I'm curious for any other ideas ))
Let's Encrypt won't publish a list of possible sources as that would let someone game the system to obtain certs for domains they do not own from systems they have compromised in subtle ways (e.g. port forward all LE servers to fakeserver, but let other connections go through to realserver)
They could reach you from anywhere in the world, there is no way to predict the source. You have to allow connections from anywhere during that timeframe.
If that bugs you, then switch to a DNS-based method that does not require any inbound access whatsoever.
We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.
Subscribe to our Newsletter
Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.