I prefer to assign an external name to an internal device and grab a free SSL cert from LetsEncrypt, but using DNS challenge instead as internal IP addresses aren't reachable by their servers.
I last looked at LetsEncrypt maybe 8-9 years ago, I thought it was awesome but not suitable for my internal stuff due to the http challenge requirement, so I went down the self signed CA route and stuck with that, and didn’t really keep up with developments in the space
It was only until recently someone told me about the DNS challenge and I immediately ported everything over with a wildcard cert - its been great!
I do this as well, but be aware that these external names you're using for internal devices become a matter of public record this way. If that's okay for you (it is for me), then this is a good solution. The advantage is also that you run no risk of name clashes because you actually own the domain
I decided to try split DNS to avoid leaking the internal IPs, but it turned out a bit more fragile than I imagined.
Especially Android is finicky, ignoring your DNS server if it doesn't like your setup. For example, if it gets an IPv6 address, it requires the DNS server to also have an IPv6 address, or it'll use Google's DNS servers.
It works now but I'm not convinced it's worth it for me.
I use CNAME records and it works on everything except Windows, where it works sometimes.
Basically, CNAME record from service.myserver.com to myserver.internal on a public DNS server, A record from myserver.internal to 1.2.3.4 on private DNS server.
I think I could maybe get it working on Windows too by tweaking the TTLs. Currently both DNS servers are automatically setting the TTL and I think Windows freaks out about that.
> be aware that these external names you're using for internal devices become a matter of public record this way
Yes, I sometimes think about that, but have come to the conclusion that it's not likely to make any difference. If someone is trying to infiltrate my home network, then it's not going to really help them to know internal IP addresses as by the time they get to use them, they're already in.
> If someone is trying to infiltrate my home network
I don't think the publishing of host names was mentioned as a concern for small home networks, but more for larger organisations that might be subject to a coordinated break-in or simply have trade secrets¹ that might be hinted at by careless naming of resources.
----
[1] their next big product/enhancement, as yet unannounced even within the company, for instance
you can use a wildcard of type *.internal.example.com or use names that do not relate to the service name if you want to obfuscate the tech stack used.
The only thing public is that you may have an internal network with nodes.
> The Name Constraints extension lives on the certificate of a CA but can’t actually constrain what a bad actor does with that CA’s private key
> Therefore, it is up to the TLS _client_ to verify that all constraints are satisfied
> However, as we extended our test suite beyond basic tests we rapidly began to lose confidence. We created a battery of test certificates which moved the subject name between the certificate’s subject common name and Subject Alternate Name extension, which mixed the use of Name Constraint whitelisting and blacklisting, and which used both DNS names and IP names in the constraint. The result was that every browser (except for Firefox, which showed a 100% pass rate) and every HTTPS client (such as Java, Node.JS, and Python) allowed some sort of Name Constraint bypass.
That’s the danger of any solution that requires trusting a self-signed CA. Better just trust the leaf certificate, maybe make it wildcard, so you only have to go through the trust-invalid-cert once?
I wa t ti be able to import a cert into by browser and specify what to trust it for myself. “Only trust this cert for domain.com” did example.
The name constraints can give me a hint what it’s designed for, but if I import a cert to MITM devsite.org, I don’t want that cert working for mybank.com.
I did some research, write-up and scripting about the state of X.509 Name Constraints, so that people you give your CA cert to don't need to trust you not to MitM them on other domains.
Packaged into a convenient one-liner to create a wildcard cert under for the new .internal TLD.
For example my government uses non-standard CA and some websites rely on it. But importing CA obviously makes them able to issue google.com and MITM me if they want to. And they already tried, so trust is broken.
I imagine something like generating separate name-constrained certificate, sign existing CA with this name-constrained certificate (I think it's called cross-sign or something like that) and import things into OS, expecting that browser will use name-constraints of the "Root-Root" certificate. Could it work?
Niklas, if you are reading this - it was a pleasure to interview with you some 6 (or so) years ago :) thanks for the script and the research, I will make use of it.
Is "name constraints" new? I wanted to do something similar a decade or two ago and found I'd have to be trusted for all domains, which I wanted to avoid.
It's been around since ~2008 when rfc5280 was released.
But it's long been stuck in a cycle of "CAs won't issue name-constrained certificates because not all clients support it properly" and "Clients don't bother to support it properly because CAs won't issue name-constrained certificates"
And even if today's clients all support it properly - there will always be some users running ancient smart TVs and android phones that haven't received a software update in a decade.
I'd rather see something with 90 days and ACME. Note sure why there isn't a simple certificate management tool that does this and maybe even brings a simple UI?
This is about creating and using a domain-restricted CA, which is then used to create server certificates. Point being that your (tech savvy) friends are willing to install the CA because it can only ever validate some specific subdomains (and not MITM the entire internet).
I prefer to assign an external name to an internal device and grab a free SSL cert from LetsEncrypt, but using DNS challenge instead as internal IP addresses aren't reachable by their servers.
I last looked at LetsEncrypt maybe 8-9 years ago, I thought it was awesome but not suitable for my internal stuff due to the http challenge requirement, so I went down the self signed CA route and stuck with that, and didn’t really keep up with developments in the space
It was only until recently someone told me about the DNS challenge and I immediately ported everything over with a wildcard cert - its been great!
I do this as well, but be aware that these external names you're using for internal devices become a matter of public record this way. If that's okay for you (it is for me), then this is a good solution. The advantage is also that you run no risk of name clashes because you actually own the domain
I decided to try split DNS to avoid leaking the internal IPs, but it turned out a bit more fragile than I imagined.
Especially Android is finicky, ignoring your DNS server if it doesn't like your setup. For example, if it gets an IPv6 address, it requires the DNS server to also have an IPv6 address, or it'll use Google's DNS servers.
It works now but I'm not convinced it's worth it for me.
I use CNAME records and it works on everything except Windows, where it works sometimes.
Basically, CNAME record from service.myserver.com to myserver.internal on a public DNS server, A record from myserver.internal to 1.2.3.4 on private DNS server.
I think I could maybe get it working on Windows too by tweaking the TTLs. Currently both DNS servers are automatically setting the TTL and I think Windows freaks out about that.
Or use a wildcard cert for all internal certs.
That could be a good idea, though it means that the certificate/key has to be well guarded.
Please don't. Technical debt accumulates by force of practice.
It's working good for me. My technical debt is to always make sure that I'm able to renew a certificate and that the distribution occurs successfully.
I don't see how other solutions are less problematic.
Shameless plug:
https://www.merklemap.com/
> be aware that these external names you're using for internal devices become a matter of public record this way
Yes, I sometimes think about that, but have come to the conclusion that it's not likely to make any difference. If someone is trying to infiltrate my home network, then it's not going to really help them to know internal IP addresses as by the time they get to use them, they're already in.
> If someone is trying to infiltrate my home network
I don't think the publishing of host names was mentioned as a concern for small home networks, but more for larger organisations that might be subject to a coordinated break-in or simply have trade secrets¹ that might be hinted at by careless naming of resources.
----
[1] their next big product/enhancement, as yet unannounced even within the company, for instance
You don't need to publish the IP addresses publicly if you use an internal DNS server. I think even Pi-hole could do this.
you can use a wildcard of type *.internal.example.com or use names that do not relate to the service name if you want to obfuscate the tech stack used.
The only thing public is that you may have an internal network with nodes.
From the linked Netflix article:
> The Trouble with Name Constraints
> The Name Constraints extension lives on the certificate of a CA but can’t actually constrain what a bad actor does with that CA’s private key
> Therefore, it is up to the TLS _client_ to verify that all constraints are satisfied
> However, as we extended our test suite beyond basic tests we rapidly began to lose confidence. We created a battery of test certificates which moved the subject name between the certificate’s subject common name and Subject Alternate Name extension, which mixed the use of Name Constraint whitelisting and blacklisting, and which used both DNS names and IP names in the constraint. The result was that every browser (except for Firefox, which showed a 100% pass rate) and every HTTPS client (such as Java, Node.JS, and Python) allowed some sort of Name Constraint bypass.
That’s the danger of any solution that requires trusting a self-signed CA. Better just trust the leaf certificate, maybe make it wildcard, so you only have to go through the trust-invalid-cert once?
Note that statement is 7 years old, it prompted Netflix to make bettertls.com.
The situation has improved since then, see the linked https://news.ycombinator.com/item?id=37544094
I wa t ti be able to import a cert into by browser and specify what to trust it for myself. “Only trust this cert for domain.com” did example.
The name constraints can give me a hint what it’s designed for, but if I import a cert to MITM devsite.org, I don’t want that cert working for mybank.com.
I did some research, write-up and scripting about the state of X.509 Name Constraints, so that people you give your CA cert to don't need to trust you not to MitM them on other domains.
Packaged into a convenient one-liner to create a wildcard cert under for the new .internal TLD.
Please scrutinize!
I use this to provide e.g. at home:
to provide transport encryption of these services in the local WiFi.Friends and family can add the CA root to their devices without having to worry about me MitM'ing their other connections.
Is it possible to constrain existing CA?
For example my government uses non-standard CA and some websites rely on it. But importing CA obviously makes them able to issue google.com and MITM me if they want to. And they already tried, so trust is broken.
I imagine something like generating separate name-constrained certificate, sign existing CA with this name-constrained certificate (I think it's called cross-sign or something like that) and import things into OS, expecting that browser will use name-constraints of the "Root-Root" certificate. Could it work?
Niklas, if you are reading this - it was a pleasure to interview with you some 6 (or so) years ago :) thanks for the script and the research, I will make use of it.
How does this compare to mkcert?
mkcert might be getting this as well: https://github.com/FiloSottile/mkcert/pull/309/commits/92215... (this is linked from the current submission's readme)
Is "name constraints" new? I wanted to do something similar a decade or two ago and found I'd have to be trusted for all domains, which I wanted to avoid.
It's been around since ~2008 when rfc5280 was released.
But it's long been stuck in a cycle of "CAs won't issue name-constrained certificates because not all clients support it properly" and "Clients don't bother to support it properly because CAs won't issue name-constrained certificates"
And even if today's clients all support it properly - there will always be some users running ancient smart TVs and android phones that haven't received a software update in a decade.
VALIDITY_DAYS="3650"
I'd rather see something with 90 days and ACME. Note sure why there isn't a simple certificate management tool that does this and maybe even brings a simple UI?
This is for an internal network.
tbh the skill level require for a valid wildcard cert isn’t all that high either.
This is about creating and using a domain-restricted CA, which is then used to create server certificates. Point being that your (tech savvy) friends are willing to install the CA because it can only ever validate some specific subdomains (and not MITM the entire internet).