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.