I'm having a cluster with nodes (let's call them A and B for the sake of example) running identical micro services (1, 2 and 3 - so the application 2 running on node A is called A2). The applications with the same numbers are completely identical.

Each application instance (micro service) is accessible via HTTPS.

I wonder what is the best practice to manage the PKI material used for the HTTPS connector of the applications. Can you give some things to consider?

I'm considering the following setups, but can't really decide:

  • A1, A2, A3, B1, B2, B3 should have their own specific key pairs (per application instance)
  • A1 and B1, A2 and B2, A3 and B3 pairs should have their shared key pairs (per application)

Every key pair can be signed by a common trusted CA, so that is not an issue here.

3 Answers 3


Generally speaking, each private key should be unique, and private keys should not travel.

If you have several "applications" that expect HTTPS connections (on port 443, SSL/TLS handshake...) and that run on the same machine, then the application are not, actually, doing the SSL. The SSL is handled by the Web server frontend (say, an Apache or IIS): that frontend does the SSL, then (only then) receives the HTTP request, learns the target path, and thus knows to which application the request shall be dispatched. In that kind of setup, the private key and the certificate are not owned by the applications, but by the frontend. In that model, you would give one private key and certificate per machine.

The paragraph above assumes that your "micro services" really are all registered on a common HTTP+SSL engine, as is expected if they all use the default HTTPS port (443) and the same IP address. You could do otherwise, e.g. run the different services on distinct ports (the connection URL will then have to include the port name), or even on distinct IP addresses (if each machine owns several IP addresses). In that case, each micro service may run its own HTTP+SSL engine, and thus have its own certificate and private key.

There are two main reasons why you would want to make several private keys and certificates:

  • You want to give certificates to systems that are not equivalent to each other in terms of security, e.g. they belong to distinct customers who do not fully trust (or even know) each other. The idea is that knowing a private key used by a server allows (conceptually) impersonating that server. Similarly, having distinct certificates allows revoking one without revoking the others.

  • Private keys that travel around are "less private". It is best when private keys are generated on a machine and never leave that machine. Thus, if you have 10 servers, you would want to have (at least) 10 private keys. Moving private keys around safely is doable but requires care (copying over SSH connections should be OK).

  • Regarding private keys not traveling, what about email signatures? Or decryption of inbound emails? Keys need to be on multiple devices (phone, work, kiosk, etc). Aug 10, 2015 at 16:58
  • The more a private element is copied, the less private it becomes. You want to have your key on a lot of devices, but this implies that the key is no more secure than the least secure of these devices. That's your call... Aug 10, 2015 at 17:13

For me each application should use own key pair. As app on all cluster nodes is the same they should expose to the client on the same way.

From other side i do not see any problem to have one key pair for all servers and applications (if they have something in common, part of big application, etc.)


One argument that comes to mind is that often designers want the cluster to be agnostic about which node a user is connected to; ie the user gets the same output regardless of which node did the processing, sessions started on one node can be load-balanced to a different node without the user knowing, etc. Having different certificates for each node would prevent this.

  • Not if the certs are using a common CA. Jun 12, 2015 at 6:28
  • @StackzOfZtuff Don't understand. If nodes have different certs, and the user is load-balanced to a different node, they'll have to re-do the TLS handshake, no? Jun 12, 2015 at 11:47
  • Oh, I see. Not initial load-balancing, but Rebalancing. Hm. I don't think there's a simple way of doing that. You'd need to synch session tickets or something between cluster hosts. And then let the users reconnect using session resumption with those tickets. I don't know if that would work at all, but I don't think different certs would make a difference. -- I was more thinking about the loadbalancer terminating TLS and then establishing TLS again to the backend. If you install the CA on the loadbalancer, then you wouldn't have to worry about backend certs as long as they are signed. Jun 12, 2015 at 12:02

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.