What are the risks of deploying a client application with server authentication certificate (private + public key) so that a client application can host a webserver. Which is accessible via HOSTS redirect through the browsers.

What are the risks with the following approach?


  1. I own the "example.com" domain.
  2. I get a valid server authentication certificate for "app.example.com", say for e.g. from Comodo.
  3. I have a web application hosted at "https://www.example.com".
  4. Users are supposed to do some action which requires me to send some requests to an application running on their system and get a response.
  5. I do this by installing a client application on user's system.
  6. This application has the server authentication certificate for "app.example.com" issued above. It can host a locally accessible web server.
  7. During installation, I add an entry to C:\Windows\System32\drivers\etc\hosts for a redirect from "app.example.com" to ""
  8. When user is using the Web application at "https://www.example.com" it also connects to "https://app.example.com" which is actually the client application running on users system.
  9. Browser can send requests to an application running on their system and get a response.

Things I would like to know: Risks, Fixes, Alternative Approaches etc.

Update: Additional Question: Certificates for localhost, MITM Attack

I preparing a list for why not to do this as asked in the question. As well as for my understanding.

  • Why are you not just using plain http? You are effectively downgrading https to http (except for passive sniffing in case of ephemeral keys). What is the threat model for your system? – domen Dec 6 '18 at 17:16
  • Your application design seems backwards. Why not create an application that runs on the desktop, normally, and occasionally connects to your website? Otherwise, I believe most modern systems all have a localhost certificate - can you just use that one (or generate a self-signed certificate and install it to the proper store)? – Clockwork-Muse Dec 6 '18 at 18:29
  • @domen Browser block mixed content. – AEonAX Dec 7 '18 at 4:28
  • @Clockwork-Muse Users generally use the webapplication, only some operation require communication with the client application. Can you give source for localhost certificates? Self-signed certificate are generally not trusted by the browsers – AEonAX Dec 7 '18 at 4:34
  • 2
    Side note, hilariously relevant: letsencrypt.org/docs/certificates-for-localhost – Clockwork-Muse Dec 7 '18 at 5:09

You are publishing a certificate for https://app.example.com along your app. Thus this private key is no longer "private". Someone will find out and publish it. This will lead to the CA revoking your certificate for app.example.com (they MUST revoke it). This has happened in the past, you are not the first one to have such idea, companies like Cisco, Blizzard, EA, Spotify, mega… used to do this.

This is more a procedural issue, but it will bite you quite quickly (do remember that the CA have 24h to revoke it once they are made aware that the certificate is compromised).

A MITM could extract the certificate from your app and impersonate app.example.com on someone which don't have the hosts entry, but it isn't worth listing the risks with that given that your approach won't work for too long.

If you really need to use a certificate for https://app.example.com, create a certificate locally (so that each client have a different certificate), properly constrained, and add it to the client certificate store.

Plus, obviously, the server running in the client shouldn't do silly things such as allowing launching arbitrary programs, or exfiltrating client files. That local server is a security boundary, so it shall be very careful validating any input…

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.