Recurring Firewall rule for LetsEncrypt
-
Yep, I have CertMgr setup on my internal domain as well...however, this is public facing to share w/ clients.
-
I take it public facing on some odd ball port then? Yeah automating such access most likely PITA with acme then and their 90 day requirements.. If they are "your" clients and you have given them access to your site via controls and info - why not just have them trust your CA as well? 1 time pain vs pain every 90 days of renewal of cert.
Or just bite the bullet and get official cert from public CA, this will be good for a year or 2 and not have to go through the 90 renewal nonsense with acme.
-
Yep oddball port, I get where you're going...just thought an enhancement to scheduling the FW rule would be nice to have. I have thought thru those options...I'll just put a calendar invite for now to do my update manually.
-
you might look to posting a bounty or who develops acme package - not sure if that is @jimp or not? In adding such an option for some future release of the package to enable a rule before it checks for renewal and then disable. Such a post prob good in the package area - I think acme has its own category.
Other option might be to just allow 80/443 for the IPs that acme would be coming from.. Might be a lot? But you would hope they would post a netblock listing you could enable on your rule.
-
There isn't a good way to do that at the moment. You can't predict the source of ACME checks as they deliberately do not publish their origin since they say that would lead to a potential security problem. Someone could hijack a site in a non-obvious way and redirect only the ACME checks to a different server to obtain a cert, etc, etc.
Also at the moment there is no port 443 choice as TLS-SNI was deprecated. They just turned on TLS-ALPN but acme.sh hasn't added code for that yet.
If you do standalone mode in the ACME package, you could run it on a random localhost port (e.g. localhost on port 8888) and then setup a port forward for WAN:80 to localhost:8888. The ACME standalone server will only run during the verification attempts and other times anyone hitting WAN:80 will be rejected since nothing is listening there. Or forward port 80 to a dummy web server with nothing else on it and then setup sftp verification in ACME so it can dump the challenge data there when needed.
Naturally using a DNS update method would be 1000% better if you can. Zero issues with that so long as your DNS server or provider has a supported update method in the ACME package.
-
Great info @jimp thanks...
He seems to have secondary problems with this running on his nas and being limited to prob what nas version of acme can do. But I would think he could prob run acme on its own in a docker? If he is on synology I would think so, etc
edit: Sure looks like you can use dns on the acme.sh for synology.. Just not in any gui.. I have a few domains I guess I could play with..
https://warmestrobot.com/blog/2017/4/10/lets-encrypt-synology-dsm-6x
It's from 2017 so stuff might have changed for sure.. But there is a dns section listed there.
-
Let the ACME package handle the cert checks, enable the option to write the certs to a file, and then script something to copy them from /conf/acme/ over to the NAS via scp maybe. Still easier than trying to deal with the other parts.
If you must allow it on a schedule then a NAT rule without an associated rule, set to a schedule that matches the ACME update window should work in theory. For example, if the NAS updates ACME at 4am each day, then add a NAT rule on its own then a separate firewall rule. The schedule for the firewall rule to pass into the NAS would only need to be active for :00 to :15 that hour. Not ideal but still better than nothing. I really would try to avoid that though unless it can run on an alternate port on the NAS. I wouldn't ever want to expose a NAS web interface directly to the Internet.
-
I don't think he needs to go through all that - I edited link above looks like you can do dns with the acme.sh on dsm 6.x
-
Thanks for all the info - I'll get to diggin.
-
hmm
What about haproxy with combination of standalone HTTP server method?
This is how I do it for all my hosts.
Acme starts http server on localhost and on haproxy I have backend on that same ip and port 80.
Then again on haproxy there is ACL path starts with /.well-known/acme-challenge and it gets redirected to backend which is actually acme standalone server :)
