From the article:

> "You might be tempted to work around these limitations by setting up a domain name in the global DNS that happens to resolve to 127.0.0.1 (for instance, localhost.example.com), getting a certificate for that domain name, shipping that certificate and corresponding private key with your native app, and telling your web app to communicate with https://localhost.example.com:8000/ instead of http://127.0.0.1:8000/. Don’t do this. It will put your users at risk, and your certificate may get revoked."

EDIT: oops, it's not exactly what you were talking about, since you suggested only pointing it to 127.0.0.1 in your own /etc/hosts file, so I don't think the article answers your idea directly

This sounds like a bad idea. You don't want private keys to a production subdomain being handed around teams. For instance, let's say you have dev.mybank.com. Somebody could trivially poison a DNS cache for a local system to redirect to their server, have a valid SSL key on the company domain, and implement a very real-looking phishing website for the company.

Another problem - controlling a subdomain could be used to steal login cookies from the main website. This is why Github moved Github Pages to a separate domain: https://blog.github.com/2013-04-09-yummy-cookies-across-doma...

Or use ngrok.io. :)

They discuss this in the article with some good criticisms of it.

You could maybe try something with a fully different origin, like mysite-dev.com...

yup, works fine for a small trusted team or when you wear all the hats, also useful for troubleshooting occasionally.

No, never do this. I will find your keys, and I will have your certificate revoked.

*also misread, I was considering the DNS case. Lightly, dont do this for the hosts file example either.

from TFA:

>It’s possible to set up your own domain name that happens to resolve to 127.0.0.1, and get a certificate for it using the DNS challenge. However, this is generally a bad idea and there are better options.