Score:-3

Creating/Configuring a DNS server with runtime configuration

my flag

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?

vn flag
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
ws flag
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.
Michael Chourdakis avatar
my flag
You are confused, the *app* is the server.
Score:1
vn flag

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.

Score:-1
vn flag

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.

Michael Chourdakis avatar
my flag
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.
tsc_chazz avatar
vn flag
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.
Michael Chourdakis avatar
my flag
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.
tsc_chazz avatar
vn flag
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.
Michael Chourdakis avatar
my flag
No, the user must be able to connect to the server app using the common browsers.
tsc_chazz avatar
vn flag
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.
ws flag
No idea why this has been downvoated twice. I'm confused too.
vn flag
@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.
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.