4 ms·

Easiest way is to get a certificate for a subdomain of a domain you own, e.g. dev.example.com, and then point dev.example.com to 127.0.0.1 in your hosts file.

456hdsaq234g 8y ago
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.
gruez 8y ago
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.
- Macha 8y ago
  I read that as being about the actual public DNS, not your own local hosts file?
  - vbezhenar 8y ago
    Malicious network could forge DNS responses and direct user into fake server. HTTPS should protect user, because face server can't own proper certificate for that domain. But if private key is leaked, this attack could work.
    - icebraining 8y ago
      There are no DNS responses if the domain is in the hosts file.
philip1209 8y ago
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-domains/ https://blog.github.com/2013-04-09-yummy-cookies-across-doma...
- nikanj 8y ago
  A domain you own <-> a production domain. Our corp has corptech.com and a few similar ones for this purpose. A generic .com costs about nothing, so no point in running anything non-production on your primary domain.
ezekg 8y ago
Or use ngrok.io. :)
- tootie 8y ago
  Ngrok will route all your traffic over the internet.
shittyadmin 8y ago
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...
hackerpacker 8y ago
yup, works fine for a small trusted team or when you wear all the hats, also useful for troubleshooting occasionally.
_sdegutis 8y ago
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/ https://localhost.example.com:8000/ instead of http://127.0.0.1:8000/ 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

456hdsaq234g 8y ago

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.

gruez 8y ago

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.

Macha 8y ago
I read that as being about the actual public DNS, not your own local hosts file?
- vbezhenar 8y ago
  Malicious network could forge DNS responses and direct user into fake server. HTTPS should protect user, because face server can't own proper certificate for that domain. But if private key is leaked, this attack could work.
  - icebraining 8y ago
    There are no DNS responses if the domain is in the hosts file.

philip1209 8y ago

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-domains/ https://blog.github.com/2013-04-09-yummy-cookies-across-doma...

nikanj 8y ago
A domain you own <-> a production domain. Our corp has corptech.com and a few similar ones for this purpose. A generic .com costs about nothing, so no point in running anything non-production on your primary domain.

ezekg 8y ago

Or use ngrok.io. :)

tootie 8y ago
Ngrok will route all your traffic over the internet.

shittyadmin 8y ago

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...

hackerpacker 8y ago

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

_sdegutis 8y ago

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/ https://localhost.example.com:8000/ instead of http://127.0.0.1:8000/ 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