Recurring Firewall rule for LetsEncrypt
LetsEncrypt requries port 80/443 open inbound to allow renewal of cert. Is it possible to setup a firewall rule on a 90 day rotation to match LE's schedule so the port isn't exposed all the time??
Wouldn't say it requires - can you not use one of the dns methods of renewal?
Well I see where you're coming from but my Synology NAS does not allow that type of update. The function on it is pretty locked down ... The scheduling piece of FW Rules is close, but the recurrences won't line up.
who accesses your nas? I just put a cert I created myself on it, good for 10 years = done ;)
Unless you have browsers that access it you do not control, there is little need to go through all the hassle of acme for such https.. Make it 20 years if you want ;)
You can see its trusted by my browser... Zero outside access required ever ;)
As a side benefit - you can use rfc1918 address in your SAN... And even trusted if have to hit via IP in case your dns breaks down..
acme is slick and all - but I really don't see the fascination with it for stuff that is not accessed by the masses where they wouldn't trust your own signed certs.. Stuff like admin interfaces rarely should ever have need of such access. Also allows for use of non public domains.. But if you can for sure use public domains as well.. Since its your CA you can sign off on any fqdn you want, etc. etc.
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..
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.
maverick_slo last edited by
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 :)