I'm going to claim that the answer is the third one.
You could certainly argue that there is a better case for the first one,
but that would be pretty disappointing.
The reason that we trust this key is not because it's signed by VeriSign.
In fact, it actually is signed by VeriSign.
When we look at that certificate, we see that it is signed.
It was issued by VeriSign, and it does have a certificate signature.
We could verify it against this public key,
but that would be verifying it against the same key that the certificate describes.
That's what called a self-signed certificate.
This doesn't convince you of anything. Anyone could generate it like that.
In fact, you can do that. You can generate one yourself.
If you're using a Mac, you have open SSL built-in
and use that to generate a self-signed certificate.
But it doesn't prove anything.
The best answer here is that we trust it because we got it from some trusted source,
and we protected it and we know that it's valid.
How that works in a web browser is there is a set of certificates that are built in.
You can download more, but you have to be careful.
If you download them, you need to know that they're secure.
If you look at your browser settings, you can see all the certificates that are built in.
There are actually quite a lot of them.
Not all of these were always built in, so all the ones that are listed as built in were built in.
They came with the browser, and we can see that there is one for VeriSign--
actually several for VeriSign--that were built in.
These are trusted only because we think we got the browser from a trusted source,
and it had these certificates built in.
We can look at one of these certificates.
You'll notice that their rated as different classes.
What it means is mostly that someone was willing to pay more to VeriSign to get a higher certificate.
If you pay more, they do a little more identity checking
to say that you're probably the one who's asking for the certificate.
But all the certificate proves is that VeriSign granted it to you
and decided that the person that they granted a certificate that said "I'm google.com"
probably had some affiliation with Google.
The higher the class the more you have to pay and the more work VeriSign does to validate that.
If we look at one of these certificates, we can see the root certificate that's built in.
This is the root of trust. We're trusting this, because it came in the browser.
You'll notice that these have quite long expiration dates.
Since these are used to sign all these other certificates,
if they expire, all the certificates they sign would break.
That raises the question of what happens when there's a bad certificate.
There have been several well-publicized incidents
where VeriSign or other certificate authorities
accidentally granted a certificate to someone who wasn't actually representing the company
that they asked for a certificate from.
Revocation lists are one way to deal with that.
You can have a list of--well, these are signed certificates that aren't actually valid.
If those are kept up to date, and the browser always checks them,
then you could have a certificate be revoked even though it was signed.
This is a pretty painful solution to this problem, though.
It requires always updating this list.
It means that the time between updates you're vulnerable if there is a bad certificate
and requires a lot of extra work for the browser to validate a certificate.
The best solution, of course, would be never to grant a certificate without validating that identity.
