How does the certificate trust model work in detail?
A X.509 certificate contains the following information:


The name of the subject the certificate belongs to.
The public key of the subject. This public key corresponds to a private key. The subject is assumed to have exclusive access to this private key.
A reference to the issuer of the certificate (e.g. VeriSign or some other certificate authority). For a self-signed certificate, the issuer will be identical to the subject.
Some more fields, such as the validity period of the certificate, extensions that specify how the subject public key is supposed to be used, and various information the issuer decided to associate with the certificate.
A digital signature of the DER encoding of all of the above information. 


If the RSA PKCS#1-v1.5 signature algorithm is used, the DER encoding is hashed using a specified digest algorithm, that digest is PKCS#1-v1.5 signature encoded, and a RSA private key operations is performed on that encoding using the issuer private key. 

Server side, the server will obtain a server certificate by generating a key pair, keeping the private key strictly private, and sending its subject name together with the public key to a certificate authority. The certificate authority verifies that the entity that sent the public key also is properly identified by the subject name that was provided. If verified OK, the issuer issues a server certificate.

When a client connects using TLS (e.g. HTTPS), the server will send the server certificate as part of the initial handshake messages, and use the corresponding private key to generate or decode some part of the handshake (e.g. sign an ephemeral public key, or decrypt a key transport message), in such way that only an entity in possession of the private key, would be able to complete the handshake and end up with the same shared key as the client.

Client side, the browser will have a list of self signed root CA certificates corresponding to the certificate authorities the browser manufacturer has decided the client user should trust for server authentication. 

When the client gets the server certificate handshake message, it typically verifies the digital signature (using the public key from the issuer certificate), and that the subject name of the certificate matches the domain part of the URI it is attempting to connect to. Additional verification, such as offline verification of the certificate validity period, and online or offline verification of the revocation status of the certificate, is also recommended. 

If the server certificate checks out, the client extracts the public key from the certificate and uses it for completing the handshake. If the handshake completes OK and a shared secret integrity key gets generated, the information sent by the server from thereon will be authenticated to the client.