In order for self-signed certificates to securely protect communication between devices and servers, the devices must be setup to “trust” the self-signed certificate. This is generally done by installing your CA on each device. In the past, this would be easy to do as organisations have complete control of the devices that their employees use. Unfortunately, that is no longer the case these days.
Organisations often resort to letting their end-users “trust” the self-signed certificates by advising the end-users that they can safely ignore browser warnings when connecting to (say) the HR self-service website. It’s less of an issue if the website is accessible internally within the organisation, however it’s a totally different story if it’s publicly accessible over the Internet.
Aside from teaching the end-users a bad browsing habit (it’s safe to ignore invalid certificate warning on your browsers), the bigger problem is that it makes the communication between the servers and clients vulnerable to the man-in-the-middle attack (information being communicated is intercepted - observed/modified by a third party).
Secure communication using SSL is two-fold: data encryption, and ability to verify that the client is indeed talking to the server that it thinks it’s talking it. Data encryption will happen regardless of the type of certificate you use, but if the browser gives out a warning about the certificate, it means it can’t recognise the authority of the certificate, which means that it has no way of verifying if you are actually talking to a the legitimate server.
It’s therefore important to note that if you choose to use self-signed certificates:
- You must somehow get the client machines to trust that specific certificate (or CA).
- Do not ask your end-users to ignore browser’s certificate warnings
- Do not turn on “accept invalid SSL certificates” options in LongRange.