How are messages from server secured when using SSL certificate In case of using SSL the certificate server has a primary key and a public key that is published to all clients - as far as I understood. So in this case when message is encrypted by public key (on client side) only the owner of private key (which is the server in this case) has ability to decrypt it.

But I do not understand how this works the other way, I mean when the message is encrypted by private key then does it mean that whoever has the public key can decrypt it? That would mean that only the messages toward the server are secured and messages which come from the server can be read by anybody with public the key.

Update:
in my case I have web server in DMZ hosts multiple web services (WCF), the clients are non-server application (they are standalone .NET application) reaching these web services via internet using https protocol.

My server has SSL certificate issued by Versign, the point is that my client do not have any type of credential and any machine with that application (or similar app) should be able to consume the services, the point is that the information passing between client machine and server must be encrypted and signed, so this is my question is having the certificate and using the transport security enough to make sure that nobody can read the messages passing between client and server or do I have to somehow come up with some kind of ad hoc client credential and add message security.
This link describes that SSL is good for Intranet and for internet message security is suggested why? what does happen if I only use SSL and no message security for the internet scenario?
You are missing the entire TLS protocol. The TLS protocol first establishes session keys. These can be randomly created at the client and send encrypted to the server. After that the session keys can be used to protect the data for confidentiality, integrity and authenticity. Encryption and authentication is performed in both directions.

The TLS protocol is however gravitating towards authenticated ephemeral Diffie-Hellman, which is a key agreement protocol. Ephemeral DH provides forward security, meaning that the session keys (and thus the data) stay secret even if the private key gets factored afterwards. In that case the private key is only used for signature generation to perform authentication.