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