Authentication between two internal servers

Question

I have two internal servers that are going to communicate with each other; they speak HTTPS. Is there a best practice for authenticating communications between internal servers?

Short of a best practice, my current idea is to have both the server and the "client" (really another server, but a client in the HTTP sense) verify that the other end presents a cert that is signed by a well known CA. I'm thinking of using a self-signed cert as the CA, and just distributing this cert to the machines as part of our automated deployment. (We also have a cert for example.com and *.example.com, but I'm not sure how wildly I want to distribute that cert's corresponding private key. Also, it's my understanding of centralized CA's that I can't create a foo-service.example.com cert without giving more money to and waiting on an external CA.) Is this fine?

Mostly, if the client inadvertently gets pointed at the wrong server (e.g., a DNS record gets pointed to the wrong IP) then things refuse to work. (Also, someone roguely connecting to the server shouldn't have their request accepted.)

I've thought about having the servers just have secrets, and pass them over HTTP headers, but someone would be passing their secret first without having first authenticated the other side. (Though crypto could fix this, it seemed like I'd just re-invent TLS certs.)

Answer 1

There is no need to involve a certificate authority (CA), or trusted 3rd party, when you control client and the server. By avoiding the need to have a CA, you are no longer threatened by rogue certificate authorities, and rogue certificate authority certificates.

Using two self-signed certificates it is possible to create a very strong TLS connection between two systems. Both the client and the server generate their own self-signed certificate, then the public keys are swapped.

• The server uses TLS Client Authentication to ensure the client is using a known certificate.

• The client uses certificate pinning to ensure that the server is using a known certificate. There is a draft RFC which extends HTTP-Strict Transport Security (HSTS) to allow for signature chain validation. In the near future, the client will use HSTS for this requirement. For now, client-side certificate pinning requires a platform specific implementation.