Safest method for self-signed certificates on client?

Question

Context of Problem

I am writing a piece of middleware. The middleware runs on a client machine. It downloads material from a server (using normal SSL), decrypts the material using a private key on the client machine, and provides a standard interface for third-party applications to access. The third-party applications expect an SSL certificate, even when they are configured to connect my middleware on localhost. I don't want my users to have to click through security exceptions, and these days not all applications even allow for security exceptions to be made.

Therefore, after installation my application needs to support an SSL connection without the user having to fight against a self-signed certificate, but obviously without opening the user to MITM attacks.

Proposed Solution

This is the best plan I have right now for the client installation process:

1. Generate a CA locally
2. Generate a certificate locally for domain localhost
3. Use the CA to sign the certificate
4. delete the .key file from the CA so it can never be re-used
5. install the CA .cert file to the system's trusted CA list

Question

• Are there security holes in this plan?
• Is this strategy in use anywhere else?
• Is there a better way to approach the problem?

---

Clarification

Let me be really clear, the server does have an SSL certificate. When the middleware talks to the server, it uses SSL. That is not in question. It is the connection between the 3rd party client and the middleware (which are both on the client machine) that is in question.

What needs to work: I need 3rd party clients to connect to my middleware as if it were a remote server in a seamless fasion. If the 3rd party client were a browser, it would look like a little green lock icon next to the https. The user should not to have to accept security exceptions. Some 3rd party clients will not allow security exceptions at all, resulting in outright rejection of self-signed certificates. That is obviously obnoxious for my users.

What I am trying to protect against: I do not want to add a CA to the client machine that allows anyone who gains access to the machine to execute MITM attacks. That is why I would be deleting the CA .key file as soon as the localhost certificate was signed. Theoretically, a MITM attack could be launched with just the generated localhost certificate, but only against localhost connections, and not against www.mybank.com.

What I do not see as a threat: Anyone who has access to the client machine will already have access to everything passed between the 3rd party client and the middleware, as most 3rd party clients don't encrypt the materials they recieve from the middleware. Therefore I don't see the security of the generated localhost certificate as being particularly relevant.

Answer 1

The question you need to clarify is what you're trying to protect against. Your solution is fine if all you need is the little green lock icon in the browser, but it gets significantly more complicated as you start requiring more.

For instance, are you trying to protect the application from attack (what attacks?), or are you trying to protect the user from an attacker reusing the localhost certificate for other reasons?

In any case, an attacker on the machine can get access to the raw private key of the localhost certificate, or access to use the private key, regardless of the state of the CA.

This can be made more difficult by running the service as a separate service account, and locking the key to that user, but any administrator on the machine can bypass this. You can then mitigate this further by making sure the human users aren't running as admin (this naturally turns out to be the hard part).

Answer 2

It depends on your relationship to the the people who will be consuming the service you are designing. What you describe means that you can't revoke the issued certificate. How would you (or someone else) go about removing the trust for the certificate?

Is there a better way to approach the problem?

Go buy a certificate from an existing public certificate authority (or get a free one from let's encrypt).