You cannot "encrypt" with a private key.
Encryption provides confidentiality of the encrypted message.
If the public key performs decryption, and the public key is public, then anyone can decrypt the message. So "encrypt with the private key" is not possible.
This notion may be popular, but it is incorrect.
It stems from the fact that signing a message with textbook RSA is equivalent to public key encryption done in reverse. However, there are many problems with this:
- Textbook RSA does not provide a secure signature/encryption scheme, and is not used
- Padding and hashing ensure that the signature process is in fact not the same as the encryption process done in reverse.
- Few, if any, other algorithms even operate in a similar manner. E.g. there exist signature schemes that you cannot encrypt with, and therefore signatures being "encrypting with the private key" is not even a vaguely correct analogy.
So your questions can be translated to something more accurate:
When establishing a connection in the SSL protocol, does the protocol always require that the message is first signed using side A's private key (so side B knows that only A could have signed it) and then is encrypted with B's public key so that only B could decrypt it?
When establishing a connection, it is assumed that A's public key is already signed by a certificate authority (that has vetted A's identity). First the certificate and public key are presented to B. B has the public verification key of the certificate authority pre-installed, and can use it to verify the signature on the certificate and public key. There is a nice outline of the process on our information security sister site.
In what case would side A encrypt the message only with B's public key and then just send it?
Situations where the message is not signed include:
- Broken protocols vulnerable to man-in-the-middle attacks
- When A and B already share public keys with each other
- The initial key exchange could use signatures, but the actual messages sent back and forth may only use MACs rather than signatures.
- When A desires deniability about having sent the message to B