How can I explain self-signed certificates to users?

Question

I don't trust certificate authorities, so I'm using a self-signed certificate on my server. The server provides both a website as well as other services.

Most modern SSL-capable software, upon encountering SSL, checks if the certificate is given by a CA and if not throws up a very scary warning. Contrary to Mozilla's logic, I believe that in my case a self-signed certificate is actually more secure, because it avoids the risk of malicious or incompetent CAs.

But let's say I want to give a friend access to my website or my server. Maybe I have a few photos on it from my trip that I want to show them: If I just give them the secure URI, their computer will also throw up the usual warnings. But since unlike me, they weren't the ones who configured everything, how will they know that Everything Is Fine™ (unless the fingerprint doesn't match)?

I could have a little notice in the HTTP version of my page explaining the error, and how to manually verify the fingerprint and make sure that Everything Is Fine. But:

• If the connection was compromised, the attacker could just alter this notice to say "nah bro self-signed certs are totally fine, trust me".
• If the user goes straight to the HTTPS URI, how will they know to check the HTTP version?
• If the user uses a non-web service accessed through its own program, how will they even know about the notice?
• If the user doesn't know how SSL works, they'll just believe their browser and close the site, instead of investigating why there is a self-signed cert (since unfortunately the documentation/UI authors' attitude seems to have been "there's no good reason ever").

So how can I ensure that when I send a user to my server, and they are confronted with the "self-signed certificate" warning, they are able to decide for themselves whether to trust it or not, instead of having to believe the skewed picture that their software paints for them?

I don't want to tell users to "just ignore the warning, it's fine", because not only does this reinforce a bad habit in general (what if their CA-verified bank gets compromised one day and presents a self-signed cert?) but also there would be no way for them to tell if my server is compromised.

Also worth mentioning is that the certificates are not forever, and eventually expire, so the user must be able to tell the difference between suspicious change of cert (say well before the planned expiration of the current one), suspicious change of cert that is made to look non-suspicious (a MITM executed just when I was scheduled to renew my cert), legitimate change of cert (when my cert expires and I issue a fresh one), and legitimate change that happens to look suspicious (I decided to issue a new cert way ahead of schedule for whatever reason).

We can assume that:

• I have few users, so scalability is not so important. For instance, the users emailing me or calling my phone number to verify the certificate are perfectly valid solutions.
• The users trust me and can communicate with me through a secure channel. For example, they can talk to me in person or send me encrypted email.
• The users are reasonably intelligent, and can be expected to understand basic security concepts like "if the certificate changes unexpectedly, the site may have been compromised".

My main concern is dealing with less technical users, who would be confused when they see the self-signed certificate warning.

Answer 1

So how can I ensure that when I send a user to my server, and they are confronted with the "self-signed certificate" warning, they are able to decide for themselves whether to trust it or not, instead of having to believe the skewed picture that their software paints for them?

If you are not using pre-defined trust anchors (e.g. the root CA of the browser) you have to find a way to give your users the necessary trust information in a secure way. The preferred way would be of course personal, because any indirect ways like phone call or PGP signed mails need a pre-established trust, e.g. associating phone numbers or keys with you.

Also worth mentioning is that the certificates are not forever, and eventually expire, so the user must be able to tell the difference between suspicious change of cert...

In this case you have again inform the user about the change in a secure way.

The whole idea of the trusted CA in the browser is to start with some pre-defined trust and then defer trust information about other sites. This is similar to real life: you initially trust some people (parents..) and from them to learn trust other people. But once you abandon any initial trust settings you have to start from zero and thus find your own way to make your users trust you.

If you want to establish your own certificate as trusted you can only start with the existing trust relationships, i.e. friends which know you directly, know your phone number, your PGP key etc. These trust relations then must be used to transport the new trust into your certificate (i.e. fingerprint or similar). The best approach then depends on the kind of trust relations you already have to your friends and which one can be used as the best transport for the new trust.

Answer 2

Edit: The question author made significant edits to their question after this answer was posted. This answer is based on an earlier version of the question which gave the impression that they were asking about a usual public website.

You can not explain that a self-signed certificate is fine, because on a public website it is not! The other question you mentioned was about a different context: Using your own CA to sign your certificates and have a limited and known number of clients which trust that custom CA. From the perspective of the browser this is technically not different from using an "official" CA and it requires that the clients obtain the CA root certificate via a trusted channel. But with anonymous internet users, this is not possible.

No matter how much you distrust the CA system (and you have good reason to do so, but that's a different topic), using a self-signed certificate on a public website is even worse. Any MITM attacker could decode the communication, replace your certificate with their own and re-encrypt it for the user. Without a trusted 3rd party to verify the signature of the certificate, there is no defense against this. So there is no way to verify that indeed "everything is fine".

Providing the fingerprint of your certificate is pointless, because you have no way to send it to the user in a way which can not be manipulated by the MITM attacker. A https website can be manipulated as previously described, and a http website is even easier to manipulate. The attacker could just replace the fingerprint on the website with that of their own.

There is hope that one day a better system like DANE (which moves the trust role to the DNS system) will finally replace the flawed CA system, but until then certificate authorities are still the best solution we have.

Answer 3

When you have secure(!) contact with all of your users over a different medium, you can send them the root certificate of your own certificate authority which you used to sign the certificate of your website and give them instructions how to add it to the list of trusted certificates of their web browser (or maybe even a handy install script which does it automatically).

When they did this correctly, the website will no longer appear as self-signed in their browser. The browser will instead treat it like if it were signed by any other "real" certificate authority.

This, of course, does not protect your users from a rogue CA which creates a false certificate for your website, because common web browsers do usually not support CA pinning (telling them to only trust one specific CA for a specific website).

You should also make your users aware that this means that you now can also impersonate other websites they visit, so it requires a large amount of trust. This problem is also not fixable, because currently there is no such concept as a CA which is only trusted for specific domains.

Thankfully, this problem might one day be solved with DANE which puts the DNS servers into the role of the certificate authorities. You will then be able to distribute your domains TLS certificate by the DNS server which is responsible for your domain (and only that one). But currently there are no browsers which support it out-of-the-box, and considering that there are several companies which have financial interests in keeping the CA system (which is practically a money printing license sold by browser developers) it might take a while until it takes off.

Answer 4

The Best approach (for the use case of a limited user group and a personal website) I use is to have a non secured page somewhere where my users can download the root certificate (my own CA) and find instructions how to install that into there trust store. this way the computer can trust my 'self-signed' certificate.

one of the headaches with this approach is that for windows or mac it usually suffices to put it in the systems key-store application. on Linux / UNIX most applications have there own certificates store. And sometimes browsers have there own store. I usually solve this by offering my users (remote) help installing the certificates and putting it on all the right places.

but with a user group of less than 100 people this is feasible.

as to your "more secure" remark. It is impossible to say its more secure. Those other CA's have regular audits. I doubt you have the time / money to be audited like a CA. so we simply do not know if your more secure.