A server certificate that the client trusts is mandatory for setting up an SSL session. The client can generate a certificate on the fly, but the server must have a certificate with a chain of trust that terminates with a root certificate that is trusted by the client.
Simple TLS handshake (source)
A simple connection example follows,
illustrating a handshake where the
server (but not the client) is
authenticated by its certificate:
- Negotiation phase:
- A client sends a ClientHello message specifying the
highest TLS protocol version it
supports, a random number, a list of
suggested CipherSuites and suggested
compression methods. If the client is
attempting to perform a resumed
handshake, it may send a session ID.
- The server responds with a ServerHello
message, containing the chosen
protocol version, a random number,
CipherSuite and compression method
from the choices offered by the
client. To confirm or allow resumed
handshakes the server may send a
session ID. The chosen protocol
version should be the highest that
both the client and server support.
For example, if the client supports
TLS1.1 and the server supports TLS1.2,
TLS1.1 should be selected; SSL 3.0
should not be selected.
- The server
sends its Certificate message
(depending on the selected cipher
suite, this may be omitted by the
server).
- The server sends a
ServerHelloDone message, indicating it
is done with handshake negotiation.
- The client responds with a
ClientKeyExchange message, which may
contain a PreMasterSecret, public key,
or nothing. (Again, this depends on
the selected cipher.)
- The client and
server then use the random numbers and
PreMasterSecret to compute a common
secret, called the "master secret".
All other key data for this connection
is derived from this master secret
(and the client- and server-generated
random values), which is passed
through a carefully designed
"pseudorandom function".
- The client now sends a ChangeCipherSpec record, essentially
telling the server, "Everything I tell
you from now on will be authenticated
(and encrypted if encryption
parameters were present in the server
certificate)." The ChangeCipherSpec is
itself a record-level protocol with
content type of 20.
- Finally, the
client sends an authenticated and
encrypted Finished message, containing
a hash and MAC over the previous
handshake messages.
- The server will
attempt to decrypt the client's
Finished message and verify the hash
and MAC. If the decryption or
verification fails, the handshake is
considered to have failed and the
connection should be torn down.
- Finally, the server sends a ChangeCipherSpec, telling the client,
"Everything I tell you from now on
will be authenticated (and encrypted,
if encryption was negotiated)."
- The server sends its authenticated and
encrypted Finished message.
- The client
performs the same decryption and
verification.
- Application phase: at this point, the "handshake" is complete and the
application protocol is enabled, with
content type of 23. Application
messages exchanged between client and
server will also be authenticated and
optionally encrypted exactly like in
their Finished message. Otherwise, the
content type will return 25 and the
client will not authenticate.
If you turn off SSL (https), then communicaton between the client and the server will not be encrypted, but your site should function normally.
I say should because there could be hardcoded absolute https urls that are suddenly broken. Also, if the client certificate is used for authentication purposes, then you may not be able to login to the site - this is unlikely because most websites use a username and password mechanism.
