3

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.

nihilist84
  • 131
  • 2

3 Answers3

1

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).

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 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). – makerofthings7 Aug 10 '15 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... – Thomas Pornin Aug 10 '15 at 17:13
0

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.)

Romeo Ninov
  • 638
  • 5
  • 11
0

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.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
  • Not if the certs are using a common CA. – StackzOfZtuff Jun 12 '15 at 06: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? – Mike Ounsworth Jun 12 '15 at 11:47
  • Oh, I see. Not initial load-balancing, but **Re**balancing. 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. – StackzOfZtuff Jun 12 '15 at 12:02