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! :-)