Ask any cybersecurity professional if using self-signed SSL certificates is acceptable, and they’ll probably say “not really.” Ask why, and we’ll say “we can’t always know who’s behind the screen,” even though we really want to say “Man-in-the-Middle attack.” Then we’d advise your server to utilize a certificate issued by a Certificate Authority trusted by your users, or one that uses an established Public Key Infrastructure (PKI).
In the reverse scenario, the solution is less straightforward. When the intended user is an average person using a web browser to reach your website, we assume the user will be seeking out an SSL certificate issued by a trusted certificate-issuing authority to be installed on your server. These authorities are called Root Certificate Authorities (Root CA). They are previously installed on the user’s computer because some other entity – think Microsoft, Apple, Mozilla, etc. – trusts the user, and the user trusts their operating system to look out for them. This path is the PKI.
When the user connects to your site from their browser of choice, your server presents its certificate. If the certificate follows an acceptable trust chain to a Root CA, as well as passes any additional validation checks, then an encrypted session is established. A padlock appears on the browser, and the user knows that your server can be trusted. Ideally, they will feel comfortable enough to send their passwords and information through your server. However, if your certificate is not trusted, then the browser will present an ugly, scary warning. Most users will ignore these warnings because they only appear when the user is using free WiFi, like at a coffee shop or in the airport.