Date Created: Fri 18-Jan-2008

Related Document Categories:


    Click the link below for WebSphere / IHS SSL secrets:

    http://www.webspheretools.com/sites/webspheretools.nsf/docs/WebSphere%20SSL%20Secrets%20-%20Part1


    Below are some points about SSL key and trust stores from IBM documentation and articles.

    The default Key file and Trust store password is WebAS. Often you will see {xor}CDo9Hgw\= this is the encrypted version.

    A key store (in JSSE terms) stores the personal certificate, which represents the X509Certificate, public key, and private key. This is the representation of the identity of this entity.

    A key store contains the personal certificates that can be used as the identity for the SSL end point referencing the key store. If more than one certificate is present, a certificate alias on the SSL configuration specifies one of the personal certificates. When an SSL connection is made (on either the client or the server side), certificates may be exchanged. The personal certificate referenced by the SSL configuration and stored in the key store is the certificate that will be used.

    A keystore contains both public keys and private keys. Public keys are stored as signer certificates, while private keys are stored as personal certificates. In WebSphere Application Server, adding keystore files to the configuration is different between client and server. For the client, a keystore file is added to a file, like the sas.client.props property file. For the server, a keystore file is added through the WebSphere Application Server administrative console.

    A personal certificate represents the identity of the end point and contains a public and private key for signing/encrypting data.

    A trust store (in JSSE terms) stores the X509Certificate and public key only (also referred to as a signer certificate). The trust store must contain all signer certificates from all other entities that it is trusting to make connections to or with. Without the signer of the remote entity, an SSLHandshakeException occurs with a message stating "No trusted certificate found."

    A trust store contains the signer certificates which this end point trusts when either making connections (from an outbound end point) or accepting connections (for an inbound end point).

    The default server truststore is called the DummyServerTrustFile.jks file. The file is located in the ${USER_INSTALL_ROOT}/etc/ directory. The default password is WebAS. It is recommended that you create a new key file and trust file if you plan to use the certificate in a production environment.

    The default client truststore is called the DummyClientTrustFile.jks file. The file is located in the ${USER_INSTALL_ROOT}/etc/ directory. The default password is WebAS. It is recommended that you create a new key file and trust file if you plan to use the certificate in a production environment.

    A signer certificate represents a certificate and public key associated with some personal certificate. The purpose of the signer certificate is to verify personal certificates. By accepting the signer certificate into an end point's trust store, you are allowing the owner of the private key to establish connections with this end point; that is, the signer certificate explicitly trusts connections made to or by the owner of the associated personal certificate. The signer certificate is typically made completely public by the owner of the personal certificate, but it's up to the receiving entity to determine if it is a trusted signer prior to adding it to the trust store.

    How to encrypt a props file

    The PropFilePasswordEncoder command encodes passwords that are located in plain text property files. This command encodes both Secure Authentication Server (SAS) property files and non-SAS property files. After you encode the passwords, a decoding command does not exist.

    To encode passwords, you must run this command from the directory:
    ${app_server_root}/bin

    Syntax - The command syntax is as follows:
    PropFilePasswordEncoder "file_name" { passwordPropertiesList | -SAS } [ -profileName profile ] [ -help | -? ]

    Parameters
    The following option is available for the PropFilePasswordEncoder command:

    file_name - This required parameter specifies the name of the file in which passwords are encoded.

    passwordPropertiesList - This parameter is required if you are encoding passwords in property files other than the sas.client.props file. Specify one or more password properties that you want to encode.

    -SAS This parameter is required if you are encoding passwords in the sas.client.props file.

    -profileName This parameter is optional. The profile value specifies an application server profile name. The script uses the password encoding algorithm that it retrieves from the specified profile. If you do not specify this parameter, the script uses the default profile.

    -help or -? If you specify this parameter, the script ignores all other parameters and displays usage text.

    Example - The following examples demonstrate correct uses of the syntax:
    PropFilePasswordEncoder "file_name"
    PropFilePasswordEncoder "file_name" password_properties_list
    PropFilePasswordEncoder "file_name" -SAS


    To encode passwords, you must run this command from the directory:
    ${app_server_root}/bin

    for eg:
    Path: /apps/was/ws6/inst01/profiles/dmgr/properties
    Command: /bin/PropFilePasswordEncoder.sh soap.client.props com.ibm.SOAP.loginPassword

    Note: When you use this tool that all comments will be removed during the encryption. It is best to use the tool to encrypt the props file than edit the backup it creates with your encrypted file. The backup file is an exact copy of the original. This way you get to keep your comment history which is useful for what each props security line is for etc. Then replace the newly generated file with the backup to get a file which is exactly the same except with encryption.

    Tips for UNIX: Search for old password to ensure you have changed all relevant files.

    find /apps/was/ws6/inst01/ -type f 2>/dev/null | xargs grep <password> 2>/dev/null

    Note that you must use the console to edit the LPTA password as new keys are generated using the password. You should only edit security.xml for serverPassword and BindPassword! You must restart all of WAS. incl Deployment Manager and Node Agents.

    References:

    Steven Charles Robinson
    Administration Console Help (installed with WAS)
    IBM WebSphere Developer Technical Journal: SSL, certificate, and key management enhancements for even stronger security in WebSphere Application Server V6.1
    WebSphere Application Server, Version 6.0 Information Center

Middleware Mentor - Steven Charles Robinson

About Me

Steve Robinson has been working in IT for over 15 years and has provided solutions for many large-enterprise corporate companies across the world. Steve specialises in Java and Middleware consulting. Steve comes from both an administration and development background.

Before moving to JEE, Steve was an accomplished developer and consultant for both IBM Lotus Notes and Microsoft .NET Technologies.

Follow Steve as @stevencrobinson on twitter.

Read my books?

IBM WebSphere Application Server 8.0 Administration Guide

IBM WebSphere Application Server 8.0 Administration Guide

WebSphere Application Server 7.0 Administration Guide

WebSphere Application Server 7.0 Administration Guide

WebSphere Categories

Oracle WebLogic Categories

JBoss Categories

Other Categories