Client Authentication
Setting Ciphers
SSL for multiple IP virtual Hosts
Client Authentication:
If you enable client authentication, the server validates clients by checking for trusted certificate authority, Known as CA root certificates in the local key database. To enable client authentication, you need to use SSLClientAuth directive. The options to use with this stanza are:
None – The server requests no client certificate from the client.
Optional – The server requests, but does not require, a client certificate. If presented, the client certificate must prove valid.
Required – The server requires a valid certificate from all clients and returns a 403 status code if no certificate is present.
Required_reset – The server requires a valid certificate from all clients, and if no certificate is available, the server sends an SSL alert to the client. This enables the client to understand that the SSL failure is client-certificate related, and will cause browsers to re-prompt for client certificate information on subsequent access. make sure you have GSKit version 7.0.4.19 or later when you choose this option.
For example, If i want all the clients to be authenticated, then i need to add the following stanza
SSLClientAuth required
Ciphers
We set the cipher specification to use during secure transactions. The specified cipher specifications validate against the level of the Global Security Kit (GSK) toolkit that is installed on your system. Invalid cipher specifications cause an error to log in the error log. If the client issuing the request does not support the ciphers specified, the request fails and the connection closes to the client. IBM HTTP Server has a built-in list of cipher specifications to use for communicating with clients over Secure Sockets Layer (SSL). The actual cipher specification that is used for a particular client connection is selected from those which are supported by both IBM HTTP Server and the client.
Some cipher specifications provide a weaker level of security than others, and might need to be avoided for security reasons. Some of the stronger cipher specifications are more computationally intensive than weaker cipher specifications and might be avoided if required for performance reasons. When an SSL connection is established, the client (web browser) and the web server negotiate the cipher to use for the connection. The web server has an ordered list of ciphers, and the first cipher in that list which is supported by the client will be selected.
IBM HTTP Server supports the following SSL ciphers: SSLv3 and TLS and SSLv2
IBM recommends the following setting, keeping in mind both strong security and performance
## SSLv3 128 bit Ciphers
SSLCipherSpec SSL_RSA_WITH_RC4_128_MD5
SSLCipherSpec SSL_RSA_WITH_RC4_128_SHA
## FIPS approved SSLV3 and TLSv1 128 bit AES Cipher
SSLCipherSpec TLS_RSA_WITH_AES_128_CBC_SHA
## FIPS approved SSLV3 and TLSv1 256 bit AES Cipher
SSLCipherSpec TLS_RSA_WITH_AES_256_CBC_SHA
## Triple DES 168 bit Ciphers
## These can still be used, but only if the client does
## not support any of the ciphers listed above.
SSLCipherSpec SSL_RSA_WITH_3DES_EDE_CBC_SHA
## The following block enables SSLv2. Excluding it in the presence of
## the SSLv3 configuration above disables SSLv2 support.
## Uncomment to enable SSLv2 (with 128 bit Ciphers)
#SSLCipherSpec SSL_RC4_128_WITH_MD5
#SSLCipherSpec SSL_RC4_128_WITH_SHA
#SSLCipherSpec SSL_DES_192_EDE3_CBC_WITH_MD5
View the Ciphers which the server uses for Secure transactions
Set the LogLevel to info in the configuration file. Look in the error log for messages in this format: TimeStamp info_message mod_ibm_ssl: Using Version 2/3 Cipher: longname|shortname. The order that the cipher specifications are displayed in the error log from top to bottom represents the attempted order of the cipher specifications.
View the Ciphers were used for negotiating a connection
You can use the following LogFormat directive to view and log the SSL cipher negotiated for each connection:
LogFormat “%h %l %u %t \”%r\” %>s %b \”SSL=%{HTTPS}e\” \”%{HTTPS_CIPHER}e\” \”%{HTTPS_KEYSIZE}e\” \”%{HTTPS_SECRETKEYSIZE}e\”" ssl_common
CustomLog logs/ssl_cipher.log ssl_common
This logformat will produce an output to the ssl_cipher.log that looks something like this:
127.0.0.1 – - [01/Sep/2010:00:02:05 -0800] “GET / HTTP/1.1″ 200 1582 “SSL=ON” “SSL_RSA_WITH_RC4_128_MD5″ “128″ “128″
SSL for multiple IP virtual hosts
When you do not define an SSL directive on a virtual host, the server uses the directive default. You can define different (SSL) options for various virtual hosts. To enable SSL:
Specify the SSLEnable directive on the virtual host stanza in the configuration file, to enable SSL for a virtual host.
Specify a Keyfile directive and
Any SSL directives you want enabled for that particular virtual host.
Restart the server.
With all the above security options enabled, your virtual host may look like this:
SSLEnable
Keyfile keyfile.kdb
SSLCientAuth required
## SSLv3 128 bit Ciphers
SSLCipherSpec SSL_RSA_WITH_RC4_128_MD5
SSLCipherSpec SSL_RSA_WITH_RC4_128_SHA
## FIPS approved SSLV3 and TLSv1 128 bit AES Cipher
SSLCipherSpec TLS_RSA_WITH_AES_128_CBC_SHA
## FIPS approved SSLV3 and TLSv1 256 bit AES Cipher
SSLCipherSpec TLS_RSA_WITH_AES_256_CBC_SHA
## Triple DES 168 bit Ciphers
## These can still be used, but only if the client does not support any of the ciphers listed above.
SSLCipherSpec SSL_RSA_WITH_3DES_EDE_CBC_SHA
## The following block enables SSLv2.
## Excluding it in the presence of the SSLv3 configuration above disables SSLv2 support.
## Uncomment to enable SSLv2 (with 128 bit Ciphers)
#SSLCipherSpec SSL_RC4_128_WITH_MD5
#SSLCipherSpec SSL_RC4_128_WITH_SHA
#SSLCipherSpec SSL_DES_192_EDE3_CBC_WITH_MD5
Courtesy:http://josephamrithraj.wordpress.com/2010/09/04/advanced-ssl-configuration-on-ibm-http-server-client-authentication-and-ciphers/