How to use LetsEncrypt certificates for local development
Since the communication over the internet is moving toward SSL, it became really frustrating for developers to setup their local environments in that manner.
On one hand, you want to replicate your local-environment as close to production as possible, and on the other hand (and most importantly) when writing mobile apps, the communication layer to REST-APIs requires you nowadays to use SSL encrypted endpoints (HTTPS).
There are methods out there, where you create a self-signed certificate and import them, but this most of the time does not work as expected.
Fortunately enough, there’s a workaround which I was able to get running on my local setup, using LetsEncrypt certificates.
The idea (in short)
Just use a LetsEncrypt certificate for your local setup, and create a DNS record to point the domain to your local machine.
So let’s say you’re the owner of example.com and you have a valid wildcard certificate for both, example.com and *.example.com .
This means you have a valid certificate which you can use for domains likelocalproject.example.com , localapi.example.com etc.
So, locally, you set up your nginx-server to listen to localproject.example.com and use the (valid) wildcard certificate which you obtained from LetsEncrypt. Then you simply point that domain (in your hosts file) to the IP of your local machine 127.0.0.1
How to do it?
I’ll give you a brief overview of the steps. Although, I’m going to mention some services as examples, you’re still free to chose the ones you’d like.
1. Get a cloud server
https://www.hetzner.com/ is not only cheap, but it allows you to spin up a server literally within seconds. The servers already have a public IP and you can access them instantly.
2a. Register a domain
You need to own a TLD domain, if you don’t already have one. In this example I’ll go with example.com . The easiest way is to get one at https://www.namecheap.com/
2b. Point the domain to the cloud server
If you register a domain, you need to point its primary and secondary nameserver (NS) to that of the provider where you have your cloud server running.
3. Grab the certificate
Now, if everything is set up correctly, example.com should point to the IP of your cloud server. Verify it with ping example.com
I won’t cover the process in detail, since there are already a few guides out there, on how to use certbot. The only thing you MUST do is to register a certificate for both domains example.com and its wildcard*.example.com
4. Use the obtained wildcard certificates on your local http-server
Now that you have your certificates, download them so that you can use them in your nginx or apache configurations.
Very simplified, your nginx configuration should look like. The important part here are the ssl_certificate and ssl_certificate_key
server {listen 443 ssl default_server;server_name project.example.com;location / {try_files $uri $uri/ /index.php?$query_string;}root /var/www/html;index index.php;include /etc/nginx/vhost.common.d/*.conf;ssl_certificate /etc/nginx/ssl/live/example.com/fullchain.pem;ssl_certificate_key /etc/nginx/ssl/live/example.com/privkey.pem;}
5. Point project.example.com to your local server
This is the final step. When you browse project.example.com you’ll be pointed to the public cloud server, you just created. But we don’t want that, at least not for project.example.com , but we sure do want it for example.com , since there’s where your public website is, and you still want to access it.
The easiest way to do this, is to modify your hosts file and add a line like this
project.example.com 127.0.0.1
If you’re very fancy like me, and you have dnsmasq running on your router, you can configure it like this
address=/example.com/192.168.1.10 (local IP of your machine)
This will tell dnsmasq to point all subdomains of *.example.com to your local machine. This way, if you’re developing websites, you can test them on other devices too.
Done!
Now when you open project.example.com in your browser, you should be greeted with the satisfying green lock, indicating that your connection to your local website is secure, yeaah! :-)
