How to set up certificate architecture for on-premise server-client application

Question

We are currently shipping a product to our customers that is server-client-based running on Windows server 2016 (server) and Windows 10 (clients). The server is installed on-premise in our customer's infrastructure. We are always installing the server in our customer's network for our customer, but it runs on the HW from our customer and is also officially operated by him. The clients are installed by our customer.

We are using certificates to secure the traffic between server and client. The customer can chose to use their own certificates or we create a self-signed certificate when we install the solution on site.

I would like to improve the situation and provide a solution that works seamlessly for all customers. Currently the customer that don't want to take care of their own certificates get a self-signed certificate that is generated by our installation team. However, in order to not have a problem with man-in-the-middle-attacks our customer now would need to bring this certificate to all client PCs and install the server's certificate when installing our client application. Since the self-signed certificate cannot proof that it is coming from the server that I actually want to talk to I need to bring the certificate to the client. For me this feels like having a 1-time-password, passing it to the 2nd communication partner to make sure that I am talking to the right person/party.

Is there a better way?

I would be willing to pay money to issue a certificate for each of our servers that is operated on-premise inside of the customers network. But since it's not in our network I guess that we would have a problem with the FQDN as I cannot sign up for a server with a FQDN inside of my customer network which is hosted by my customer. I my mind I am comparing the user-experience of our solution with a web-service. Nobody wants to think about certificates when connecting to a webpage. The webpage provider should take care of that. Of course he does that requesting a certificate from a CA which is trusted by the customer and/or the operating system which runs the server. Also our customer doesn't want to think about certificates - he wants us to handle this. Any ideas?

Thanks in advance

J.

Answer 1

There can be different solutions.

1. If customer doesn't want to order and install a valid certificate on server, they should install your self-signed certificate on each client. Then clients will consider this certificate as trusted. Man in the middle will not be possible. For each customer you should use a separate self-signed certificate, so that when private key at one of the customers gets compromised, other customers are not affected. When private key gets compromised, the customer will have to remove the old certificate (otherwise it remains trusted and can be used for man-in-the-middle attack) and to install new certificate on all clients of this certificate.

2. Establish your own CA, as @mti2935 suggested. The certificate of any root CA is a self-signed certificate. Thus your customers should install your root CA certificate as a trusted CA certificate on all their clients. Keep the root private key as secure as you can. Use it only to issue sub-CA certificates. Establish your own sub-CA. Use this sub-CA to issue certificates to the servers of your customers. The advantage compared to the first approach: In case one of the customers server gets compromised, you just issue a new certificate for particular customer, and customer does not need to reinstall anything on their clients. You will have also to establish your own certificate revocation service. In case some server got compromised, you should declare its certificate as revoked via your service, so that clients don't trust it anymore.

3. Establish your own CA and embed its certificate into each client. Make client code for certificate validation trust this certificate. Means, it will also trust any other certificates issues by your CA. As in previous case, keep the private key of your CA as secret as possible. Establish your own sub-CA and use it to issue server certificates. Advantage: Installation of your certificates on each client will be not needed. In case some server got compromised you will reissue a certificate just for this server. As in the case above, you will need your own revocation service.

4. Do hosting for customers. No matter if you do that physically or you use some hosting provider. Then you will be able to get certificates from well known CAs. Customers will not have to install any certificates on their clients. Also you will not need your own revocation service.