(Sorry I know this is a complete noob question and at the risk of posting a somewhat duplicate topic. I have a basic understanding of public/private key, hashing, digital signature... I have been searching online & stack forum last couple days but cannot seem to find a satisfactory answer.)

Example: 
I am surfing on open wifi and I browse to  for the 1st time. Server sends back its SSL certificate. My browser does its thing and verifies that the cert is signed by a CA that it trusts and all is well. I click around on the website. BUT!

Question:
Can someone actually please explain to me in a simple way how does my browser actually verify that the server certificate is legitimate? Yeah okay so on the certificate itself it says it is issued by, say "Verisign" but what is the actual cryptographic magic happens behind the scene to validate that it isn't a bogus certificate? I have heard people explain "SSL certificates are verified using the signing CA's public key" but that doesn't make sense to me. I thought public key is to encrypt data, not to decrypt data.

So confused... appreciate it if someone could enlighten me. Thanks in advance!

You are correct that SSL uses an asymmetric key pair.  One public and one private key is generated which also known as public key infrastructure (PKI).  The public key is what is distributed to the world, and is used to encrypt the data.  Only the private key can actually decrypt the data though. Here is an example:


  Say we both go to walmart.com and buy stuff.  Each of us get a copy of
  Walmart's public key to sign our transaction with.  Once the
  transaction is signed by Walmart's public key, only Walmart's private
  key can decrypt the transaction.  If I use my copy of Walmart's public
  key, it will not decrypt your transaction.  Walmart must keep
  their private key very private and secure, else anyone who gets it can
  decrypt transactions to Walmart.  This is why the DigiNotar breach was such a big deal


Now that you get the idea of the private and public key pairs, it's important to know who actually issues the cert and why certs are trusted.  I'm oversimplifying this, but there are specific root certificate authorities (CA) such as Verisign who sign certs, but also sign for intermediary CA's.  This follows what is called Chain of Trust, which is a chain of systems that trust each other.  See the image linked below to get a better idea (note the root CA is at the bottom).



Organizations often purchase either wildcard certs or get registered as a intermediate CA themselves who is authorized to sign for their domain alone.  This prevents Google from signing certs for Microsoft.

Because of this chain of trust, a certificate can be verified all the way to the root CA.  To show this, DigiCert (and many others) have tools to verify this trust.  DigiCert's tool is linked here.  I did a validation on gmail.com and when you scroll down it shows this:



This shows that the cert for gmail.com is issued by Google Internet Authority G2, who is in turn issued a cert from GeoTrust Global, who is in turn issued a cert from Equifax.

Now when you go to gmail.com, your browser doesn't just get a blob of a hash and goes on it's way.  No, it gets a whole host of details along with the cert:



These details are what your browser uses to help identify the validity of the cert.  For example, if the expiration date has passed, your browser will throw a cert error.  If all the basic details of the cert check out, it will verify all the way to the root CA, that the cert is valid.

Now that you have a better idea as to the cert details, this expanded image similar to the first one above will hopefully make more sense:



This is why your browser can verify one cert against the next, all the way to the root CA, which your browser inherently trusts.

Hope this helps you understand a bit better!
