Am I right in thinking that SSL certificates from a CA are purely for identification purposes and serve no purpose in the actual encryption of data? In other words if I were to create a self signed certificate, would https communication be just as secure as using a certificate from a trusted CA even though the user would not be able to confirm the identity of the certificate owner?

3 Answers 3


Well, technically, if the user cannot confirm the identity of the certificate owner, then the communication cannot be really secure, because a villain may impersonate the server; he may even relay the data to the right server transparently (that's the man-in-the-middle attack model). Making sure that you talk to the right server IS an integral part of the security.

  • 2
    Thanks for the response. Assuming I was the user and I could confirm an unsigned certificate would the communication channel be secure?
    – Imran Azad
    Commented Oct 24, 2011 at 22:09
  • 1
    @ImranAzad: Yes.
    – bstpierre
    Commented Oct 24, 2011 at 23:45

I like the fundamental point of the accepted answer but figured I'd add this:

Cryptographically, you are right. An public/private key pair and algorithm are the same math whether you have a certificate signed by a Trusted CA or if you have self signed your own, as long as you are using same key size, same algorithm.

From a holistic security perspective - the other answers are correct - the system as a whole is compromised if the client has no reason to trust the server. Being signed by a trusted CA confers legitimacy to the server, which is crucial if the client is giving the server private information.

You could configure an equally secure point to point connection = setup a client that only trusts the 1 self signed certificate that comes from the server, and sneakernet the certificate from the server to the client. This isn't actually crazy in some scenarios where you have a front-facing public proxy protecting a backend server. In that case, the proxy is the only client of the server, and it may be worth while to set up a point to point SSL connection. The proxy, however, should have a signed certificate for talking to clients outside of the protected zone.


Not unless you have another means to identify the recipient.

Typically people use SSL to prevent eavesdropping -- only the intended endpoint should be able to glean information sent over the channel that is not gleanable from simple traffic analysis.

If you can't be sure that the endpoint for the channel is the intended recipient then you cannot prevent eavesdropping -- the self signed cert might be provided by an eavesdropper acting as a man-in-the-middle.

If you trust all the network infrastructure that allow you to establish a connection to the endpoint and fetch the cert (so DNS spoofing is not possible or is not involved) and you're sure that the cert-signer is not compromised then you might be able to get a definition of security based only on non-eavesdropping with self-signed certs.

  • Thanks for the response. How would an eavesdropper act as a man-in-the-middle, could you give an example please in the context of a web application?
    – Imran Azad
    Commented Oct 24, 2011 at 22:23
  • See infosecisland.com/blogview/… Commented Oct 24, 2011 at 22:30

You must log in to answer this question.

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