1

For a federated server-to-server protocol with domain-based identities, I am thinking of using TLS client certificates as authentication mechanism. I figured that re-using each peer's TLS server certificate as client certificate for connecting with other peers would be the simplest approach to implement this.

However, I am not sure if this double usage of a single TLS certificate can be considered secure. Do any special risks arise from using a single certificate as both a server and client certificate, similar to how using a private key for both signing and encrypting is problematic? I want to avoid creating a serious security problem out of mere convenience.

Improve this question

1 Answer 1

Reset to default
1

This scheme is often used for sendmail (MTA) and OpenVPN. It is decent, and I have until now only found one pitfall:

On the/each server, you have to carry a whitelist for:

  • the allowed CA (possibly, but doesn't hurt)
  • the allowed clients

How to specify the clients is up to the specific software. I'd recommend specifying their CN (commonName) and requiring that the presented cert is ① otherwise good and ② signed by the CA specified.

I'm implementing SSL client certificate-based SMTP relaying with this (beats SASL any time of the day, IMHO: the mailers (MUA) send to localhost, and localhost uses their (official) cert to connect the the smarthost, which uses that cert to permit relaying). OpenVPN setups with this are not very common (most people just whitelist one hand-made CA and permit all certs signed by it) but still in use (i.e. not rare either).

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .