I am trying to understand the typical purpose of a self-signed certificate.

Reading this link on self-signed certificates and link on DV certificates I believe there is no information contrasting them so I infer that a self-signed certificate simply offers no assurance you are accessing content from an entity that controls the domain and that the purpose for a self-signed certificate on a web host is to merely make it feasible for SSL encryption to operate?

  • "...make it feasible for SSL encryption to operate?" - encryption yes but without being able to verify that you are talking with the intended party unless you have shared the self-signed certificate up front. And not being able to verify the peer means that you are open for man in the middle attacks, no matter if you encrypt or not. There are many similar questions on this site in case you need more details. Nov 17, 2017 at 5:37
  • It is not clear if you are asking specifically about use of self-signed certificates in SSL or use of self-signed certificates in general - since there are many more uses for certificates than SSL. Please clarify. Nov 17, 2017 at 5:45

2 Answers 2


While with Let’s encrypt offering certificates free of charge and easily today does take away the “it doesn’t cost anything” argument, there are still reasons why self-signed certificates can be useful, for example

  • for testing purposes (no CA is giving you a certificate for your local domain like testing.testenv.cooperation)
  • on local networks (to secure routers’ web interfaces, for example.),
  • as client certificates,
  • for S/MIME,
  • countering the problems of CAs in general.

The only real difference is that a CA-signed certificate is (usually) trusted without prompting the user for input while a self-signed certificate does need the user to validate it and put trust to it - for example by checking the fingerprint through a trusted channel. Once trust has been put into the self-signed certificate, it is as good as a CA-signed one (not counting rollover issues).

Self-signed certificates might come in handy when someone is not trusting the CA to not create a certificate for a MITM, for example.

Another big application of self-signed certificates (or more generally “non-CA-signed certificates”) can be client certificates: A web application can create certificates for authenticated users and use them to authenticate them from that point forward - certificate-based authentication is way better in terms of security than traditional username/password schemes and gets used often for B2B applications as well as mobile applications.

Using self-signed S/MIME certificates makes S/MIME about as convenient as GPG with the need to validate certificates manually (see above), but there are edge cases where someone without trust in a CA might have access to S/MIME encryption but not GPG (iPhone users, for example, as well as some corporate email clients)


Consider the case where you control the root certificate verification chain on both server and client (this would be the case when you develop both components). This could include scenarios such as:

  • Running your own e-mail, database or Web server which only would be used by people whose trusted certificates you can control;

  • Developing an endpoint or mobile application which would communicate with your own server;

Here using a self-signed certificate makes more sense than CA-signed certificates. The obvious advantages include:

  • Full control over certificate lifecpan, allowing you for example to sign the "evaluation" certificates to be valid as little as one week;

  • Full control over certificate content. For example, you can store the licensing information in the CNAME field of the client certificate, such as "10 workstations". Even for servers you can also issue wildcard certificates, which is something Let's Encrypt won't do for you at all (and which usually costs quite a bit).

  • The security properties of the whole system are known to you. This allows better assertion of risks, including coercion risks from nation-states;

  • You can sign certificates on the fly. This is useful in certain cases (I used it when implementing dynamic load balancing);

  • And of course it is (almost) free.

  • Letsencrypt plans to add wildcards in January. Nov 18, 2017 at 1:40
  • Let's see how it works for them.
    – George Y.
    Nov 18, 2017 at 5:20

You must log in to answer this question.

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