A public key certificate is the signed combination between a public key, identifiers, and possibly other attributes. Those who sign this document effectively assert the authenticity of the binding between the public key and the identifier and these attributes, in the same way as a passport issuing authority asserts the binding between the picture and the name in a passport, as various other pieces of information (nationality, date of birth, ...).
First, a couple of clarifications on the terminology:
Strictly speaking, there is no such thing as an "SSL certificate". Most of the time, this is a short expression for "X.509 certificate used for SSL/TLS". (SSL/TLS is also capable of using other types of certificates such as OpenPGP certificates, although this is less common.)
Your usage of "encryption" and "decryption" is incorrect here. In public key cryptography:
- The private key is used for signing and deciphering/decrypting.
- The public key is used for verifying signatures and enciphering/encrypting.
See the glossary of the TLS specification:
public key cryptography: A class of cryptographic techniques employing two-key ciphers. Messages encrypted with the public key can
only be decrypted with the associated private key. Conversely,
messages signed with the private key can be verified with the public
key.
It may not seem that this distinction in terminology matters, because these operations are roughly the same as far as RSA is concerned (in fact you'll find underlying routines called RSA_private_encrypt in OpenSSL), but (a) this wouldn't work for DSA and (b) not understanding this fundamental difference can lead you to make mistakes as far as your overall security scheme is concerned.
In particular, the purpose of encryption is to hide something. When you talk about "encrypting with a private key" here, it doesn't make any sense since the public key is known to anyone. In addition, the issuer's public key isn't required to look inside a certificate this issuer has signed, because everything (see TBSCertificate structure) is there in clear for anyone to see anyway. Nothing is hidden here.
(What is done for signing with RSA is indeed more or less the same operation as encrypting, but with the private key, applied to a cryptographic digest of the message to sign, typically done using SHA-1 for certificates nowadays.)
What you server certificate intends to prove is that the CA has somehow verified the binding between your host name and your certificate request (more specifically, the public key in your certificate request). At the very least, it would have e-mail the domain name owner (for Domain Validated certificates). (See distinctions between validation modes here.)
The content of the certificate issued should be compliant with RFC 3280/RFC 5280, which define how clients should verify and validate the certificate. This will define which attributes can be used, in particular (extended) key usage attributes usually, e.g. "TLS server".
As a result, your X.509 server certificate will bind together:
- A public key (for which you have the private key).
- An issuer name (the CA certificate Subject DN).
- A server name (in accordance with RFC 2818 Section 3.1 or RFC 6125), in the Subject Alternative Name extension or in the Common Name of the Subject Distinguished Name.
- Usage extensions.
- Possibly other extensions (critical or not), e.g. EV certificate policies.
This is all placed in the TBSCertificate structure of the X.509 certificate. Then, this
structure is digested using a cryptographic hash algorithm (e.g. SHA-1) and signed using the CA's private key to form the signature (signatureValue in the resulting Certificate).
When the certificate is used, the client can verify this signature (using the CA's public key it knows, or by building a certification path using multiple CA certificates to one of the trust anchors it knows), check that the usage attributes are compatible with SSL/TLS usage and check that the host name it requested matches the one for which it was issued.
<nitpicking>"she ensures that only Bob can decrypt it" is not quite right. I would phrase it as "she ensures that only a process with access to Bob's key can decrypt it." Knowledge of a private key is often a good proxy for identity but it is not the same. Access can be gained by delegation, theft, or brute-forcing and it is almost always a computer that is using the key, rarely a person. Conflating identity and knowledge can cause you to overlook attack vectors.