How to implement TLS between microservices

Question

Can someone please comment on, vet, critique, or otherwise blast holes in the microservices security design I’m considering?

Let’s say I have three microservices, each of which talks to the other two via REST endpoints. Each microservice contains a keystore. In this keystore is the containing microservice’s private/public keypair, signed by a trusted certificate authority. Also in this keystore is the other two microservices’ public key certificates, exported from the source microservice’s signed/trusted keypair.

This implementation works, but something doesn’t quite smell right about it.

Namely, every time I introduce a new microservice I must add a) each existing microservice’s public key certificate to its keystore, and b) the new microservice’s public key certificate to every other microservice (the assumption being the new microservice must communicate bi-directionally, and securely, with each existing microservice).

Now, repeat the above pattern for a second keypair, this one used to sign/verify authentication tokens supplied in REST calls.

I am wondering if, instead of the above, it is a) advisable and b) safe to share a single trusted public key certificate between all microservices? Something completely different?

Please be polite. I am by no means an expert it this area.

EDIT: It occurred to me, after reading replies/comments to my original post, that I omitted detail that might have made the problem more clear, and therefore the commenters better able to address it:

1. The microservices in question exist within a private intranet, and will only ever be accessible by clients (browsers or other microservices) within that intranet.

2. There is in fact a trusted CA—namely, the company that owns this intranet—and it is that CA that signs the microservices’ keypairs.

The resolution to this problem, it seems, is implied in @Andreas first comment, in which he wrote, "As long as the CA that issued them is trusted, they will be trusted too.”

As long as each new microservice is deployed with a) its own keypairs, signed by the CA (one for signing and the other for encryption), and b) the CA’s certificate, I can deploy new microservices with reasonable assurance they will communicate securely with all other microservices (reasonable because of other potential vulnerabilities I am not even aware of).

Somehow I got it into my head that I would have to create a brand new certificate for each microservice’s keypair, and include these in the other microservices' keystores (repeat for every new microservice). Instead all I need is one certificate, that of the CA that signs the keypairs, in each microservice’s keystore.

Answer 1

One way to do it (your question is broad, and without code it may be more on-topic on SoftwareEngineering than here) is the following:

1. create your own CA
2. (optional, create a sub-CA only for your microservices)
3. generate all certificates by this CA
4. make your code trust all certificates from this CA, instead of checking the certificate itself (but you should still check the dates, the correct signing, etc.)

In that way, when you introduce a new microservice you have only one certificate to generate for it, and nothing to change in the other microservices, which is a goal you need to reach otherwise it can not be managed.

By doing it like that you can even move some of your microservices outside your systems, as needed. They just need to be shipped with the CA public key.

I would advise against reusing the same certificate for different microservices as it would only lead to problems.

Also, loosely related but make sure to read this: https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf it shows various pitfalls when using TLS outside the web. It is an eye-opening. While being targeted only at TLS specifically and not PKI problems, this Internet-Draft (https://datatracker.ietf.org/doc/draft-gutmann-tls-lts/) can provide useful insights on how to properly implement TLS1.2 with some secure default choices. The "LTS" part specifically means "Long Term Support".

Have a look also at this related question: https://security.stackexchange.com/questions/175627/securing-internal-micro-services-letsencrypt-vs-self-signed-certificates-be and the answer giving you other ideas, like using a vault.

Answer 2

If your micro services are not exposed to the web , then you can create Self Signed Certs for that purpose .The Self signed certs are used for intra calls.You can create them on sslshopper site.

Also, dont use the same certs for all micro services. I have implemented the similar solution , in our case we have set up Signed Service as another micro service which will cater to other micro services.This Self Signed Service will connect to HSM or Hardware Security modules.All the Certs are stored inside the HSMs belonging to the profiles.You can do some googling on HSM and it profile creation.

Trust stores are used for keeping public certs and key stores are used for storing private keys .Thats the standard, not universal but in ideal scenario's.