Distributing or generating certificates as part of private apps running localhost servers

I’m developing and distributing a desktop app that runs a localhost webserver. This desktop app responds to requests from a public facing website that runs on HTTPS (i.e uers’s web-browser makes requests directly to user’s desktop server app). Since browsers are beginning to forbid HTTP requests on HTTPS websites, I need to distribute or generate SSL certificates with my application.

Some requirements:

  • These apps run ask desktop apps on localhost or as severs on private networks
  • The end-users of these apps are not expected to buy or configure there own SSL certs - the app “should just work” after it is installed.
  • Since these apps are just running privately on localhost, they can’t generate certificates with HTML/HTTP or dns-01 validation.
  • Hundreds of these apps may be downloaded and installed per week

I’m looking for suggestions as to how to distribute SSL certificates as part of these apps. Hopefully this is a helpful thread for other developers who might be distributing apps that involve a localhost server.

Related issues: Certificates for hosts on private networks, Certificates for many user-controlled subdomains

Option 1 - Self-Signed Certs
On app install, we:

Cons:

  • Asking users to install certs on install is tedious
  • Bundling and running openssl on windows adds complexity

Option 2 - Create a cert-generating server on the public internet

  • Create a cert generating server on the public internet: <developer's-website>.com
  • On app install, the app automatically:
    1 - adds e.g. 127.0.01 myapp.<developer's-website>.com to /etc/hosts
    2 - generates a CSR
    3 - makes a request with that CSR to something like <developer's-website>.com/generate-cert
  • <developer's-website>.com will generate a cert for myapp.<developer's-website>.com with the requested CSR via a CA’s API
  • The app will receive the cert in the response and use it to start an HTTPS server

Note that the developer controls the public domain name <developer's-website>.com and they can serve content on the subdomain myapp.<developer's-website>.com to issue certs against. This same address is used to access the localhost app on user’s machines via the /etc/hosts entry (or on a private DNS entry in a private network).

Cons:

  • Some CAs will generate these renewal certs on-the-fly via an API but it’s pretty expensive
  • LE currently only permits 5 renewals (or duplicates) per week (I’ll need hundreds)
  • Some CAs only allow you to renew a certificate within a few weeks or months of its expiry date

Are there any other possible options that I’m not considering? Thanks for the help and the service!

I’d add some amendments to both options.
For 1: Look into automating the CA installation. I would guess most OS have some sort of API for this (and for those that don’t, it’s probably as easy as adding a PEM file to some directory.) I would also look into name-constraining the root certificate to your domain to avoid the Lenovo Superfish situation.

For 2: I’d definitely use per-user subdomains, similar to how Plex implemented HTTPS. Multiple users owning private keys for the same domain name seems like a security nightmare, and I’m not quite sure if it’d be allowed by the TOS. If your site has some kind of authentication mechanism, you can just use the user id or something like that and the subdomain would still be predictable from the point of view of your application (i.e. you wouldn’t need to ask your users to provide their subdomain separately). As for the rate limiting, you might be able to ask for an adjustment using this form.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.