0

Well, let's imagine that server S provides a service to a given set of clients C1 and C2 with secured cert-based authentication (think of OpenVPN, SSH or other similar services).

  • S could use a trusted CA or create its own to let C1 and C2 know that he is the real S (what OpenVPN, HTTPS, etc. do). This requires the CA cert to be pre-shared with each client.
  • S could just present its certificate to C1 and C2 the first time the clients connect to it and the client would check whether this certificate is the one expected (what SSH, Syncthing, etc. do).

The thing is:

  1. Some systems (*cough* android... *cough*) just add the custom CA directly into the global trust store (OpenVPN).
  2. Also p12 format is pretty convenient, whereas pem is dreadful for the user, yet we often don't have the choice (why are there 4 files? what's the key you were talking about? what's the private cert? why ca.cert does not work as my private cert?...).
  3. The users don't like/are not allowed to validate/type stuff on both server and clients to authenticate each other (Syncthing).
  4. Yet they can't be bothered to check a certificate hash thoroughly (SSH).

A (possibly dreadful) way to solve these problems (and create others) would be to directly use S private key to sign C1 and C2 certificates:

  1. No new CA to add to the system-wide trust store.
  2. Only one file to handle in both p12 and pem formats.
  3. The user doesn't have to access S.
  4. The user doesn't have to check anything as long as he can trust the signed certificate given to him (through HTTPS/SSH, etc.). NB: this trust problem is the same when you have to get the CA cert on each client.

The thing is that I have not heard of such a scheme before. I thinks it is mostly because it does not provide strong improvements over the CA-based scheme, but it could be because the approach is flawed.

So, are there bad security implications arising from using this kind of scheme?

PS: I am asking out of curiosity because I don't know any protocol using this scheme, yet it seems a bit simpler.

  • 2
    This is a "self-signed certificate". They're generally considered a bad thing. – paj28 Mar 2 '16 at 11:33
  • But in OpenVPN for instance, you just don't have a choice... Yes, your server certificate can be signed by a trusted CA, but you can't do that with clients. Of course, I agree with you for one-server-to-many-anonymous-clients connections (e.g. HTTPS). But other than that... I mean, OpenSSH is not built around trusted CAs and I am not sure it should be. – JPatta Mar 2 '16 at 11:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.