SSL client modes
SSL client modes are:
- ClientAnon
- Client
- ClientAuth
ClientAnon
ClientAnon is the anonymous mode for clients. Clients use Ephemeral Diffie-Hellman, creating spontaneous public keys for encryption. The client is not authenticated, nor are private keys required. This is an appropriate choice for most secure web servers, which usually use anonymous SSL.
In Ephemeral Diffie-Hellman, the recipient randomly generates two numbers called the modulus and the generator, and transmits them to the sender. The sender uses those two numbers, along with the recipient’s public key, to generate a temporary key. This key is for encrypting messages to be sent to that recipient only. The recipient independently generates the same key to decrypt the messages. When the connection is closed, both parties delete their temporary keys.
Features:
- Provides only encryption using ephemeral Diffie-Hellman, which applies a spontaneously generated public key to each message.
- No non-repudiation or authentication.
- No required certificates: these are dynamically generated when the connection is established.
Client
Client is the standard mode for clients. Clients use the private key and certificate for authentication. The client can be authenticated if requested, but it performs no authentication of the server. Use this when connecting to a web server, for it to authenticate you by your certificate.
Certificate File, Private Key, and Password are enabled.
You must specify the complete path for the certificate file and private key file. You must also provide a password, which is used to encrypt and decrypt the private key file.
Neither certificate file names nor private key file names can include spaces. The file extension for the certificate file or the private key file must be .pem for PEM-encrypted files.
This is the non-repudiation mode and is the standard mode for clients. The client does not perform any authentication of the server at the other end of the connection, but may be authenticated by the server.
Features:
- Provides encryption and non-repudiation. This indicates no authentication.
- Requires a private key and certificate. You specify the location of these files in the security dialog box.
- The private key is used to encrypt the data.
- The certificate is sent to the other party during handshaking.
- The other party uses the certificate to decrypt any data you send. This provides non-repudiation. This indicates the encrypted data could only have been generated from this private key.
ClientAuth
This is the authentication mode for clients. Clients use a private key and certificate for encryption, and a Certificate Authority to authenticate the server. Use this to authenticate the web server’s certificate.
All text boxes are enabled.
You must specify the path for the CA file, CA file name, and complete path for the certificate file and private key file. You must also provide a password, which is used to encrypt and decrypt the private key file.
The CA file must reside on this computer system. This is the file that contains the CA for the other end of the connection whose path is required. If you are configuring SSL for a client, then you must provide directions to a local CA file for the corresponding server.
As you could have any number of connections, the CA files for various connections could be in various directories. CA Path should provide complete paths to all the directories to be searched for CA files. Each path is separated from the next by a semicolon.
Neither certificate file names nor private key file names can include spaces. The file extension for the certificate file or the private key file must be .pem for PEM-encrypted files.
Features:
- Messages are encrypted using a private key and certificate. The client obtains a certificate from the server at the other end and then validates that certificate using a CA file to authenticate the server. The client may also be authenticated by the server.
- Provides encryption, non-repudiation, and authentication.
- Requires a private key,
certificate, and a CA certificate.
The CA certificate should be obtained from a trusted third-party.
The private key is used to encrypt the data.
The certificate is signed by both yourself and the CA certificate.
The certificate is sent to the other party during handshaking.
The other party verifies that your certificate is signed by a trusted CA.
The other party uses your certificate to decrypt the data.
The other party trusts that you are who you say you are. This is because your certificate has been signed by the CA and you both trust the CA. Optionally, one of you can be a CA and agree that you trust each other.
- The CA file is the path to the CA certificate, which is used for authenticating the other party’s certificate.
- The CA Path is the directory where this and other CA files are located.