5

During development, test, and staging, we have a variety of docker servers that come and go as virtual machines. Eventually, the docker images under this process will get to a customer machine with a well-defined host and domain names. However, until that point all the machines are only our internal network. In the customer-deployed environment it is the intent that ALL 'http' communication be it internal or external is via HTTPS. Given this intent, it is highly desirable to wire all the containers up with useable/testable SSL certificates.

One, two, three, and on and on of MANY docker/letsencrypt/nginx tutorials describe how to do this at the end, but not during the development process. Does anyone know if such a focused setup is possible? Do I need to make the inner-most docker container (ours happens to house a Tomcat webapp) have a public domain? Or is this just completely impractical [even knowing this for certain will be a big help!]? If this usage is possible, might anyone know (or have) specifics on what needs to be done to get this functional?

UPDATE

In case it wasn't clear from the above. I want to ship Docker containers one of which will probably be a letsencrypt/nginx proxy. There are many to choose from on Docker Hub. However, I can't figure out how to setup such a system for development/test where all the machines are on an internal network. The certificates can be 'test' - the need is to allow HTTPS/TLS, not a green lock in Chrome! This will allow for a huge amount of testing (ie. HTTP properly locked down, TLSv1.0 turned off to avoid certain vulnerabilities, etc, etc).

JoeG
  • 7,191
  • 10
  • 60
  • 105

1 Answers1

3

I suggest you forget about Letsencrypt. The value proposition of that service is really focused on "getting that green lock in the browser", which you explicitly say you don't require.

Also, Letsencrypt requires access to your server to verify that the ACME challenge file is there, which means YES, you need every such server to have a publicly reachable domain. So you need to own the domain and have DNS pointing to your specific server, which sounds undesirable in a testing environment.

So in summary I think you're trying to use the wrong tool for your needs. Try using regular self-signed certificates as described in this question. For that to work, the connecting clients must be set to not verify the certificates.

Or you can take it to the next level and create your own CA. For that to work, you need to make all your containers import that root cert so that they will trust it.

Of course, once you ship the containers/images into production, don't forget to undo these things and get real valid certificates. That's when Letsencrypt will be useful.

Community
  • 1
  • 1
peedee
  • 3,257
  • 3
  • 24
  • 42
  • www.startssl.com offers free valid SSL certificates. – Niloct Jan 24 '17 at 15:54
  • that service solves exactly the same problem that letsencrypt solves, except letsencrypt is much faster and easier to use. but still the wrong tool for the problem at hand. – peedee Jan 25 '17 at 02:27
  • As I understood, his problem is that he is using DNS with non-public IPs. With startssl you can validate a domain by several "older" methods like receiving an e-mail at `webmaster@domain` for instance, then map local ip hosts as `192.168.0.10` within the domain. – Niloct Jan 25 '17 at 03:32
  • @peedee The reason I haven't (ok, don't want to!) accepted your answer is that I would prefer my 'test' environment and 'production' environments to mirror one another as closely as possible. If I introduce Letsencrypt as you say in the last paragraph, then have I ever even tested that? Given this, unless another answer comes in, I am exploring your advice on creating a CA – JoeG Jan 25 '17 at 12:15
  • I see your point, but I would like to counter that there will always be differences between testing and production. As long as you verify that certificates of a certain "strength" work when they are trusted, that's all you can ask. If you allow me an analogy, your argument sounds to me like "The DB password will be different in production, but if I never used that specific password in testing, have I ever even tested that?" – peedee Jan 25 '17 at 14:10