Trusted CA certificates are validated by a third party, called Certificate Authority. In a cryptographic sense, CAs are a trusted third party (TTP) validation authority in a public-key infrastructure (PKI):
The primary role of the CA is to digitally sign and publish the public
key bound to a given user. This is done using the CA's own private
key, so that trust in the user key relies on one's trust in the
validity of the CA's key. When the CA is a third-party separate from
the user and the system, then it is called the Registration Authority
(RA), which may or may not be separate from the CA. The key-user
binding is established, depending on the level of assurance the
binding has, by software or under human supervision.
In a nutshell, they provide for an easier to establish trust of a client to the server they're connecting to, and the root certificates (CA public keys) used to verify such CA issued certificates come pre-installed on many web clients (browsers, email clients,...) by default, meaning they can be used in a transparent way, where no additional user interaction is required.
The assumed levels of end user's trust in connecting to the right server usually boil down to what is called certificate validation type:
- Domain validated certificates: These are most frequent, mainly because they're usually the cheapest CA issued certificates. These are usually validated by sending an authentication token via email to the CA that issues the certificate, and are only validating what their name implies - that the user is really connecting to the domain that the certificate was issued for.
- Organisation validated certificate: These certificates carry an additional information about the organisation they're registered to, and in some cases that can be helpful in establishing required trust. Most web clients don't assume much greater trust in such validated certificates than domain validated, and don't visually differentiate between them either.
- Extended validation certificate: As the name implies, these certificate type owners are most rigorously validated. They are not cheap and are supposed to provide for the highest levels of trust of the end user that the certificate owner is indeed the one they're supposedly connecting to. Criteria for issuing such certificates is described in more detail here. An added advantage is, that they're also clearly marked in most web clients by a green address bar, a green lock, or similar.
Now, what you describe as trusted remote certificate is also known (or perhaps better known) as a self-signed certificate, that the end user manually installs to the list of trusted certificates in web clients they use to communicate with the server that issues them. That is, provided they trust the issuer of such a certificate, since they don't provide for any third-party validation of its owner of any sorts whatsoever. They are still useful, as they can be used to encrypt the communication between the client and the server (most commonly for transport layer encryption), but the trust level is something left to the end user to decide. Such certificates are of course free (i.e. can be signed by open source tools, such as e.g. OpenSSL).