Hi, we’re using letsencrypt via Docker compose (jwilder/nginx-proxy + jrcs/letsencrypt-nginx-proxy-companion). For a production, it works really great, but I would like to generate also certificates for local development. We’ve been using .dev, but now it can’t be used due to Chrome’s HSTS preload, so we’re using *.test domain.
I can generate certificates manually, but it would be great to generate via lets encrypt. Any clue? Thanx a lot!
The easiest way I’ve found is this: we use the DNS-01 challenge to generate certificates for dev.example.com, and have public DNS mapping it to the server’s address on the LAN (or even 127.0.0.1). A slightly more complicated version is to have the computer use a local DNS server, which remaps dev.example.com to the IP you need on the lan/computer.
@_az - I’m sorry I wasn’t explicit - sure, I know that .test is reserved TLD and especially for testing, together with a few others: https://tools.ietf.org/html/rfc2606 - It’s sad what happened with .dev domain, used by millions of developers around the world, but it’s a different story.
And it’s absolutely clear that Letsencrypt must verify domain before it issues a certificate. But my point is that it would be really big time-saver to have an exception just for the .test domain and that this certificate can be issued WITHOUT domain validation.
Why?
Letsencrypt, Docker and lot of other projects are about simplifying things. Look on this popular container: https://hub.docker.com/r/jrcs/letsencrypt-nginx-proxy-companion/ - over 10 million pulls - it means, that all those developers involved are fighting somehow with situation, that they need to simulate HTTPS on their dev environments, and coz letsencrypt can’t be used, there must be a lot of workarounds, manual creation, it’s more complicated with the repositories, et.
I think that it can bring only good things without sacrificing security.
@jvanascoand thank you, currently, we have also running local DNS servers, which are handling *.test domains and returning local address, which is then handled by local Docker environment. Only one thing is, that now I have to manually generate all the certificates for the *.test domains. It’s even more complicated, coz I found that for some Chrome’s bloody reasons it’s not possible to generate one wildcard certificate for *.test domain (coz there cannot be wildcard certificate for whole TLD domain, it’s a bit logical), but it means generating tons of certificates for each testing domain/environment, which is exactly the opposite to simplifying the things.
Under the Baseline Requirements, Let’s Encrypt – all CAs – have zero latitude to issue real certificates for fake TLDs.
Whether or not it’s a good idea, it’s not something a CA can unilaterally do. The most they can do is push for regulatory changes.
I don’t know if something like this was debated at the time internal names were banned, but I don’t think it would pass now. I expect the browsers would resist anything that smells like making the rules more complicated and reducing security.