Yes, reopening this. It was discussed under help here:
And rejected as not possible.
I wish to revise that to “Not currently possible” and raise the ante on this to a feature request upon certbot, for it is easily technically possible (certbot/letsencrypt only need to record and alternate .lan name in the otherwise validated cert).
In face I will raise it one notch further and suggest .local (also commonly used for LANs) be supported.
In support of this I offer the following use case which I contend is not uncommon, plausible quite common.
I run a LAN on which I have some cloud services. There are certified and I can access them from the WAN using HTTPS fine and am trusted. But if I am working on the LAN itself, using the WAN domain name causes hairpin of requests and data flow out of the LAN and back into the LAN probably from the first hop on the WAN that can route back to our WAN IP address which WAN name points to. And so to access these services in the LAN we use a .lan name resolved by the DNS on our LAN to a LAN IP. That also works fine. BUT the cert is not trusted/valid for that name and so not everything works. Which is a problem.
Certificates support alternate names. And while .lan and .local are not IANA TLDs, they are well known (reminiscent of .well-known) local domains. As a consequence they cannot be verified from WAN access they can only be verified by an agent on the LAN. As letsencrypt isn’t on the LAN and given LANS are by definition rather small (in comparison toe the WAN) and managed by a sysadmin who has oversight over the LAN, it suffices that said sysadmin nominate the alternate .lan or .local name for the IANA TLD. If teh IANA TLD validats (with a challenge) the .lan or .local name can tag along, be trusted on the word of the sysadmin running certbot and added to the cert as an altname before it’s encrypted.
To wit, I argue this feature will boost the utility of certbot significantly in avoiding hairpin data request.