How to generate certs for local testing domain .test


#1

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!


#2

.test is a reserved TLD that cannot be resolved on the public internet.

Since it is not possible to demonstrate control over such a domain, Let’s Encrypt would not be able to issue a certificate for it.

It should not be possible to get a .test certificate from any CA, in theory:

2015-11-01 7.1.4.2.1 Issuance of Certificates with Reserved IP Address or Internal Name prohibited.


#3

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.


#4

@_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.

Thank you!


#5

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. :sweat:

Incidentally, .test certificates exist, both old and more recent and misissued.


#6

And to reinforce your point, they’ve all been revoked, as required by the BRs.


#7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.