It all starts first with a handshake. The client tells the server what version of SSL it supports and what cipher suites. The server answers with the information on which version of SSL and which cipher suite will be used.
The client now has to check if the server really is who he sais he is. This is done with the certificate. The client verifies the name of the holder, the domain, public key, signature and the date when it will expire. The check of these information is done by asking the certificate authorities if it is valid or not.
3. Key exchange
Now that everything is almost set up, the client generates a random symmetric key that will be used for encrypting the data sent back and forth between the client and the server. (note: both ways are encrypted!) The client then encrypts this symmetric key with the asymmetric public key of the server and sends this information to the server. Only the server can read this data, because it only can be decrypted using its private key. So now both parties have the symmetric key that will be used to encrypt and decrypt the data of the communication.
The reason why there is a symmetric key is because of performance. Using only the asymmetric public key of the server would be much to slow and is even bound on limitation of the size of the data. And as you pointed out, the server otherwise couldn't send encrypted data back to the client.
I hope this gives you a brief understanding in how SSL works.