7 ms·
Assuming you are working on the dev machine, the process is as follows: 1. Buy a domain name. Certificates can only be issued if you have a real domain name. Y
by jabbany 5y ago
Assuming you are working on the dev machine, the process is as follows:
1. Buy a domain name. Certificates can only be issued if you have a real domain name. You can't get a certificate for "localhost" or "blah.localhost". You don't actually need to point this domain at your dev machine, you just need to own it. Let's call this domain "my-domain.com"
2. Follow the instructions for setting up the DNS-01 challenge. As a part of this, you'll need to provide credentials to allow LE to change your DNS records so it can renew the certificate automatically. Most registrars you can buy domains from will provide free DNS service and many will also provide API access to change DNS records. If this is the case, there's probably already support in LE for setup so you can just follow the instructions [here](https://github.com/acmesh-official/acme.sh/wiki/dnsapi https://github.com/acmesh-official/acme.sh/wiki/dnsapi) to provide the needed credentials.
3. Once the setup is complete, you should have a certificate (public certificate chain + private key) issued by LE and it should also automatically renew. Edit your dev server's configuration to use to these issued files for HTTPS.
4. Add something in /etc/hosts (or equivalent in Windows) like:
127.0.0.1 my-domain.com
5. Now load your dev environment by visiting `https://my-domain.com https://my-domain.com` on your local machine. It should work now with no certificate errors (green padlock). Congrats! You now have HTTPS for local dev at no cost beyond owning a domain + you can still use this domain to serve a real website (say hosted with some cloud host). The domain _does not_ need to point to your dev environment. In fact your dev machine doesn't even need to be connected to the Internet (as long as you can handle the renewals).
Advanced:
Now, if you want `my-domain.com` to also be productive, say, to serve your blog hosted on say EC2 over HTTPS, you can just edit your renewal setup. Add a post-renewal script that copies (e.g. scp) the renewed keys over to your EC2. Now both your dev machine (local) and your "production" server (remote) have the same key.
When you visit the domain locally, the /etc/hosts record circumvents DNS so you end up just hitting your local dev server which has the key info it needs to serve you HTTPS. When you visit the domain from a different machine, it would do a DNS query and end up hitting the remote instance. But since that instance also has the key info, it can also serve HTTPS.
Now if you want your dev machine to also be able to hit production, you can (1) when you setup LE in step 2, set it up so that it issues "*.my-domain.com" instead. (2) In step 4, use `dev.my-domain.com` instead of `my-domain.com`. This way on your dev machine, hitting `dev.my-domain.com` gets you the local dev server with a green padlock, hitting `my-domain.com` gets you the remote server, also with a green padlock. Both servers are sharing a wildcard certificate. The interesting part about doing it like this is that you don't need "dev.my-domain.com" to actually be a real DNS record. From the internet, nobody would even know that that subdomain exists.
- johnchristopher 5y agoAh, I see. Thanks for the detailed explanation.