3 ms·
What's interesting is their proposed scheme would already work with Lets Encrypt acting as the CA. I'm not sure why they think they need to have a subordinate C
by agsdasdg 6y ago
What's interesting is their proposed scheme would already work with Lets Encrypt acting as the CA. I'm not sure why they think they need to have a subordinate CA.
Keep the goofy ssh key based dns registration and provide users with a SSH-hash.luci.openwrt.org A record pointing to their public IP, then just let LE and ACME do the rest.
Mikrotik's RouterOS (and I'm sure other commercial router distros) already provides me this in the form of <stringOfHex>.sn.mynetname.net (though I have to do the ACME myself via script or from a host inside the network).
- josteink 6y ago> Keep the goofy ssh key based dns registration and provide users with a SSH-hash.luci.openwrt.org A record pointing to their public IP, then just let LE and ACME do the rest. This presumes you only have one OpenWRT-device and that it’s on a public IP.
- kelnos 6y agoThere's even a way around this: the DNS record can point to a server that the OpwnWRT people control, and use ACME to get that server issued a cert. Then the cert can be passed to the router that's running OpenWRT. And after that, the DNS can start pointing to the router's private LAN IP. Repeat every time the cert needs a refresh. To mitigate issues while the refresh is happening, the DNS server running on the router could intercept requests for its own name. Of course that doesn't work if the client on the LAN is pointing directly to an off-LAN DNS server, so it's not a perfect solution. But presumably, with a low A-record TTL, "downtime" of the local DNS name could be kept to a minimum, and the cert renewal could be scheduled to take place in the middle of the night. Not sure if any of this process would violate LetsEncrypt's policies and get the account banned, though.
- kardos 6y agoYep it sounds like a workaround that could work, but that is a lot of moving parts to keep oiled.