Just a few points to add to @Cheekaleak's answer.
The Certification Authority (CA) is the entity issuing a certificate for a server (amongst other things). By doing so, the CA signs with its private key the content of the certificate and adds its signature.
To indicate who signed the certificate, X.509 certificate have an Issuer Distinguished Name naming the CA, in addition to the Subject Distinguished Name identifying the entity for which the certificate is issued.
CAs themselves have CA certificates, that is, certificates that can be used to issue other certificates (by signing the issued certificate using the private key matching the public key in the CA certificate, and by using the CA cert Subject DN as the cert Issuer DN). This builds a hierarchy from CAs to End Entities (e.g. servers), and there can be intermediate CA certificates (i.e. a CA cert used to issue another CA cert, which may then be used to issue an end-entity certificate). The root CA certs at the top tend to be self-signed.
The way browsers evaluate their trust into a given End Entity Certificate (e.g. a server certificate) is by building the certification chain between the EE cert and a CA cert they already trust (trusted anchors). Most OS/browsers come with a bundle of CA certs trusted by default.
(The second aspect of this is that the browser verifies the EE cert has been issued to the name of the server it wants to connect to.)
The main problem of this model comes from the fact you don't really know why you should trust the CA certs that are bundle by default with the software you get, because a rogue or badly-managed CA that would have its CA cert in your trusted anchors could issue a certificate with the name of the legitimate website.