Some organizations and software projects (like LEAP) use puppet under git control and usually generate certificates locally which later are deployed to the nodes. Reading the documentation seems that letsencrypt cli utility creates the cert in the same machine that it will be deployed. Is there an alternative for this? Or a suggested workaround for generate the certificate in a different box than the one that it will deployed?
The protocol is designed to enable one machine to speak the protocol and another to answer the challenges.
So far in client code we’ve been focusing on the case where you run the client on your web server, so we can also help with automated configuration. But we did recently add a manual authenticator, which will spit out a file for you to provision on your web server.
When you run letsencrypt auth, you have the option to choose the manual authenticator. I just tried it now and it spat out some binary contents rather than the expected JSON, so it looks like we may have a bug at the moment. I’ll file that against our repo.
1 Like
Oh, thank you for your reply. I hope it will be able when letsencrypt gets the first stable release. Thanks for your work!
I have an application hosted inside my LAN, which only serves local users. The machine running the web application does not have connectivity to the Internet, however, it does have a valid FQDN from my organization. I’d really like to strip out self-signed certificates. Does the ACME protocol supports this? Is there a mechanism, now or in the future, to requests certificates for non-public systems?
2 Likes
I’m sure there’ll be a way to make this more slick in the future, but as things are today, If you can set up a public server at the FQDN, even temporarily, you can use the manual mode of the Let’s Encrypt client to accomplish what you want. You’ll just need to copy the “proof” to the public server when prompted, and then download the certificate from Let’s Encrypt once issued and transfer that into your private system.
After that point, you can disable the public server at the FQDN until you need to re-issue.
You can also use the standalone mode, which automates the process of getting the cert. (It would also require a public server at the FQDN; it’s just a bit faster and more automated.) When the process is complete—which should take less than a minute—you’ll have the cert available to be installed on the intranet server.
An advantage of the manual-mode suggestion is that you don’t need to copy the private key onto the public server, even temporarily. That is more in keeping with some traditional cryptographic best practices where ideally private keys are generated in the place where they’ll be used, and not migrated across a network. For the standalone-mode suggestion, you would need the private key to be present on the public server temporarily during the duration of the validation process.
It’s also worth clarifying, as I’ve seen this asked on our GitHub project page: you do need to be able to make a public server available temporarily for Let’s Encrypt to verify it, and Let’s Encrypt will publish or publicly disclose the existence of the certificate and the existence of that DNS name (because the CA is going to be publishing records about all of the certs that it issues). So you can’t get a cert using Let’s Encrypt for an internal site whose name and existence must be kept secret. However, if you’re willing to have the existence of the site be publicly disclosed in this way, you can certainly deploy the cert on a server that isn’t accessible to the public or isn’t reachable over the public Internet.
2 Likes
Thanks for the information. I'm trying to wrap my head around the concepts, particularly at this early stage; but I think I'm making progress. I've started to carefully read the [ACME Specification][1], a task that, in retrospect, should have done earlier.
I'd like to request a little bit of clarification if possible (english is not my first language, sorry, and I'd like to parse the statements with precision) so allow me to quote a bit from you:
I noticed that you wrote a public server and not something like temporarily make the server public. Does that mean that I could use a dummy or proxy to request the certs (run the client)? In other words, it doesn't have to be the very same machine, right?
OK, I'll go back to reading the spec! Thanks a lot.
PS. Unrelated: you people are going to change the landscape. Can't wait!
[1]: DEPRECATED - Automatic Certificate Management Environment (ACME)
1 Like
That's right, it can be a different machine. Either you can run the Let's Encrypt client on the public machine and then carefully transfer the private key, or you can take the somewhat harder (but more safe) approach of running the Let's Encrypt client on the private machine, and only transferring the challenge response (public) and the resulting signed certificate (also public).
2 Likes