2

I want to make it easy for users who have private servers to connect to those servers inside their LAN from Android devices.

I want to avoid having these users perform configuration tasks like, trusting self signed certificates, setting up DNS or changing DNS settings in Android (which by default uses Google's 8.8.8.8 DNS server).

I'm considering a way to do this, however it involves delivering a private key for a HTTPS certificate on a domain-name we control, to the user, essentially publishing it.

Assuming the domain name is not used for anything else - is this ever going to be OK from a security perspective (I have noted MITM below)?

The scheme by the way is as follows:

-Obtain a LetsEncrypt wildcard cert. for our domain name somedomain.tld

-Setup DNS to point addresses like 192-168-1-1.somedomain.tld to 192.168.1.1

-Install the certificate for *.somedomain.tld on the machine 192.168.1.1 (this requires the private key).

-Now when their Android device tries to load https://192-168-1-1.somedomain.tld/ it will be pointed to 192.168.1.1 which will serve the page 'securely'.

Potential flaws that I can see:

-Private IPs on public DNS can cause confusion because they will not always point to the same machine or are not always accessible, in my context this isn't an issue.

-Attackers could do a MITM attack between private server and its client.

The context for this is development, and shouldn't be used for production, also I'm tempted to think that to implement a MITM attack on a private network may require the network to be so comprimised already that it would be pointless?

  • 2
    If you don't consider a MITM attack viable - then why do you need to use HTTPS in the first place? By making the private key public for the certificate you throw away basic assumptions of HTTPS and severely degrade the security it can offer. Apart from that most CA revoke a certificate if the private key gets compromised (i.e. is known to a potential attacker). – Steffen Ullrich Jan 8 at 19:47
  • @SteffenUllrich just because certain services that our outside of control, will not use HTTP now. – Jim W Jan 8 at 20:23
  • You say this if for development. Whose Android devices are these? If they're company devices, do you have a permanent enterprise root certificate? Especially if it could be added to the devices during provisioning. – Clockwork-Muse Jan 9 at 5:58
  • @Clockwork-Muse well in reality some may be company devices, others will not be, so I can't rely on enterprise root certs. – Jim W Jan 9 at 18:46
1

You can't do it with a publicly trusted CA, because anybody who can prove they possess the private key can ask the CA to revoke the certificate, and the CA will have no other choice that to revoke it.

3

Why on earth do you want to do that? Issue a fresh Let's encrypt certificate for each subdomain. This is fairly trivial, as you can authenticate domains in DNS, by a txt record.

Run the ACME client on the local device that needs the certificate, send the required txt string to your server, update DNS with it, and notify the local device that it can proceed to verify the domain.

I do this for a few things inside my network, that cannot be reached externally, and it works like a charm. That way the keys will be unique. And LE certs are free anyway...

This Q&A explains dns challenge validation.

  • Thanks, I was under the mistaken impression that the server had to be publically accessible. – Jim W Jan 8 at 20:16
  • No, you have to prove control over the domain with DV (Domain Validation) certificates. That can be done with a DNS record. – vidarlo Jan 8 at 20:28
  • Actually there is one problem, LE rate limits your certificates to 50/week (I know you can get 5000 using SAN, but it's not technically viable in this situation). So I'm back where I started. – Jim W Jan 10 at 5:29
  • You can ask them to increase the limit for you. – vidarlo Jan 10 at 5:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.