I'm having a hard time finding the practical benefits of transmitting a self-signed certificate over simply a public key. I understand that a self-signed certificate proves the integrity of the public key and user ID (i.e. proof the signer is able to decrypt messages encrypted by the public key), but what is the practical security benefit of this knowledge?

From what I understand, both sending a self-signed certificate and sending simply the public key are susceptible to man-in-the-middle attacks:

  1. Alice and Bob want to communicate privately.
  2. Mallory is between Alice and Bob.
  3. Mallory intercepts the public keys or self-signed certificates.
  4. Mallory creates a new keypair, and self-signs in the case of self-signed certificates.
  5. Mallory relays the new public key or self-signed certificates to Alice and Bob respectively.
  6. Mallory is now transparently between Alice and Bob.
  7. Alice and Bob mistakenly believe their communicate is private.

Since Mallory can just generate new keypairs and self-sign, a man-in-the-middle attack can be executed quite as straight forward as if solely public keys were exchanged.

I've also considered a denial-of-service attack, where Mallory can corrupt the user ID or public key so that Alice/Bob can not decrypt messages and thus not communicate. A self-signed certificate would allow Alice/Bob to tell that there is a corruption as soon as the certificate arrives, whereas a public key by itself would only be discovered as corrupted once the response is received.

However, Mallory gains no benefit in performing this convoluted denial-of-service: Alice and Bob are not revealing secrets as they are not able to communicate, and simply blocking network packets is a far simpler way of denying service to Alice and Bob.

So in what practical ways is transmitting a self-signed certificate more secure than transmitting a public key by itself?

See also

Public keys without the certificates

  • 3
    None. There's no security benefit. It's just that tools like openssl are setup to work with certificates, so it's more practical to use a self-signed certificate rather than no cert at all.
    – paj28
    Commented Sep 25, 2014 at 15:14
  • @paj28 So self-signing is more a way to integrate a public key with no third-party signature into an application that is only configured to accept certificates (i.e. keys with signatures)? Commented Sep 25, 2014 at 15:16
  • 1
    Yes, that's it, exactly!
    – paj28
    Commented Sep 25, 2014 at 15:17
  • @paj28 please post this as an answer
    – Philipp
    Commented Sep 25, 2014 at 16:30
  • I just wanted to say that simply because you capture the self signed certificate or the public key, the communication is still private. Sure, you could form your own key-pair with a new self-signed certificate and Bob will trust you and you can start a session, but Alice will not. Unless you inject a root certificate into Alice, all you can do is relay the connection without ever knowing the private key of Bob. Either that, or Alice decides to trust you on her own behalf. Commented Sep 25, 2014 at 17:04

2 Answers 2


None. There's no security benefit.

Tools like openssl are designed to work with certificates. This means it's more practical to give openssl a self-signed certificate rather than no cert at all.


Only if you are signing multiple certificates. Self signing doesn't give any more validation that you are who you claim to be than a public key does, however, if you have, for example, 3 different public keys and all are signed with your same self-signing private key, then someone could verify that all 3 keys are either all invalid or all valid (though they can't tell which without verifying your root key first). We know that all 3 keys were approved by the same person, but we don't know who that person is without verifying the root. With simple public keys, they wouldn't be able to verify that the 3 public keys are linked in any way.

You must log in to answer this question.

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