In the current state of things, yes. I have to expose something internal to the entire internet to use the LetsEncrypt service. That is the root of my feature request, I am proposing a way to limit exposure.
1 Like
Well, that's of course a choice you're allowed to make 
However, I wouldn't be surprised if this isn't a feature LE will choose to develop. On the other hand, maybe they think it's a genius idea, who knows I'll leave it at this and let the Let's Encrypt staff do the decision making.
5 Likes
If your dns is not supposed to be publicly known, it should not be in a tld zone, imho.
You can apply split-horizon principles to the http-01 challenge as well, you just have to set up your acme clients to use a webroot on a single machine that answers on the public internet for every fqdn you want a certificate for. Then you install the certificates on the internal machine.
3 Likes
Ill leave it at this, I want to use LetsEncrypt without the need to expose a service to the entire internet. My feature request is just an idea of a way to make the process even more secure. I am aware port knocking is not a common practice and has it's own challenges in implementation. The solution allows end users who want LetsEncrypt source IP addresses for their firewalls to have them.
1 Like
If you want to use a public certificate (which perhaps you don't really need), then you need to expose something to the world, even if it's just an email address in your domain's Whois information (which if I understand correctly other CAs may use even if Let's Encrypt doesn't). But in order to fully automate domain verification like Let's Encrypt does (helping keep costs low so that it can be free), to ensure that you own a name as seen from everywhere on the Internet requires them to check your name from many places on the Internet.
3 Likes
Not to the world you don't, no. Just to LetsEncrypt.
1 Like
Use a simple, standard environment but totally separated from the protected infrastructure in order to generate the certificate. Then just pull the certificate from this environment. Even it gets compromised that cannot harm your protected infrastructure.
4 Likes
Perhaps in a technical sense, but in a policy sense they need to mitigate the risk of a bad actor trying to get a certificate for your name by intercepting only their connections (which would be easier if they published what IPs they were connecting from and advertised them, whether though port knocking or just by having a list available). They check from multiple places to ensure that the name is actually owned by you on the public Internet.
If your systems really need to be locked down this much, and users outside your organization aren't going to be using the sites anyways, then you'd probably be much better served with a private CA you're running yourself and automatically distributing the root into your users' trust stores, rather than trying to use a public CA like Let's Encrypt.
3 Likes
Read LetsEncrypt's statements on why they do not publish a list of their sources. Their arguments against publishing sources apply equally to this situation. The situations themselves are different in implementation, but their arguments against IP publishing apply equally to your proposal. Paraphrasing some: (i) that is not the job of a CA, (ii) they do not care about supporting internal/private systems, only public accessible ones, (iii) the proposed changes undermine the concept of publicly available dns information, etc. Your suggestion is essentially a slight variation to present an explicitly unsupported model in a new wrapper.
The pre/post hooks are a convenience in Certbot. You can manage this yourself. I have a custom renewal system that wraps all certificate procurement with a system to setup and teardown firewall rules and custom dns server.
3 Likes
That's the point. Let's Encrypt goes TO A LOT OF TROUBLE to make sure what they see is what everybody else sees. And it does so by design, for security and authentication reasons.
Why would you ask them to compromise this?
2 Likes
Yup, that's what the feature request is all about. Its a function that doesn't exist, and I think it would be nice to have it.
They could knock from multiple sources, that would work fine.
I got it!
Let's Encypt can create its' own TLD: ".LE"
Then you can register your-domain.le directly with LE and never need any other (additional) proof of ownership, nor ever need to actually use it anywhere on the Internet.
[that, of course, will never happen]
2 Likes
Can you explain in detail how the implementation of my feature compromises anything?
1 Like
Who would the valid knockers be?
If anyone could knock (first), and the port would open, how is that any different than just leaving the port open?
4 Likes
Let's Encrypt's primary focus is to provide certificates to publicly-available web sites. The DNS challenge makes it possible to use LE with internal servers, but if you want to lock things down so much that you can't even expose DNS externally, LE probably isn't the right solution for you, and asking them to come up with workarounds for your specific needs isn't going to scale. (You want port knocking, others want a list of IPs to whitelist, others might want ABC, XYZ, etc.)
Like others have said - a perfectly viable solution would be to use split-horizon DNS. Use a hosted DNS service like Route53 on the public web, then have your internal recursive DNS resolvers point to your internal authoritative DNS servers. Then you could use LE without LE having to touch your actual internal DNS servers.
If that's not an option, you might want to look into some sort of internal PKI solution, rather than using publicly trusted certs. Sure, it's extra work to set up the private root on every device on your network, but that's the price of having such an unusual setup. Otherwise there are commercial CAs that offer other forms of validation (whois email lookup, for example) if you need public certificates.
6 Likes
When I create my request with LetsEncrypt, I add my knock comnination as additional meta data. ie "tcp/8031, tcp/442, udp/21, tcp/9001". My client application tails the firewall logs. When it sees a source IP address make connection attempts to these ports, in this order, we know its LetsEncrypt knocking. So the app then opens DNS to that source IP for a durration to allow LetsEncrypt to connect.
This is the, "No, were not going to do that" I was looking for.
I still think its a cool idea, but I get it. There are other ways to achieve higher security that exist today.
you do realize that every issue you have with your dns server also applies to your firewall, do you?
3 Likes
I don't think you are providing anything useful to this conversation anymore. It appears you are trying to "win".
But if this is a feature that you want LE to implement, it is going to be published publicly. Then anybody can simulate the LE's "knocking". Soon you will see many unrelated third parties properly knocking on your door.
4 Likes