SSL certificate chain verification
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); 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!
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.
How will the browser with Verisign public key is going to identify that my public key is indeed a valid Verisign key that can be used for encrypting messages that my Verisign private key can decrypt?
It only needs to verify Verisign's signature. Verisign's signature on your certificate is proof that the ceritificate really came from Verisign and wasn't fabricated on your computer for example. The signature is simply a message that is signed with their private key. Since what the private key encrypts only the associated public key decrypts (it works in both ways), then the browser can decrypt that signature with their public key (since it's public anyone can get a copy of it, and it is included in your certificate, so the browser gets it from there). If it can decrypt that message, that means that it was encrypted with their private key, which in turn means that it originated from them.
Now, what should the browser match that decrypted message against ? Signatures are simply a hash of the whole certificate. So what it needs to do is calculate the hash itself (for exemple it gets 123XYZ) and compares it to the decrypted signature. If it gets 123XYZ too, that means two things :
- that verisign is verily the author of that certificate (otherwise the decrypted message wouldn't match the computed hash)
- that the certificate hasn't been modified (otherwise the hashes would differ)
I assume its the Verisign public key digital signature that is tested against the server public key digital signature?,
No, it is tested against the certificate hash. See previous.
In case its indeed the digital signature that is tested I assume there is a relationship between all of Verisign public keys?
Verisign has a single, unique public key and private key. The question doesn't make sense.
Or maybe there is only relationship between each public key Verisign assign to a specific client(website/device/etc) and the public key the browser/operating system including.
Just to be more precise : they may create public keys for you but you can also hand them your public key if you already have one and they will sign it.
The relationship there is between the certificate they sign for you and the certificate there is in the browser is : the certificate that is in the browser is the root certificate, the one that browsers trust by default. The certificate that verisign delivered to the client isn't trusted by default on all browsers, so a browser needs to check who issued that certificate. If the issuer is trusted then the browser trusts your certificate and proceeds with giving you access to the website you requested. If not, it will check the issuer's issuer, if any, and see if it's trusted. It will continue to check for the issuer's ancestors until it reaches a root certificate authority that is trusted, or untrust the certificate if it can't find any.
So in your case it will see that Verisign is the issuer (with an intermediate certificate) and Verisign's issuer is Verisign itself (but with another ceriticate called a root certificate), and since the root certificate of Verisign is installed on every browser it is thus trusted, which in turn leads to trust your certificate.
I understand that the need for them is security, so the root CA private key can stay offline, if there are more reasons i'll love to hear about them.
Security is a good reason, yes.
About the chain verification, I assume the server public key digital signature is tested against the server intermediate certificate digital signature, if its valid now it is the turn for the intermediate certificate digital signature to be tested against the browser/operating system pre-installed public key digital signature, and if this is also valid, the client has successfully validate both the intermediate certificate and the public key of the server.
See previous
While I was learning how SSL works I made this diagram. It could be helpful.