In this article:
First, let’s talk about SSL (now called TLS by the way), which adds the ‘S’ at the end of HTTPS and is in charge of “securing the communication“. The clue to answer this question is indeed to fully understand what we mean by “securing the communication”.
SSL, no matter if it is a self-signed certificate which is being used or one signed by a trusted CA, will ensure that the communication between you and the remote host remains confidential and that no one can tamper with any data exchanged.
The warning message shown by browser about self-signed certificates is therefore not about that.
But, how can you be sure that the remote host answering to your requests is really the one you expect? With public websites, for which you have no direct way to authenticate the certificate by yourself, this is just impossible. Here comes external trusted CA: by trusting a CA you assume that all certificates signed by him are used only for legit purposes to secure the traffic with the server(s) explicitly mentioned in the certificate.
This is all this warning is about: your browser warns you that, while the communication with the remote host is secured, it has no automated way to authenticate the certificate (and therefore the remote host identity) and relies on you to explicitly accept or refuse to establish the connection.
If the self-signed certificate is associated to one of your servers, you should be able to proceed with this manual verification: you should be able to check the certificate fingerprint, or at least you should know if the certificate has been changed recently or not.
Once this manual verification has been done, your browser offers you the possibility to “remember” this certificate: this means that the browser will associate this self-signed certificate to this URL and provide no warning in the future since, now, the browser has an automated way to authenticate the certificate.
However, as soon as the self-signed certificate will be changed on the server, the browser will display the warning again, and it will again be up to the end-user to determine wether this certificate change is normal and if the new certificate presented by the server is indeed a genuine one.
IMHO the default way browsers inform the user’s about current security is mostly ineffective. Users just do not care about the padlock, and do not notice when the SSL security is missing. Even users who care haven’t access to the right information (nothing prevents a website showing an Extended Validation Certificate to configure their website to use poor and weak cryptography systems or to rely on less secured third-party content: default browser’s interface will still be happy about that and show the “top-notch security” green bar).
Hopefully, depending on the browser used there might be some plugins trying to remedy this situation. On Firefox, you have SSLeuth which will by default add a new notification area to the left or the URL bar (next to the padlock when there is one)
This new notification area has the following properties:
The background color ranges from red (no security: HTTP), through orange (poor security setup) to blue and green (good and best security according to current best-practices).
An option allows to extend this color to the whole URL bar, so HTTP websites will now display a fully red URL bar,
At last a score (between 0 and 10) is displayed to show an estimation of the current SSL/TLS security level. It takes into account several criterion, amongst them the type of certificate (self-signed, CA signed, Extended Validation Certificate), the cryptographic configuration used, third-party content security, etc. Clicking on the notification area provides all score details, mostly useful when the result is not the expected one (aka “Why is my bank website granted an orange URL bar?“).
Article based on a StackExchange answer.