It's not at all clear to me what you don't understand, so I'll take it very slowly.
First some terminology. It's important to get this straight, because otherwise you can't know correctly what you're hearing and saying.
Key pair: a private key and a corresponding public key which are mathematically related and used for public-key cryptography (PKC) also called asymmetric cryptography. For RSA, which is usually the only PKC someone knows when they don't specify, the public key consists of a modulus N which is the product of two large primes, and a public exponent E which can be and usually is small (in fact it usually is either 3 or 65537); the private key contains at least N and a private exponent D such that E x D = 1 mod phi(N) or at least lambda(N); in practical use, the private key often contains additional values that enable faster computation, but there are quite a few other questions about that so I won't repeat them.
Digital signature: a value computed, for a specified chunk of data (almost always a hash of the "real" data) using a private key, such that the corresponding public key can be used to determine if the given signature is correct for the given data and could only have been generated by the given private key. This allows the verifier to determine that the data has not been altered or forged, and the data was sent or at least seen by the holder of the private key, but it doesn't say anything about who that holder is.
(X.509 aka PKIX) (Identity) Certificate: a data structure including a public key for an entity and the identity of that entity; plus some other information related to the entity and/or the CA; all signed by a (generally) different entity called a Certificate Authority or CA. I hope you meant Verisign only as an example; it is one CA but not the only one; you can get an equally good Internet certificate from others like GoDaddy, Comodo, StartCom LetsEncrypt, etc. If you trust a given CA to issue certs correctly, then you can trust the much larger number of public keys and identities in certs it issues. Update 2017: StartCom is no longer good, since it was bought by WoSign who was then caught breaking CABforum rules and now is widely distrusted. OTOH LetsEncrypt is now widely-trusted, and free. Which further emphasizes the importance of having multiple CAs! More Update: Now Verisign is bad also; although not publicized so widely in 2017, Symantec (who had acquired Verisign and several other brands, but continued mostly using the existing names) was caught misissuing and progressively distrusted which they resolved by selling the businesss to DigiCert (who fairly quickly replaced tainted Symantec certs with Digicert ones). But I've left the pseudo-Verisign names in my example below, matching the Q, since this is only an example and the logic is the same for any names.
User (end-entity) certificate: a certificate containing the key and identity for anything other than a CA, such as an SSL server, an SSL client, a mail system, etc.
(CA) Root certificate: a certificate containing the public key of a root CA. Since there is no CA "above" the root, a dummy signature using the CA's own private key is used, but that has no security value. You must decide (or delegate) whether to trust that key
"out of band", that is, based on reasons other than cryptographic computations.
Chain or intermediate certificate (and CA): (as your question indicates) most CAs now operate in a hierarchical fashion, where the root key is not used to directly issue user certificates. Instead the root CA and its root (private) key is used to sign certificates for several intermediate or subordinate CAs, each of which has their own keypair. Each intermediate CA can then issue user certs, or sometimes a second level of intermediate certs; this can be extended to several levels, but that's very rarely needed.
Since you mention a browser, you are apparently concerned (only?) with certificates (and keys) for HTTPS (HTTP over SSL/TLS). This is a common and important use of certificates and PKC, but not the only use.
Now, case 1. Since this case doesn't consider chain/intermediate, and Verisign does use that, I'll use a hypothetical SimpleCA instead. First, no CA ever has or sends you your private key. You generate your key pair and send your public key to the CA in a data structure called a Certificate Signing Request or CSR. The CSR also should contain your name; for an SSL server this is normally the domain name (FQDN) of the server. The CSR contains some other data you can ignore for now. The CA verifies your claimed identity (for SSL server, that you "control" the specified domain name), and usually collects a fee, and then creates a certificate which contains:
- your name (here SSL server FQDN) as the Subject and/or one or several name(s) as SubjectAlternativeNames especially in recent years
- your public key as SubjectPublicKey, and usually a hash of it as SubjectKeyID
- a ValidityPeriod specifying how long the certificate is valid, chosen by the CA based partly on how much you pay them
- the CA's name as the Issuer, and usually an AuthorityKeyID which also identifies the CA
- some other data you can ignore for now
and this whole structure is signed using the CA's private key (which means it can be verified using the CA's public key). The CA sends this certificate back to you to use in your server along with the private key you already have.
Previously, assuming SimpleCA showed it can be trusted to appropriately verify applicants and paid a fee, the browser vendors (Microsoft, Mozilla, Google, Apple, etc.) agreed to include its public key with their browsers, normally in the form of SimpleCA's root cert. Now when some browser connects to your server and you send your cert which says in effect "Aviel-server approved by SimpleCA", the browser finds SimpleCA's root cert and thus SimpleCA's public key and uses that to verify that your cert is signed correctly, and that the server name in your cert matches the server in the URL the user wants; if both those pass, it accepts the public key in your cert as the correct public key for you, and uses it to complete the SSL/TLS handshake. If not it displays some kind of warning or error.
Unless, that is, your cert was revoked. If your private key is compromised, or if the CA determines that you no longer control the claimed identity (including if they discover you never did but deceived them on the application), the CA publishes that your cert is revoked and therefore browsers don't trust it even though the signature still verifies (because the RSA computation is a fixed mathematical process independent of time or environment).
But revocation, and if and when and how well it works, is a whole complicated topic by itself, and this answer is large enough already.
(edit) How does OCSP stapling work? covers revocation (actually both OCSP and CRLs) with ursine thoroughness. If your certificate is expired (past the end of its validity period) it is also invalid; this one is easy for browser to check. Formally a certificate can also be invalid before the beginning of its validity period, but in practice CAs don't issue 'post-dated' certs unless someone messes up the timezone or something.
However, the set of CA root certificates supplied in a browser is usually only the default; the browser user can decide to add new roots or delete existing ones if they choose. And if so that may make your server trusted when it wasn't before, or untrusted when it was before.
Case 2 (chain). One reason for intermediate CAs and thus intermediate or chain certs is keeping the root key offline as you say. Another reason is to allow the intermediate CAs to be managed much like users: they can have limited validity periods and be renewed, and if compromised (or just no longer wanted) they can be revoked, and this happens automatically and nearly invisibly. On the other hand if you have to extend, replace, or revoke a root, basically every browser in the world must be updated. That's a lot of work, and is never done completely because users will refuse or forget to install an update and be left trusting a CA that isn't secure and thus probably servers that aren't legitimate.
Also for revocations that are published the older way using a Certificate Revocation List (CRL) dividing the issued certs over multiple intermediate CAs makes CRL management easier.
With a single intermediate/chain cert, the process is changed as follows. Let's say VerisignServerB is issued under VerisignRoot and is used in turn to issue Aviel-server. (The actual names are longer, but this is easier to see.) Then your server is configured to send both Aviel-server and VerisignServerB to the browser. The browser checks that the VerisignServerB cert is signed correctly under the VerisignRoot public key (as before, normally stored as a selfsigned root cert), AND that Aviel-server cert is signed correctly under VerisignServerB public key from that cert, and that Aviel-server cert name matches the desired one. It doesn't matter which order the signatures are checked as long as both are.
SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate?
has a nice graphical example of this which may help you.
For multiple intermediate/chain certs, when used, the extension should now be obvious.
