Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In my experience, you don't want HTTPS for localhost, you want HTTPS for a server in the local network so that you can also test on other devices than the development machine.

A convenient solution in case you can control DNS at the local network level is to just get an ordinary certificate for a real domain (for example dev.mydomain.com) and have it resolve to that local IP.

Using your own CA is possible too, of course, but getting it installed on all the devices is a nuisance.



Using the DNS challenge with LE, you can create a wildcard cert that is valid for *.domain.tld. Now you need a simple local DNS server like PiHole to resolve any local domains to your local reverse proxy serving local sites with the wildcard cert and you're done. You only need internet connection on the user's browser to get the little green lock and when you generate the wildcard cert itself.


If you do it this way, you have to copy your actual server’s private key to your local machine (or even machines if you’re using several), though. That possibly increases the chances of it getting compromised.

I’d prefer getting a separate certificate for local.domain.tld instead.

Please correct me if I have a misunderstanding.


Wouldn't this need an internet connection to check the authenticity of the certificate ?

How do you make it work if you are working offline, say in a plane ?


Routing to an IP in the local network obviously doesn't work outside that local network.

Re-routing the domain to the local machine (by editing /etc/hosts) should work just the same. A certificate from a trusted CA can be validated without an internet connection, they are part of the OS/Browser distribution.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: