DEV Community

Running SSL on localhost

Brian Rinaldi on April 18, 2018

Before I get started with the how, I assume some of you may be asking, "Why do I care about running SSL on my localhost?" Well, there are some spec...

Read full post

Rémy 🤖 • Apr 19 '18

Other method:

Get a domain, let's say foobar.com
Get a wildcard for *.foobar.com
Setup a local nginx (on port 443) with that certificate on all vhosts
For each project, create a vhost that proxies back to your app. Say app1.foobar.com is a proxy to localhost:4000
Add 127.0.0.1 app1.foobar.com to your /etc/hosts

Daniel Lo Nigro • Apr 24 '18

Let's Encrypt makes this pretty easy, and free. What I usually do is have localhost.foobar.com resolve to 127.0.0.1, and either have a Let's Encrypt wildcard cert, or a cert specifically for localhost.foobar.com

Nico • Apr 24 '18

Now this is a nerdy, overcomplicated solution that I like.

Daniel Lo Nigro • Apr 24 '18

Note that ngrok goes over the internet, so it's pretty excessive/slow for local development. The request will go over the internet to ngrok's servers, then back to your system.

What I usually do for local development is configure localdev.example.com (where example.com is the site for whatever project I'm working on) to resolve to 127.0.0.1 on my DNS server, and then use Let's Encrypt to create a real cert for localdev.example.com.

Electrode Cathode • May 17 '20

I'm so interested to learn more about this.

Daniel Lo Nigro • May 17 '20

You can use Let's Encrypt DNS validation to get certificates for servers even if they're not accessible over the internet (for example, for internal servers or local development). Certbot and acme.sh both support this and integrate with various DNS APIs to handle the validation, or you could manually set the required TXT record.

I use acme-dns to handle the validation, but it takes a bit of setup.

Cary Reams • Apr 19 '18

I like where you're going. Wanted to offer some two other options to skin that particular cat, addressing at least the three motivations you identified: VMs and Containers.

If you want me to support the suggestions, let me know in a comment. Otherwise, I'll just consider it out-of-scope or beyond the intent of this post.

Brian Rinaldi • Apr 19 '18

Go for it. I barely skimmed the surface of possible solutions...just covering the use-cases that I needed for my particular work.

Cary Reams • Apr 20 '18

Sure.

I prefer the VM (or container) approach because, in addition to addressing the three items you identified, it generally allows me to nail down a test environment as close to the production server as I care to make it -- without unnecessarily constraining my dev machine.

By offloading the test environment to a VM, I'm free to upgrade my dev machine through various OS/distro upgrades, without compromising the test environment integrity -- the VM continues to run CentOS 6 server, while my dev machine matures from Ubuntu 12->14->16(->18 next weekend) LTS versions.

Similar advantages may be had with containers - with the added advantage that they can also leverage shared OS for a smaller footprint if multiple servers are needed.

With later versions of apache, getting SSL up and running is as simple as linking the sites-available conf to the sites-enabled directory. The provided snakeoil certs make it a breeze.

There's a bit of a learning curve for the VMs, but its been well worth it.

Good luck and please keep blogging.