first, let me state that I’m totally aware that Let’s Encrypt will not issue a certificate for “whatever.local”, and why it won’t do that.
But would the following scenario work to provide such a device that is only reachable in a private, local network and which uses mdns/avahi/zeroconf to announce its name in the “.local.” domain with a valid HTTPS certificate?
set up a (public) DNS CNAME entry for “mydevice.mydomain.net” that points to “mydevice.local”
If I’m not mistaken, the last step should (at least on a reasonably modern client) resolve “mydevice.mydomain.net” to “mydevice.local” (i.e. get the CNAME from public DNS), then resolve “mydevice.local” to whatever IP the device has at the moment (via mDNS), and finally connect to the device and see the expected certificate for “mydevice.mydomain.net”.
Is your question whether you’ll be able to use the http-01 or tls-sni-01 challenge types with a domain name that’s a CNAME to a .local (or otherwise private) domain? The answer to that would be no, as Let’s Encrypt performs the domain ownership validation from their servers (not the client), and that server won’t be able to resolve a private domain name.
If you’re just asking whether this network/DNS setup will work in general (assuming you’ve already obtained your certificate via dns-01 (or some other means)), I think that should work, though there are some DNS resolvers who filter out responses including reserved/private IPs, which might be relevant here. This is a DNS thing though, TLS doesn’t really care about these circumstances.
Well, I could temporarily set up a public IP for the name during certificate (re-)validation and use one of the HTTP based challenge methods, but that would be way more complicated.
So, yes, doings it with a DNS based challenge is the only sensible way.