typical purpose of self-signed certificates

Question

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?

Answer 1

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)

Answer 2

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.