Let's Encrypt to work around *mixed-content* issue in a webinterface for remote control


Hi there,

our open source software provides a service that enables the user to remote control our desktop application through a web interface. The traffic is either tunneled through our servers or is established via a direct connection to the lan/wan IP of the user.

We are looking for a solution to also enable direct connections in the https context.
There are two problems at the moment. Either the http connection is getting blocked due to “mixed-content” or the browser wants the user to accept an exception on every ip:port variant for the self signed certificate. So after each IP change, the user would need to accept the self signed certificate again and again.

Since we do not rely on SSL for security/encryption/authenticity because we use our own technology layer on top of the http protocol, our current approach is to use a wildcard certificate that we want to deploy together with our software. At the moment, we’re discussing this approach with our certificate provider. We are very aware of the risk of a possible Man-in-the-Middle attack when the private key is bundled with the application, but since we have our own security/encryption/authenticity layer on top, this is not a problem in our use case.

We would like to discuss the possibility to use “Let’s Encrypt” to provide a custom certificate for each running instance of the application.
This would either require wildcard support for “Let’s Encrypt” or at least 2 different certificates per running instance for lan/wan mode.
Our service is currently still in the beta phase, but we would already require about 30-60k certificates.

It would be nice to get in contact with someone that is able to provide feedback/help with this.

Best regards
Daniel Wilhelm


Would be nice to get some feedback from staff!?


Well, without knowing what your project is actually about I won’t say something like “funky software design” and “there has to be a way better way” :smiley:

This sounds like it would be a huge strain on the letsencrypt servers with maybe next to no benefits to the users at all.
I suggest you explain your project better (link to it?) if you want a bigger response.


Hmm…What exactly is unclear about the project? :slightly_smiling:
Our software allows our customers to access their home desktop computers from anywhere. The traffic is either tunneled through servers or directly connected to the home destop computer. Tunneling through our servers increases latency and reduces speed while a direct connnection will always win in terms of latency and speed.
The main issue here is that a https website no longer can talk/access non https content (mixed-content blocking).
This issue is valid for every software where a websites wants to access content on dynamic IP’s. Using self signed certificates on the home computer is no solution, because the customer would have to add an exception for the certificate every time his IP changes. Self signing does not support wildcard certificates because browser always only add an exception for hostname:port. That’s why we thought about using Let’s Encrypt for the home computer site to dynamically create certificates that are valid in browser.

Just to make it clear, we are trying to find a good solution to enable https in a dynamic IP environment.


You cannot get LE certificates on just IP addresses - they have to be hostnames. Therefore, you’d have to assign a DDNS hostname for every of IP address of your clients. Therefore, you could just as well point a subdomain in your domain (that has a wildcard certificate) to your client’s IP address with a short TTL.



[quote=“Jiaz, post:1, topic:9467”]
…our current approach is to use a wildcard certificate that we want to deploy together with our software…[/quote]

Please read my first post (again), thanks!

We would like to use Let’s Encrypt to avoid compromising the private key by bundling it within our application.
With help of Let’s Encrypt each customer would be able to generate his/her own certificate.
At this moment (we are still in beta stage) this would already require about 50-60k subdomain certificates.


Hmm, for a moment I assumed that the traffic is passing through your servers. I was wrong then.

Considering that each client software would request that certificate from their device, the 50-60k subdomain certs would be split among 50-60k distinct IP addresses. I guess LE quotas wouldn’t limit that but I’m not the authority to speak here.