Hi There,
I am new to LE, and I really like this easy way to implement SSL.
I am planning to use LE for a few of vagrant boxes running on my local computer’ virtualbox. Generally, the DNS record is not published.
From my understanding, the DNS verify is crucial for LE authentication so I am wondering is there any workaround that I can use LE for my internal dev environment ?
Thank you,
There isn’t a workaround. LE needs to verify the domain you are requesting and does so by public DNS lookups and accessing the server to verify a special file.
Most development environments should be fine with self-signed certificates as very few people will be accessing them.
If you don’t have to prove authenticity to third parties over insecure channels, why do you want to use a third-party CA in the first place?
If you are in your own environment, use self-signed certs or your own CA.
Outside CAs are a necessary “evil” (in the trust chain) if you have to deal with unrelated third parties. If you can, you should always contain trust to an absolute minimum.
Does this mean we cannot use LE in development?
You can use LE in development environments if you want to. We’re actually doing this where I work to simulate production setups for our QA testing.
Keep in mind that you’ll need to use a real valid public domain for getting the certificate and be able to validate using one of the supported methods. You don’t need to make the environment public, however, as you can use the DNS-based verification method.
Generally, using “real” validating certificates for development is overkill in all but a few circumstances, however.
Say I want to simulate a prod environment in vagrant using ubuntu and nginx as the reverse proxy.
Does this mean I would need to expose my development environment as a hidden production server to test it properly?
No, you don’t have to expose the environment externally. You do, however, need to use a valid domain name so you can at least validate the certificate request (possibly using the DNS-01 method).
For example, you could use something like “internaltest.example.com” as the name and point the IP to 127.0.0.1. When you request the certificate, you’d need to use the DNS-01 method to verify since LE obviously won’t be able to connect for the other types of verifications.
You could not, however, try and get a certificate for “localhost” or “test.localdomain” or “test.whateverman”. Basically, any fully qualified name that isn’t resolvable publicly.
So I would have to update my /etc/hosts file correct?
vagrant@vagrant-ubuntu-trusty-64:~$ cat /etc/hosts
127.0.0.1 localhost
127.0.0.1 internaltest.example.com # <<<< ? Like this?
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
How do you specify the method to run DNS-01?
I think from the other thread that @motoko didn’t realize that you (I think) don’t actually have a publicly-visible domain name to use with the certificates. The literal name “example.com” won’t work; it’s a placeholder name used in examples, which has to be replaced by a name that you actually do control.
We have to really distinguish two things here:
To issue a certificate, Let’s Encrypt does not have to actually be able to connect directly to your server, nor does your server have to have a public IP address. You can get a certificate for an internal-only service, or one that you run on your local machine only, or behind a firewall. Only the DNS-01 method will allow creating a certificate without making an inbound connection of some kind.
However, to issue a certificate by any method, Let’s Encrypt does have to confirm that you really control all of the domain names that will be listed in the certificate, and those names must be publicly-visible names in the global DNS. Let’s Encrypt won’t ever believe or rely on or know about what you write in your own /etc/hosts file.
hi @rlam3
there is another way of doing this (I have done this for a few dev shops and it works ok)
A) lets say your live site is supercoolapp.io and you don’t want change DNS or touch your production servers
B) go to godaddy and buy a supercoolapp.xyz (1.99 per year)
C) configure this to work with cloudflare (easy, cheap and fast DNS)
D) issue a certificate (e.g. test.supercoolapp.xyz staging.supercoolapp.xyz)
E) configure your web servers to listen for domains above
F) configure your internal dns to point the above domains to your test servers
Andrei