3 ms·

If you have a domain already, you can get a certificate for free from Let's Encrypt and just repurpose the certificate. You don't even have to run an out facing

If you have a domain already, you can get a certificate for free from Let's Encrypt and just repurpose the certificate. You don't even have to run an out facing HTTP server as they have a DNS-only challenge. I have a similar setup where I have something akin to "my-home.network" and manage a wildcard cert from Let's encrypt through a local cron job. My router intercepts all the DNS requests to the domain and returns local IPs on the local network. Machines that need HTTPS can get a copy of the wildcard key and do something like "hostname.my-home.network" and get HTTP.

johnchristopher 5y ago
I don't understand. You are getting a LE certificate for example.com (that you are putting where ?) then when your browser requests example.localhost it gets the certificate for example.com... but how (and how does the browser accepts a mismatching domain name certificate) ?
- 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 ago
    Ah, I see. Thanks for the detailed explanation.

johnchristopher 5y ago

I don't understand. You are getting a LE certificate for example.com (that you are putting where ?) then when your browser requests example.localhost it gets the certificate for example.com... but how (and how does the browser accepts a mismatching domain name certificate) ?

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 ago
  Ah, I see. Thanks for the detailed explanation.