The Secure Sockets Layer (SSL) protocol is popular in the Internet industry, primarily because of its use of public-key certificates as a means of authenticating principals. These certificates represent a possession-based authentication scheme; you are deemed to be who you claim to be (you are authentic) because you possess an appropriate certificate. The certificate identifies you and, through the encryption techniques used to create it, can be proved to be legitimate.
With SSL and public-key certificates, you trust the Certificate Authority (CA) that signed any certificates presented to you. If you do not trust the CA, then you do not trust the certificate, and by extension you do not trust the principal it represents. You only need to know about the relatively small number of CAs that you trust. As such, you can avoid building a large, central database of registered users (a user registry), which is essential in an environment that might consist of millions of end-users, such as the Internet.
Note: An important thing to understand is that, because SSL-based authentication is based on possession, anyone who can copy your certificate (actually the private-key that protects your certificate) is able to masquerade as you. For this reason, it is very difficult to use SSL-based authentication to perform delegation, that is, to perform down-stream method requests under your identity and authority. Further, since most enterprise information systems need to control access to their resources on an individual, group, or role basis, you often have to create some amount of central (or at least centrally managed) user database information in the form of Access Control Lists (ACLs).
A certificate is your key into a resource. Certificates are signed by an issuing CA and validated either on an individual basis or on a group basis. The larger the grouping, the more certificates are impacted if the certificate becomes compromised.