SSL works without Client certificate

Question

Hi

There is something I don't understand, When I don't put certificate at all, the SSL connection is established successfully, I wonder how the server decrypt the message without client certificate.

What is client side certificate is for?

Thanks

Answer 1

As I understand it (the 15000 metre view.)

The server has a public key it publishes in its cert. This is used by your browser to encrypt everything it sends. Only the server can decrypt the info as only it (hopefully) has the private key.

If you have a client cert then you give this to the server to ensure that it encrypts stuff to you so only you can decrypt it (again with your private key).

So to me: You can send your credit card info completely freely, knowing that only the server can read it. The client can either then send a proper cert or create a 'temp' one for the session and then the 'public' encryption key to the server secure in the knowledge that no one else will have sent it. Then the comms are encrypted both ways, but separately.

Now from here

A TLS client and server negotiate a stateful connection by using a handshaking procedure. During this handshake, the client and server agree on various parameters used to establish the connection's security. The handshake begins when a client connects to a TLS-enabled server requesting a secure connection, and presents a list of supported CipherSuites (ciphers and hash functions). From this list, the server picks the strongest cipher and hash function that it also supports and notifies the client of the decision. The server sends back its identification in the form of a digital certificate. The certificate usually contains the server name, the trusted certificate authority (CA), and the server's public encryption key. The client may contact the server that issued the certificate (the trusted CA as above) and confirm that the certificate is authentic before proceeding. In order to generate the session keys used for the secure connection, the client encrypts a random number (RN) with the server's public key (PbK), and sends the result to the server. Only the server should be able to decrypt it (with its private key (PvK)): this is the one fact that makes the keys hidden from third parties, since only the server and the client have access to this data. The client knows PbK and RN, and the server knows PvK and (after decryption of the client's message) RN. A third party may only know RN if PvK has been compromised. From the random number, both parties generate key material for encryption and decryption. This concludes the handshake and begins the secured connection, which is encrypted and decrypted with the key material until the connection closes.

This wikipedia article probably gives more info than you'll ever want.

Answer 2

Using a certificate from either the server or the client will give the endpoints a means of exchanging a shared secret (a symmetric encryption key - or seed).

A secondary purpose for the certificate (and one that's much less well-leveraged these days, relative to "encrypting the channel between endpoints") is to authenticate the endpoint supplying their digital certificate (using the cert and the proof of possession that they also send).

The overwhelming majority of SSL transactions these days are effectively only worried about the "encryption of the channel", not to authenticate the endpoint. (Practically speaking, it's a side benefit on the commercial internet, though the mass of man-in-the-middle attacks out there give us increasing incentive to try to figure out how to really know you're talking to the server - or client - that you think you are.)

In other words, the client certificate would be useful to authenticate (in a more or less "stronger" manner) that the server is interacting with either (a) a "more trusted" client (if all you were doing was ensuring that the cert is among a pool of certs you trust - e.g. mapped to an LDAP/AD directory of users you deem "trusted", or issued from a CA whose issuing practices you "trust") or (b) a specific user that you authenticate (e.g. again, through an LDAP/AD database of user, one - or more uncommonly, or more - of which has been mapped to that certificate through some automated or out-of-band - but either way, hopefully a sufficiently secure - process).

Answer 3

Hi

I also found this

Client certificates: http://support.microsoft.com/kb/895971

more practically: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/751c99bd-9657-41a5-b541-569d305872ef.mspx?mfr=true

Thanks

Answer 4

Think about certificate not in terms of encrypting-decrypting, but in terms of authentication. Encryption can be done without certificates at all - just knowing open key is enough. But certificate contains different fields, among them is personality of certificate owner. For web this value is the domain name of the server you wish to connect to. As there are means to check that IP address of the server is always equal to name stated in certificate (forward and backward DNS requests), you can be sure that you're talking to the one you wish to.

In this terms, client certificate issue should be much simpler to understand. Client certificate allows server to authenticate client, so the authentication will be mutual. Server could check, for example, that the client certificate is valid (not expired, not black-listed, etc.).