What is an easy way to serve http: // localhost as https: // someOtherDomain?

Question

I am running a local development web server to check for code changes.

Often I have to check my local changes using remote services that can only connect securely to another domain.

eg. https://external1.com will only talk with https://someOtherDomain.com , but I need to check the integration of my new code changes with https://external1.com

While my tuned setup is working, it seems complicated and got a little better in order to configure the settings correctly. It seems to me that many developers will want to do the same, so my question is this:

Is there an easy way to proxy my local web server like https://someOtherDomain.com ?

EDIT: So maybe this should be set this way: does it exist on the command line or GUI tool that you can transfer the local port and domain name, and it reliably protects your local port over https://someOtherDomain.com - not Do you need to create a configuration or SSL certificate? Of course, it would be nice if the SSL certificate could be replaced using the configuration, if necessary, but by default it will work automatically using a predefined SSL certificate. And although I use Apache, I am looking for a solution that does not actually use Apache - it uses something else. What for? Since I want this solution to work well with any other web server that is used by people in our team, since we all run different stacks, and I would like one of us to safely serve our sites without setting up each web -server separately.

Here is my current setup for receiving my local web server and serving it at https://www.someOtherDomain.com

To check this locally, I was:

• edit my hosts file and add an entry to make www.someOtherDomain.com a pointer to my local computer, which, of course, starts my dev server. This makes it such that my local site is now available at http://www.someOtherDomain.com

  127.0.0.1 www.someOtherDomain.com

• Starting Apache with installing SSL Cert and mod_proxy to redirect all https requests to my local HTTP server, which makes my site available at https://www.someOtherDomain.com . Here is my Apache configuration for this:

   ServerName www.someOtherDomain.com <Location /balancer-manager> SetHandler balancer-manager </Location> ProxyPass /balancer-manager ! ProxyPass / balancer://mycluster/ <Proxy balancer://mycluster> BalancerMember http://localhost route=1 </Proxy> ProxyPass / balancer://mycluster ProxyPassReverse / balancer://mycluster SSLHonorCipherOrder On SSLProtocol -ALL +SSLv3 +TLSv1 SSLCipherSuite RC4-SHA:HIGH:!ADH # Rewrite all http requests to https RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} 

I run this on Mac, but I am also interested in linux solutions. I saw a different person in the Middle proxy that sounds like they will work with some configuration ... but I'm looking for something really simple to install and run - not just for me, but something that I I can tell the team members about, too, how we can all do this in the future.

IMPORTANT NOTICE. My local web server does not work on port 80, although I set it this way in the example above to make it simple. I understand that port 80 on the Mac is a little special, but I am very pleased with the solutions that work fine on all ports, but port 80.

Answer 1

I think mitmproxy can do this for you, at least on linux and os-x. I have not tried it myself, but this question seems to show how this is done. However, this is not a trivial program.

However, there are other approaches that I have used:

The first one is the easiest, create a DNS record for development.mydomain.com that points to 127.0.0.1 and one certificate for the (sub) domain in which you manage DNS. Distribute this certificate to all your developers. They still need to configure SSL, but they no longer need to create certificates. This has the added benefit that everyone develops against https://develop.mydomain.com , which allows them to share the configuration. For bonus points, create a DNS record for * .develop.mydomain.com and a wildcard certificate, and your developers may have different sites (for example, https://project1.develop.mydomain.com and https: //project2.develop.mydomain. com ) on the local computer. (Unlike what the Internet sometimes tells you, name-based virtual hosting works fine with SSL, as long as the certificate is valid for all named hosts). Since the domain is the same for everyone, you might consider getting a valid wildcard certificate to get rid of the warnings.

Unlike the solutions below, it works even outside the office network, which can make a difference when people work from home or at the client.

Based on this, you can also create DNS records for the internal IP code of the development machines (if fixed). This adds some work, but it means that the current work of the developer can be achieved by other users on the local network, which can be very convenient for demonstration, testing on mobile devices, etc.

Another option is to configure one machine on a proxy for all your developers. Create a DNS record pointing to the internal IP of this field, to something like * .develop.mydomain.com, the corresponding wildcard certificate, and configure this field once with the correct certificate. Now you can create a virtual host for each proxy server, and again all sites will be accessible throughout the local network, but this requires the developer to have fixed IP addresses (or host names added to DNS via DHCP). Combined with the ability of apache to include all files in a directory, the configuration makes it trivial to create a script that adds a new site based on the template. All you have to do is write a new file based on the requested subdomain plus destination and reload the apache configuration. This means that something like a simple PHP script can do what you want to do.

Answer 2

If you want to open your network on your local computer on the Internet, try Runscope Passageway , it’s easy to set up and “just work” (from experience).

Another ngrok option that I also used, but this did not always work for me.