As far as I know there's currently no way to do this. Would be happy to find out I'm wrong about that.
I develop a tunneling tool called boringproxy that's similar to ngrok but open source and self-hosted. I also maintain a list of similar tools. Essentially these tools let you run a server on a machine that does not have a public IP address, by routing through one (typically a VPS) that does.
A fairly common feature of these tools is to enable end-to-end TLS encryption such that an HTTPS request can be routed through a public VPS provider, but the TLS is terminated on a client device completely controlled by the user. It's not necessary for the VPS provider to ever obtain certs.
However, it's possible that a malicious provider could obtain a cert via the HTTP-01 or TLS-ALPN-01 challenges. Currently the only way to detect this is via CT logs, which is a fairly complicated process for a random tunneling client to implement. Even with detection, there's no way to prevent it from happening.
It would be awesome if there was a way to disable these types of challenges, effectively limiting ACME to only using DNS-01. This creates a way to guarantee e2ee even in the case of a malicious VPS provider.
My naive idea for implementing this would be for services like Let's Encrypt checking for a special DNS TXT record, which if it exists they refuse to issue certs for TLS-ALPN-01 or HTTP-01 challenges for that domain.
I'm not quite following your description of the architecture, or whether you're running the domain name that you're trying to restrict certificate access to, or whether you're just talking about hosting other people's domain names. But I think you want to look into CAA records, if you haven't already.
Unfortunately my DNS provider is one of the few that doesn't support CAA, and switching providers might not be feasible for me.
Any idea why it's a new record type rather than just using TXT like many protocols do?
In case it matters, the architecture is you have a server with a public IP. You run a client program that does not have a public IP. It makes a permanent connection to the server to create a tunnel. When the server receives normal HTTPS requests from the internet, it forwards them to the client, which can then act as a reverse proxy to other servers on the same machine or local network. This would commonly be used for example if you wanted to run a web server from home but don't have a public IP address.
The user running the software would be doing it for a personal domain, not running it for others I think.
because it need to be block all when malformed, not silently ignore it.
CAA record on lower level override CAA on upper level, so keep mind that when giving clients dns writing permission
BTW it looks like that will get a lot of certificate from that domain, keep mind about rate limit and write rate limit adjust of apply for public suffix list: I think you'll need PSL as each subdomains are from different clients and need cookie separation
CAA record on lower level override CAA on upper level, so keep mind that when giving clients dns writing permission
Sorry I'm not certain on the DNS terminology here. Does this mean that a CAA on sub.example.com would override any CAA on example.com, or the other way around?
That's very unfortunate; I thought almost everything did by now. What's the provider? SSLMate has a list of what systems support it, which may be useful:
So if people are just configuring things for their own domain, I'm not sure why someone would need to restrict the validation methods? I'm still confused about who's doing what. If someone controls the name, then they should be able to get a certificate for their system to use regardless of how many hops it takes for traffic to get there.
That's very unfortunate; I thought almost everything did by now. What's the provider? SSLMate has a list of what systems support it, which may be useful:
So if people are just configuring things for their own domain, I'm not sure why someone would need to restrict the validation methods? I'm still confused about who's doing what. If someone controls the name, then they should be able to get a certificate for their system to use regardless of how many hops it takes for traffic to get there.
I can give a more concrete example.
Let's say I have a web server running on my laptop that I want to be accessible to the internet, but I don't have a public IP (or maybe my ISP doesn't allow inbound connections on ports 80/443). I can run the boringproxy server on a VPS, and the client on my laptop. The client connects to the server and creates a tunnel. I point my DNS for example.com at the server. When visitors to example.com hit the VPS, it forwards requests through the tunnel to the client. The client can also use this tunnel to get certs from Let's Encrypt using the TLS-ALPN-01 or HTTP-01.
The problem is in the case of a malicious VPS provider, they could also get certs and MITM the requests, perhaps without me even noticing. If I can use CAA records to restrict certs to only the DNS-01 challenge, that will still work for the boringproxy client, but the VPS provider will no longer be able to get certs and MITM the requests.
Hmm. Yeah, SSLMate agrees that they don't support it. Can't hurt to try to open a support ticket or the like and ask them about it. Part of the reason they don't support it is probably "Well, nobody asks for it."
You can also change DNS providers without changing your registrar or hosting provider. Hurricane Electric and Cloudflare each have a well-regarded free tier of DNS services (though I haven't used them personally), and I know there are others out there. (Though I'm generally of the opinion that paying for something helps make sure that you're the customer and not the product.)
Thank you, that really helps me understand the concern you were having. It is certainly the case that someone with some level of control over the IP space that the domain points to could get a certificate. Even outside of Let's Encrypt's free service, there are plenty of other CAs out there, many of which are also free. So in addition to the owner of the IP the domain is pointed to being able to get a certificate, any of the approved validation methods could be used (in the absence of CAA records), including things like email to the domain contact. (Even though Let's Encrypt doesn't use that validation method, other CAs do.) So you also need to be concerned about your email provider, and whoever controls DNS for the domain your contact's MX record points to, plus whoever controls the IP that the mailserver is on. Though maybe they're in less of a position to MITM your requests than the system actually running your domain's IP.
CAA records certainly can help mitigate that risk. But even with them, you're still trusting your registrar, your DNS provider, and whomever controls the IP space of your DNS provider, since any of those could change the DNS reply to be a different (or no) CAA record. DNSSEC helps limit this even further, but you still are relying on the registrar returning the right DNSSEC keys, and relying on whatever system is doing the signing of your DNS zone to protect the keys. (And to keep your DNS zone available, which is often a bigger risk for many people in practice than the risk of an attacker trying to modify DNS responses.)
You can also change DNS providers without changing your registrar or hosting provider. Hurricane Electric and Cloudflare each have a well-regarded free tier of DNS services (though haven't used them personally)
I've used Cloudflare in the past. That might be an option at least initially. Since this is a commercial venture, I've known I'll probably need to run my own DNS servers eventually anyway. That CAA list is actually really helpful for finding potential server software to use.
CAA records certainly can help mitigate that risk. But even with them, you're still trusting your registrar, your DNS provider, and whomever controls the IP space of your DNS provider
All true. A lot of the value in my offering would come from being the most secure, even if I can't achieve ideal security. Cutting out an entire attack vector is definitely worthwhile.
Yeah I'm aware of Cloudflare Tunnel. It's actually what I currently recommend for most people on the list I maintain:
With respect to this topic, it's actually the exact opposite of what you want. Not only does Cloudflare have the ability to MITM all your requests, they always do. It's the only way (I know of) to provide a CDN as they do.
A primary reason someone would want to use my proposed tunneling solution over Cloudflare is to get e2ee.