Correct, I pointed it out merely as a workaround. It is not strictly necessary as long as you're willing to use different URLs for internal/external access. The last solution would not require split-horizon DNS at all, but is the most complex to implement.
I pointed it out because you specifically mentioned localhost, and this restriction doesn't apply there. The last solution works for what you describe here.
From Let's Encrypt?
You can use dns-01 verification to avoid having to open port 80/443 on the client's IP. You have to run your own DynDNS setup on a domain you own and that is either on the Public Suffix List (so that the rate limit doesn't apply) or that is otherwise whitelisted from rate limiting (something that will be implemented in the future).
Your software would update your DynDNS service with the correct LAN and WAN IPs so that you can resolve internal.userid.yourddns.com to the LAN IP and userid.yourddns.com to the WAN IP.
This would essentially support every client except those with DNS resolvers that scrub internal IPs (which, IIRC, is true for plex as well). UX would be slightly worse because of separate internal/external URLs. This could be hidden behind the scenes if your software is accessed via some centralized site similar to https://app.plex.tv/.
This would probably be a good topic for a more detailed blog post, may I ask what project this is for?
// edit: nvm, just found it at the top of this thread. 