Wednesday, March 16, 2011

Installing the Certificates to the Keystore
  1. Download your certificate files from your certificate authority and save them to the same directory as the keystore that you created during the CSR creation process. The certificate will only work with the same keystore that you initially created the CSR with. The certificates must be installed to your keystore in the correct order.
  2. Install the Root Certificate file: Every time you install a certificate to the keystore you must enter the keystore password that you chose when you generated it. Enter the following command to install the Root certificate file:
keytool -import -trustcacerts -alias root -file RootCertFileName.crt -keystore keystore.key
If you receive a message that says "Certificate already exists in system-wide CA keystore under alias <...> Do you still want to add it to your own keystore? [no]:", select Yes. If successful, you will see "Certificate was added to keystore".
3.      Install the Intermediate Certificate file: If your certificate authority provided an intermediate certificate file, you will need to install it here by typing the following command:
keytool -import -trustcacerts -alias intermediate -file IntermediateCertFileName.crt -keystore keystore.key
If successful, you will see "Certificate was added to keystore".
4.      Install the Primary Certificate file: Type the following command to install the Primary certificate file (for your domain name):
keytool -import -trustcacerts -alias tomcat -file PrimaryCertFileName.crt -keystore keystore.key
If successful, you will see "Certificate reply was installed in keystore". You now have all the certificates installed to the keystore file. You just need to configure your server to use the keystore file.
Configuring your SSL Connector
Tomcat requires an SSL Connector to be configured before it can accept secure connections.
By default Tomcat looks for your Keystore with the file name .keystore in the home directory with the default password "changeit". The home directory is generally /home/user_name/ on Unix and Linux systems, and C:\Documents and Settings\user_name\ on Microsoft Windows systems. You will be able to change the password and file location.

1. Copy your keystore file (your_domain.key) to the home directory.
2. Open the file ${CATALINA_HOME}/conf/server.xml in a text editor.
3. Uncomment the SSL Connector Configuration.
4. Make sure that the
Connector Port is 443.
5. Make sure the keystorePass matches the password for the keystore and the keystoreFile contains the path and filename of the keystore.
When you are done your connector should look something like this:
 <Connector className="org.apache.catalina.connector.http.HttpConnector" port="8443" minProcessors="5" maxProcessors="75" enableLookups="true" acceptCount="10" debug="0" scheme="https" secure="true">
<Factory className="org.apache.catalina.net.SSLServerSocketFactory" clientAuth="false" protocol="TLS" keystoreFile="/working/mykeystore" keystorePass="password"/>
6. Save the changes to server.xml
7. Restart Tomcat

This is a new series on the blog which gives you tips and important commands you can use at your work to simplify your administration and BAU tasks. All these commands provided in this series of posts will work on Linux/Unix machines.
In the first post, we have 2 tips for you.
1. Finding a Zombie process:
Sometimes when you issue TOP command you see some process under Zombie state apart from the running/sleeping/waiting process. What is a Zombie process? a zombie process or defunct process is a process that has completed execution but still has an entry in the process table. This entry is still needed to allow the process that started the (now zombie) process to read its exit status.
ps -el | grep ‘Z’
Process states and explanation
  • S : sleeping
  • R : running
  • D : waiting (over het algemeen voor IO)
  • T : gestopt (suspended) of getrasseerd
  • Z : zombie (defunct)

2. Sorting the files in a directory by their size
The following command list the size of all sub folders and files from the current location, with sorting
du -a –max-depth=1 | sort –n | more
If you want bigger sized files to appear first, then
du -a –max-depth=1 | sort –nr | more

The setup is as follows:
The request flows in the following order: Web Browser –> IBM Http Server –> WebSphere Plug-in –> WebSphere Application Server.
This involves setting SSL for two different communications.
  • 1. Between Browser and IBM http server [IHS]
  • 2. Between IBM http server [IHS] and Websphere Application Server
In this part, let us take the, SSL setup for IHS. [between browser and IHS]. This involves, editing httpd.conf file and creating a new SSL certificate.
Creating new SSL digital Certificate using iKeyman:
For the certificate you can use either a certificate that is signed by a certificate authority or you can also use a self-signed certificate.  Before creating a new certificate, you need to create a certificate store or Key Database.
  • start the iKeyman utility: /IHS root/bin/ikeyman.sh
  • From the Menu Bar select Key Database File > New.
  • Choose the key database type as CMS
  • Enter a file name for the new Key Database file you are creating
  • Enter a Location for the location where you want to store the .kdb file
  • Click OK
  • After saving the key database file to the location specified, you are prompted to enter a password. This is the password that will be used to open the key database file in iKeyman in the future.
  • make sure checkbox Stash the password to a file is enabled. this saves the encrypted password file as a .sth file in the same directory as the key database file.
  • Now Click OK
Your Key Database file is Ready.
Now lets create a certificate request. Iam using this URL for my site http://www.josephamrithraj.mp/
  • First, Open the KDB using ikeyman. This will show the key database contents.
  • Click on the "down arrow" to the right, to display a list of three choices.
Select Personal Certificate Requests and click New.
Now, a new window will pop up. here you need to input details about the certificate and your organization.
 
Options:
  • Key Size= 1024 for 128bit and 512 for 56bit
  • Common Name= SiteName, [This is the name that the CA will register]
  • Organization= Company Name
  • Enter the name of a file in which to store the certificate request = This is the file (.arm) that will contain your request
Once you save the file (.arm) you are done with creating the request
You must now choose a CA and send them a the "Certificate Request"
Once the CA has signed your certificate, generally they send you back the signed certificate through email.
  • Take the information provided in the CAs email and copy it to a text file (notepad) and save it as IHS_Root/SSL/CertRcvd.arm
  • Open the KDB file and choose Personal Certificates from the drop down options [ check image3 for how-to]
  • From the Personal Certificates section, click Receive, a pop-up window will come
Input the required data. Like  certificate name and location and click OK
Preparing IHS for SSL:
Open the httpd.conf file for editing and modify it to implement the follwoing:
  • For the host_name.domain, use the virtual host IP address or fully qualified domain name.
  • Typically, port 443 is used for HTTPS protocol.
  • The timeout values are given in seconds. Your values might be different.
Sample httpd.conf file for a UNIX computer:
    LoadModule ibm_ssl_module libexec/mod_ibm_ssl.so
    AddModule mod_ibm_ssl.c
    Listen 443

    <VirtualHost host_name.domain:443>
    ServerName host_name.domain
    SSLServerCert certificate name
    DocumentRoot "IHS_Root\docs"
    SSLEnable
    SSLClientAuth none
    <\VirtualHost>

    SSLDisable
    Keyfile "path_to_keyfile_created"
    SSLV2Timeout 100
    SSLV3Timeout 1000

Restart IBM HTTP Server for the changes take effect.
Example SSL virtualhost stanza:
<VirtualHost xxx.xxx.xx.xx:443>
ServerName www.josephamrithraj.mp
SSLEnable
SSLClientAuth None
SSLServerCert mywebsite
<Directory "/home/joseph/website">
Options Indexes
AllowOverride None
order allow,deny
allow from all
</Directory>
DocumentRoot "/home/joseph/website"
</VirtualHost>

in the next part. let us see how to secure the communication between IHS and Websphere
IBM Http Server – Client Authentication and Ciphers
In the previous post, we discussed how to setup SSL between browser and IBM http server [IHS]. In this article, lets discuss how can we set up advanced security for the setup we already did.
The Advanced SSL Configuration settings are
  • 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:
<VirtualHost *:443>
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
</VirtualHost
Creating a Dedicated Profile for LiveCycle in WebSphere ND
The 64-bit version of WebSphere Application Server 6.1 ND does not come with a “Profile Management Tool” (PMT). IBM expects people to use the manageprofiles (.bat or .sh) script in the /bin folder of the WebSphere installation (C:\WebSphere\AppServer\bin\ for example). It is a good idea to create a dedicated WebSphere profile for LiveCycle instead of default ones named AppSrv01, AppSrv02 etc.
Here is a sample command (SUSE Linux Enterprise Server 10 example) to create a WebSphere profile called “LiveCycle”:./manageprofiles.sh -create -profileName LiveCycle -profilePath /opt/WebSphere/AppServer/profiles/LiveCycle -templatePath /opt/WebSphere/AppServer/profileTemplates/managed
If the command succeeds, the response would be something like this:
INSTCONFSUCCESS: Success: Profile LiveCycle now exists. Please consult /opt/WebSphere/AppServer/profiles/LiveCycle/logs/AboutThisProfile.txt for more information about this profile.
If you navigate to /opt/WebSphere/AppServer/profiles/, you will see that there now is a folder called LiveCycle there containing the new profile.
Change folder to the /bin folder of the new LiveCycle profile and federate the node to your cell. Make sure that the Deployment Manager process that manages the WebSphere cell is running. Run a command that looks like this (SUSE Linux Enterprise Server 10 example):./addNode.sh DMgr.company.com DMgr_SOAP_ADDRESS
where DMgr.company.com is the DNS name of the server running the Deployment Manager process that manages the WebSphere cell.
If successful, you will get a response such as this:
Node ServerDNSNameNode01 has been successfully federated.
Here ServerDNSName is the DNS name of the node you just federated without its DNS suffix. This will also start the Node Agent for the node.
This new node (ServerDNSNameNode01 ) will now be visible in the WebSphere Admin Console. You are now ready to create the server and/or clusters to deploy LiveCycle. Please note that the LiveCycle Configuration Manager (LCM) only configures servers and/or clusters. It does not create them for you.
Here is a sample command (SUSE Linux Enterprise Server 10 example) to delete an existing WebSphere profile called “LiveCycle”:./manageprofiles.sh -delete -profileName LiveCycle
If successful, you will get a response such as this:
INSTCONFSUCCESS: Success: The profile no longer exists

           

Installing Verisign SSL certificate on IBM HTTP server

Installing Verisign SSL certificate on IBM HTTP server
Posted on by Dave
Installing a Verisign SSL site certificate on IBM HTTP server
If you have an Apache certificate e.g. it was requested with an openssl signing request rather than using ikeyman then you first need to convert it to PKCS12 format which can then be imported into the IBMHTTPServer6 keystore.
openssl pkcs12 -export -out new_key_pair_filename.p12 -inkey private_key_filename.key -in certificate_filename.crt
You will get prompted for a password – you must use the same password as you have on the keystore you want to import it into.
Move the file to /usr/IBMHTTPServer6/bin
If you used strong encryption to generate the signing key request ( and you would have done ) then you may have to install the unrestricted JCE policy files.
To check :-
/usr/IBMHTTPServer6/java/jre/bin/keytool -list -v -keystore /usr/IBMHTTPServer6/bin/wbis104m.p12 -storetype pkcs12 -storepass passwd
If it barfs with java errors like :-
keytool error (likely untranslated): java.io.IOException: Private key decryption error: (java.security.InvalidKeyException: Illegal key size)
keytool error (likely untranslated): java.io.IOException: Private key decryption error: (java.lang.SecurityException: Unsupported keysize or algorithm parameter
s)
You need to install the unrestricted JCE policy files.
Download the zip file from https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?source=jcesdk ( you need an IBM ID – this is a free registration )
unzip and after making copies of the orginals copy over the new local_policy.jar US_export_policy.jar files to /usr/IBMHTTPServer6/java/jre/lib/security
Rerun the keytool command above ( ensuring you use the full path to the keytool command ) to confirm it lists the certificate details without Java errors.
Now add it into the keystore
You need to be able to use X as the ikeyman program is GUI only.
su to root , export XAUTHORITY and DISPLAY to those of the user you su’d from.
e.g.
export XAUTHORITY=/home/fred/.Xauthority
export DISPLAY=localhost:10.0
cd /usr/IBMHTTPServer6/bin
./ikeyman
Key Database File – Open
Key Database type CMS
Location /usr/IBMHTTPServer6/keys/
File Name key.kdb
You will be prompted for the password
Now import the certificate you converted to pkcs12 format above
Ensure Personal Certificates is selected then click on Export/Import
Select Import Key
Key file type PKCS12
File Name the file name of the converted pkcs12 format above
Location where you put the file
Click OK – you will be prompted for a password – use the one you set when you did the conversion ( which should also be the same as the keystore password you are putting it in )
If you get a message “The specified database has been corrupted” ensure you have installed the unrestricted JCE policy files above. If you have to install them you need to exit ikeyman and restart it again.
You should now get a dialog asking if you would like to change any of these labels before completeing the import process
Click on the label ( which is probably a very long string ) and then change it to something like prod-cert ( this is the name you will use in the httpd.conf file )
Click apply
Click OK ( you may have to scroll to the right to see the OK button )
If you now get an error An attempt to import the certificate has failed.
All the signer certificates must exist in the key database
This probably means that you need to install the Verisign intermediate signers certificate.
Assuming it is a standard Verisign site certifiacate ( class 3 ) then go here :-
Cut and paste the certificate into a file and save with a .arm extension
Go into ikeyman and open the keystore as above
Select Signer Certificates
Click add
Data type Base64-encoded ASCII data
Certificate file name the name of the arm file you created above
Location the location of the arm file
Click OK
Enter a label for the certificate – choose something like Verisign intermediate CA cert
Click OK
Now select Personal Certificates and import the converted PKCS12 SSL certificate using the intructions as before.
Adding the certificate to the httpd.conf file
vi /usr/IBMHTTPServer6/conf/httpd.conf
search for SSLServerCert and change the name of the certificate to the name you chose when you added the certificate to the key store e.g. prod-cert
Restart apache

BEA Weblogic Server SSL Installation Instructions

BEA Weblogic Server SSL Installation Instructions
Create The PEM File
The easiest way to import a chained certificate (one with an intermediate certificate) into Weblogic is to included all the certificates in a text file with a .pem extension and import it. Once you have downloaded your certificate from your certificate authority, open all the files in a text editor. Copy and paste any intermediate and root certificates right below your primary certificate in the following order: Primary Certificate > Intermediate Certificate > Root Certificate. Save the file with a .pem extension (i.e myCertificate.pem) The file should look like this when finished:
-----BEGIN CERTIFICATE-----
(Primary SSL certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Intermediate certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root certificate)
-----END CERTIFICATE-----

Import and Install the Certificate
  1. Using the java keytool command line utility, import the pem file you created above using the following command: keytool -import -alias tomcat -keystore /path_to_keystore/mykeystore -file myCertificate.pem The command should be typed on one line. This command imports the certificate into the keystore named mykeystore in the working directory. Your keystore path and name may be different.
  2. Noe open the WebLogic Server Console and drill down to Security > Keystores > DefaultKeyStore and fill in the paths, file name, and various passwords for your private key, root CA certificate, and keystore locations.
  3. Restart the WebLogic server
http://www.sslshopper.com/ibm-http-server-ssl-installation-instructions.html

apache ssl

Apache SSL Installation Instructions
  1. Save the primary and intermediate certificates to a folder on the server with the private key.
  2. Open the Apache configuration file in a text editor. Apache configuration files are usually found in /etc/httpd. The main configuration file is usually named httpd.conf. In most cases the <VirtualHost> blocks will be at the bottom of this httpd.conf file. Sometimes you will find the <VirtualHost> blocks in a separate file in a directory like /etc/httpd/vhosts.d/ or /etc/httpd/sites/ or in a file called ssl.conf.
  3. If you need your site to be accessible through both secure (https) and non-secure (http) connections, you will need a virtual host for each type of connection. Make a copy of the existing non-secure virtual host and change the port from port 80 to 443.
  4. Add the lines in bold below. <VirtualHost 192.168.0.1:443>
    DocumentRoot /var/www/website
    ServerName www.domain.com
    SSLEngine on
    SSLCertificateFile /etc/ssl/crt/primary.crt
    SSLCertificateKeyFile /etc/ssl/crt/private.key
    SSLCertificateChainFile /etc/ssl/crt/intermediate.crt

    </VirtualHost> 
  5. Change the names of the files and paths to match your certificate files:
    1. SSLCertificateFile should be your primary certificate file for your domain name.
    2. SSLCertificateKeyFile should be the key file generated when you created the CSR.
    3. SSLCertificateChainFile should be the intermediate certificate file (if any) that was supplied by your certificate authority
  6. Save the changes and exit the text editor.
  7. Restart your Apache web server using one of the following commands: /usr/local/apache/bin/apachectl startssl
    /usr/local/apache/bin/apachectl restart

Wednesday, December 15, 2010

configure Apache in Weblogic server

. How to configure Apache in Weblogic  server?
To edit the httpd.conf file to configure the Apache HTTP Server Plug-In:
A. Open the httpd.conf file. The file is located at
APACHE_HOME/conf/httpd.conf (where APACHE_HOME is the root directory of your Apache installation).
B. Ensure that the httpd.conf LoadModule stanza will load the correct module by
verifying that the following two lines were added to the httpd.conf file when you ran the apxs utility:
LoadModule Weblogic_module libexec/mod_wl.so
AddModule mod_Weblogic.c
C. Add an IfModule block that defines one of the following:
For a non-clustered Weblogic Server: The WeblogicHost and WeblogicPort parameters.
For a cluster of Weblogic Servers: The WeblogicCluster parameter.
For example:
<IfModule mod_Weblogic.c>
WeblogicHost myWeblogic.server.com
WeblogicPort 7001
</IfModule>
2. What is Java Heap Memory? What is min and max memory for Weblogic?
Specify the minimum and maximum values for Java heap memory. For example, you may want to start the server with a default allocation of 64megabytes of Java heap memory to the Weblogic Server. To do so, you can start the server with the java -Xms64m and -Xmx64m options.
<===Read more===>