Client Certificate Authentication enough multiple server-backends and multiple server-clients

Question

I have a flexible number of servers A (same type of servers but located in different regions, so serving different data) that need to authenticate api calls from a flexible number of servers B (same type of servers but located in different regions).

Any server B can call any server A. And of course, a server A in one location is actually a load balanced bunch of multiple servers.

So I need all calls from servers B to be authenticated when calling any server A, and instead of doing something equivalent to what one would do with tokens/sessions/..., I narrowed down to Client Certificate Authentication.

However, to avoid a devops deployment nightmare, what would be the best strategy? - One unique client certificate used by all servers B (easiest?) - One unique client certificate used by all servers B for each server A? - One unique client certificate used for all servers A, but different per server B? - A cartesian multiplication of unique certificate server B for each server A?

In order to give a scale, there can be >= 10 servers A and >= 30 servers B.

Thanks!

Answer 1

There is more than one way to do this, but if it were me doing it, this is the way I'd choose:

Servergroup A

These servers should have a server certificate, not a client one. Since they will all be accessed using the same hostname, they should use the same server certificate. This certificate must be issued by a CA that is trusted by the servers in servergroup B - this can either be a generally trusted CA, such as letsencrypt.org or Digicert, or it can be a local CA that you set up (in which case you need to distribute the root CA cert to the B servers).

Servergroup B

These servers should use client certificates. Here, I'd use one certificate per server, instead of having all of them share one. And I'd use a local CA, internal only to my own organisation, to issue them. I'd set up the A servers to allow access by any client that uses a certificate issued by my internal CA.

The reason for not using a public CA is that it's a lot easier to grant access to all certificates issued by a CA, instead of checking to see if the certificate contains e.g. the correct organization, or the correct hostname. (Obviously you also want to check that the certificate hasn't been revoked, so your CA needs to publish certificate revocation lists, or maybe even allow OCSP checks.)

I would also recommend using a configuration management system, such as puppet or ansible, to automatically enroll the B servers to the internal CA when they are installed, and to renew the certificates as necessary. There are a number of protocols that can be used for this; I'd recommend either CMP or EST. (EST is newer; it's specified in RFC 7030 and you can test it at http://testrfc7030.com).

Setting up an internal CA

If the internal CA is only used to create these client certificates, you can use pretty much any CA software you like and are confident that you can manage.

• OpenSSL is available for all operating systems, but it's not very easy to use, though with some scripting it's very versatile.
• If it were me setting it up, I'd use EJBCA, because that's the software I know best and it's fairly easy to use. It's open source and you can download a pre-installed virtual machine to test it out. (Note that this pre-installed machine should not be used in production without significant work done first; it's not been hardened and every virtual machine has the same admin key!)
• If you're running on Windows, then Microsoft Active Directory Certificate Services is probably your best bet; it's integrated from the start.
• If you're running RedHat, maybe look at RedHat Certificate System.