I'm having loads of customers with a very small application (pwa) that needs to access a local server (apache2). The application handles also customer data, so we received from multiple customers the request to make all traffic encrypted even while it is internal.
My first idea was to use a self-signed certificate, but we fail on multiple places. One is that Chrome and other browsers become more and more strict on the certificates / certificate authority. A pwa does not allow any non official certificate at all. So also standard self-signed certificates are declined.
So, I tested an idea, which almost worked, to create a letsencrypt wildcard domain and make on the dns server exceptions for the ip address (the dns we can access via an api and we know the ip addresses). So customer1.domain.com, customer2.domain.com. It worked well, although it is very, very, very bad practice.
But dns servers on the internet remove local addresses like 192.168.178.x and a nslookup responds with an '** server can't find xx.xx.com: NXDOMAIN'
I know you are not allowed to use local addresses in the dns servers (RFC2026), but I just gave it a quick try.
So it would need adaptation of the local dns servers and this is not an option due to the amount of customers and their different ways of accessing dns service. Some can, most of them have not even a real dns server they can change.
Buying certificates would be a good solution, but the price is not acceptable to my customers.
So I'm looking for a solution. Is there anyone that has a good idea in order to solve this?
Accessing from a PWA (javascript, since we need it to be clientside) to an ip address is not allowed on https. A PWA runs on the backend on a browser, so it would mean that with every pc that uses it, you'd have to do some specific things in order to import the CA. That being an end-user thing would be too complicated for most users I think.
I'm not even sure if Chrome allows non-official CA's.
It's still released as apk/ipa isn't it? Do your clients expect to connect there from main web browser? If you control released app you can set it to trust specific ca that sign certificate to each ips
Obtain a Certificate for internal.example.com or some other subdomain under your registered domain. Ideally use the DNS-01 validation so you can have this automatically renew, but you can use the HTTP-01 challenge validation and then manually copy the certificate over (or write a deploy script to automate things).
If you use the HTTP-01 challenge - switch the DNS entry: (i) either in the global public DNS; or (ii) have a local server map internal.example.com to 192.168.178.x. You can also edit the local machine's hosts file to resolve the domain to that IP address. If you search this forum, the term is called "split horizon dns".
I often use the DNS-01 challenge to generate dev.example.com certificates, which have a global DNS record for 127.0.0.1. This allows everyone on my team to develop and test with a valid LetsEncrypt certificate as if we were on the production environment.
I created a wildcard domain using a DNS challenge. I can, without a problem, install the wildcard certificate on each server. However that leaves me with the global dns server that do not allow for internal ip addresses to be referenced (https://www.ietf.org/archive/id/draft-ietf-dnsop-dontpublish-unreachable-01.txt).
Changing the hosts file on each laptop or changing the local dns servers would work, however, the problem is too many non-technical customers with too many different local dns servers, which we do not control. Changing the hostfile would require each new client pc to give explicit support.
So from the technical side this would work, but not from the organizational side.
As far as I'm aware, I did not know the term split horizon dns, the split horizon dms with local ip addresses will only work with a local dns server. And we do not control that.
I tried a wildcard domain on letsencrypt, with google dns, which works brilliantly.
Publishing the localip address on an exception on the wildcard domain did work for about 10 minutes. After that the dns entry is still there, but an nslookup gives an error. So apparently they do check if the ip is reachable or something like that.
I'll give that a deeper dive. The last time I tried, I had to trust the CA in the browser. As far as I'm aware Progressive Web Apps / JavaScript does not support in their fetch commands that you trust a specific CA. So it would mean a lot of work for non-technical people to trust a CA in their browser, if it works.
If JavaScript would be able to allow you to trust either a selfsigned certificat or a specific CA, tt would be nice, since then you could get a lot easier in order to access local sites from your application.
Thanks for helping. This is indeed the problem, we're talking about many customers, companies, of which many have no of external system system managers and most of them use chromium based browsers, but I've also seen Firefox. We also run on mobile devices, both iOS and android. As soon as we connect to the local network (wifi or vpn) the system is able to connect to internal systems, otherwise it connects only to a hosted system with less functionality.
If it was a few companies where you could do something with group scripts, then I would not have posted this question.
think actual problem here is router's dns servers refuses to resolve private IP range: I know openwrt by default discard upstream dns lookup points to non loopback ip range, so I guess quite a bit of router firmware based on it will do that too: looks like pihole had this problem
Some DNS resolvers block DNS responses containing RFC1918/the router's private subnet in order to protect against DNS rebind attacks. In such cases the network administrator may need to allowlist the FQDN.
All good perspectives and Ideas for sure.
You may want to look in to NAT reflection and "Split DNS"
As mentioned above use a DNS challenge for a valid domain name, create internal subdomains from the apex and distribute the certificates via a script.
This is the way.