Question

I am sure this is embedded in the details of the SSL certificate/HTTPS specs but I am not entirely grokking this subject.

If a modern browser connects to a HTTPS site, the body of the HTTP request is encrypted. Is the SSL certificate essentially the “public” key used to communicate back and forth between the client and server?

Couldn’t a hacker get the public key from the public site, say “https://www.google.com” and monitor client/server traffic and decrypt the data?

Also, do clients need to verify the “issuer” of a certificate. For example, self sign certificates clients don’t need to verify but for certificates provided from a trusted issuer, what happens during the certificate verification process?

Answer 1

The server’s certificate contains a public key which in fact is visible to everybody. This key in turn is used during the handshake between the server and client in order to create a unique session key that will be used to encrypt any further messages:

http://en.wikipedia.org/wiki/Secure_Sockets_Layer#TLS_handshake_in_detail

Couldn’t a hacker get the public key from the public site, say
“https://www.google.com” and monitor client/server traffic and decrypt
the data?

The hacker won’t know the session key. He will be listening to (senseless) encrypted stuff.

Also, do clients need to verify the “issuer” of a certificate. For
example, self sign certificates clients don’t need to verify but for
certificates provided from a trusted issuer, what happens during the
certificate verification process?

Like you said, the issuer of the certificate is verified against a pre-defined list of trusted authorities. Any certificate up in the chain will be verified too, including the trusted issuer, expiration dates. Additionally each certificate contains URLs that point to Certificate Revocation Lists (CRL Distribution Points), the client will attempt to download the list from such URL and ensure the certificate at hand has not been revoked.