-3

I have a big Windows video/audio application that may be controlled remotely over a web server. For that, I can listen to a local port in a, say, 192.168.1.10 system to port 8000, forward the port via NAT and have a remote browser connect to http://public.ip:8000.

The problem is now that, to have some features available for that, say, microphone recording or QUIC access, I need https. This will inevitably result in the nasty browser warning of a self-signed certificate.

I thought of a possible solution. I could get myself a cheap domain name which can have a nameserver on my Centos 7 server, for example example.xyz. Then for user having a public IP of 1.2.3.4 and wants to enable the web https server I could configure a subdomain 1.2.3.4.example.xyz which can point to the 1.2.3.4 IP and then have letsencrypt generate immediately a certificate for that server, pass it to the user and https connection is now viable.

Is the above reasoning valid? Can I somehow control/automate via, say, a PHP script, the generation of a subdomain that points to a specific IP and calls letsencrypt to generate the certificate?

Michael Chourdakis
  • 189
  • 1
  • 2
  • 11
  • A lot of folks use Caddy (https://caddyserver.com/docs/automatic-https) for this. A PHP/Laravel example at https://blog.eddy.management/using-caddy-to-deploy-laravel-apps-with-zero-downtime – ceejayoz Aug 11 '23 at 00:57
  • This makes very little sense. There are further features/constraints being added in comments elsewhere. If you are talking about packaging a software solution for other people to use then its up to the client how they manage their certificates (but I'm guessing at the intent here). If you use a reverse proxy instead of "port forwarding" then you can run multiple sites on the same DNS name/IP/port/certificate. – symcbean Aug 11 '23 at 10:03
  • You are confused, the *app* is the server. – Michael Chourdakis Aug 11 '23 at 10:05

2 Answers2

1

Okay. If I've got this straight, you have a bunch of users, and each user can somehow trigger a stock browser in your "server" that then goes out to the user's system, looking to fetch web data from the user. And you need the user's machine to support an SSL connection with a valid certificate. I'll assume you've worked out how to get through the user's firewall inbound...

Your suggested technique is to create a public DNS server of your own, then use that to publish A records for your own domain example.xyz, and a per-user dynamic 1.2.3.4.example.xyz address that you would then generate a certificate for using LetsEncrypt. Of course for that certificate to be generated you would either need to create a web target on the user's machine with a specified name, or a DNS entry for the specified address, so that the LetsEncrypt servers would recognize that you owned the domain in question. I'm assuming you would use your private DNS server for the latter... though of course you would then have to get the resulting private / public key pair back to the user's machine, unless you were doing your LetsEncrypt setup on the users' machine.

My contention is that that would work, but it would be slow. My own experience suggests that it's safest to allow 10 seconds for DNS to become available to the LetsEncrypt servers; using the technique of creating a web target is quicker, at about a second, but you still have the DNS propagation issue as you would have to generate a DNS entry for the user's machine and have that available to LetsEncrypt so they can see the web target.

As an alternative, my suggestion is to create a single wildcard certificate *.example.xyz. When user 1.2.3.4 comes in, you create a DNS entry 1_2_3_4.example.xyz in your DNS, and transfer the private and public keys for that wildcard certificate to your user. Your user then fires up their web server using those keys, and you should be in business.

tsc_chazz
  • 905
  • 3
  • 14
-1

I'm confused. Why do you want to create a certificate for each client? Generally you only need to create a certificate for the server, then provide the server's public key to the client, which you would have on your nominal web server. Simplest solution is to buy your domain example.xyz, point it at your public IP, port forward 80 and 443 to an internal web server, get a certificate for that with LetsEncrypt, and then put that certificate where you need it so that the functions that need HTTPS can use that certificate. Do it once and you're good for 3 months, for everyone who calls.

tsc_chazz
  • 905
  • 3
  • 14
  • This is for a server created within a Windows app in order for the user to connect to it remotely. The user creates a server in his local Windows and then connects to it through his mobile. – Michael Chourdakis Aug 11 '23 at 00:21
  • I'm still not seeing it. The server within the Windows app is still going to be reached as `something.example.xyz`, no? So a single certificate for `*.example.xyz` will suffice. – tsc_chazz Aug 11 '23 at 00:25
  • No. Each user has its own server based on his own IP. The app *is* the server. The app itself creates a web server in order to be accessible remotely. – Michael Chourdakis Aug 11 '23 at 00:37
  • So you have a browser app that goes back out to the user's machine? You may have enough control to be able to accept a self-signed certificate. Alternately you could still forward the same singular certificate to the user, assigning him a name `serial.example.xyz` in your `hosts` file (`serial` being created per user) and pointing that at his IP. Getting a LetsEncrypt certificate for each user, while it would work, might take an unacceptably long time. – tsc_chazz Aug 11 '23 at 00:44
  • No, the user must be able to connect to the server app using the common browsers. – Michael Chourdakis Aug 11 '23 at 00:51
  • I'll mention that there is already a Python script (Certbot) that automates getting a LetsEncrypt certificate; it is pretty complicated because it has to handle a lot of cases. But even in the simplest cases it still takes a while. Which is why instead of generating a certificate for each user, I'd generate a single wildcard certificate and pass that to the user along with a unique ID that fits within that wildcard. – tsc_chazz Aug 11 '23 at 00:57
  • No idea why this has been downvoated twice. I'm confused too. – symcbean Aug 11 '23 at 10:04
  • @symcbean I think OP was pretty clear, really; their app **is** a server. You install it, then open up a webpage it's hosting. That webpage needs to have valid HTTPS to work. Think like when you get a router and you can go to `https://192.168.1.1/` to administrate it. – ceejayoz Aug 11 '23 at 19:39