Plugin Personal Certificate will expire on April 26, 2012

Flash (Alert)


Abstract

The personal certificate called "WebSphere Plugin Key" within the plugin-key.kdb that is shipped with the WebSphere Plugin install will expire on April 26, 2012.

Content

AM I IMPACTED?

You will need to read through this flash to come to that determination.






Versions affected:
All versions of WebSphere Application Server for Distributed, IBM i, and z/OS operating systems (e.g., Version 8.0 and earlier) have the potential to be affected.
Note: Versions 6.0 and earlier are no longer in service. The purchase of a support extension might be required, if additional assistance is needed, unless you are otherwise entitled to support.








Problem Description:

When the plugin is first installed, it places a copy of the plugin-key.kdb file within the [Plugin_Home]/etc directory. When the plugin is configured to an installed web server, it will pull a copy of this file from the [Plugin_Home]/etc location and place it within the [Plugin_Home]/config/{webservername} directory.

This key file contains a personal certificate that is set to expire by April 26, 2012. Action may be required to maintain encryption between the plugin and application server(s). Please read this documentation carefully to determine if you are affected and what steps may be needed to correct this situation.

Who is affected by this?

Those using the plugin-key.kdb from the any of the above directories and don't use the propagation feature within a web server definition of the Admin Console. Typically these are users using the cell wide plugin generation and manually propagate the plugin to the web server location. Additionally, the application server must have been explicitly configured to trust this Plugin private key AND to require SSL client authentication (SSL mutual authentication).







Distributed (AIX, HP, Solaris Linux, Windows):
Before doing anything to the key file, please back up all plugin-key.* files.

1. How do I know if I'm using the plugin-key.kdb which contains the expiring personal certificate?

It is important to determine if you are set up to use Secure Socket Layer between the plugin and the application server.
  • Navigate to your Plugin_Home/config/<your webserver> directory and open the plugin-cfg.xml file.
  • Look for https transports. If you see one with Protocol=”https” then the following line will show you what keyfile you are currently using.
    <Transport Hostname="IBM-2F283EEE8BA" Port="9445" Protocol="https">
    <Property Name="keyring" Value="C:\Program Files\IBM\HTTPServer 7.0\Plugins/config/webserver1/plugin-key.kdb"/>
  • If the name of the key file is NOT “plugin-key.kdb” or you don’t have any https transports, then you aren’t working with the originally shipped file from the install and it is probably safe to end here.

Next, you need to review the content of the key file to see if you are working with the problematic key file. The default name from WebSphere is also plugin-key.kdb.
  • Navigate to your Plugin_Home/bin directory.
  • Launch iKeyman (bat/sh)
  • Select "Open" from the “Key Database File” menu
  • Within the Open panel,
    • change the Key database type to "CMS"
    • Click the "Browse" button and navigate to your Plugin_Home/config/<your webserver> directory.
    • Select the Plugin-key.kdb file.
    • Click "Ok"


  • When prompted for the password, enter "WebAS".
  • Make sure the database is showing “Personal Certificates”. This can be adjusted using the dropdown list box under “Key database content”.
    • If yours does not show a Personal Certificate named “WebSphere Plugin Key”, you can stop here.
  • Select the "WebSphere Plugin Key" certificate and click the "View/Edit" button on the right side of the screen.
  • This opens a new panel titled "Key information for [WebSphere Plugin Key]"


  • Toward the bottom of that panel is the Validity section. Check to see if yours has the validity period of May 13, 2001 to April 26, 2012.
  • If yours has the Personal Certificate named "WebSphere Plugin Key" and the validity period mentioned in the last step, then it is the key file.

2. Do I need this certificate?

If there are other personal certificates listed and the named “WebSphere Plugin Key” does not have an asterisk next to it and some other named certificate does, then it’s not is use and you can stop here.

Determining Mutual Authentication
If you are running mutual authentication between the plugin and the application server and there are no other personal certificates listed, it is likely that this certificate is in use. Using mutual authentication is unusual for SSL between the plugin and application server.

If there are other personal certificates present or you don't use mutual authentication, then it may be safe to remove this certificate.

3a. How do I determine if I’m using mutual authentication between the plugin and application servers (not for WebSphere 6.0, see 3b)?
    1. Navigate to Security > SSL certificate and key management > Manage endpoint security configurations
    2. In this panel, expand Inbound > (cell name) > (node name of where an application server is running) > servers > (server name)
    3. Click WC_defaulthost_secure then find out SSL configuration name which can be found one of followings:
      1. If Override inherited values check box is unchecked, the value in Inherited SSL configuration name.
      2. If Override inherited values check box is checked, the value in SSL configuration.
    4. Then navigate to Security > SSL certificate and key management > SSL configurations
    5. Click SSL configuration name which was identified by III).
    6. Click Quality of protection (QoP) settings
    7. Mutual authentication is enabled if the Client authentication box has either “required” or “supported” selected.



3b. How do I determine if I'm using mutual authentication between the plugin and application servers within WebSphere 6.0?
    1. Navigate to Security > SSL within the left-hand panel
    2. Select the SSL configuration repertoire within the SSL configuration repertoires panel.
    3. Mutual authentication is enabled if the client authentication check box is checked.

4. What do I do if I use this certificate and need mutual authentication?

It would be best to create a new keyfile for the plugin. In doing so, you would be using the latest Signer Certificates and associated Personal Certificates.

Use the following URL’s to explain the steps for generating personal certificates and creating mutual authentication between WebSphere and the Plugin.

Configuring the Web server plug-in for Secure Sockets Layer

Implementing a non-default keyfile for the Web server

Note: It would be beneficial to remove the expiring personal certificate from the [Plugin_Home]/etc copy of the plugin-key.kdb file.







z/OS:
Before doing anything to the key file, please back up all plugin-key.* files.

1. How do I know if I'm using the plugin-key.kdb which contains the expiring personal certificate?

It is important to determine if you are set up to use Secure Socket Layer between the plugin and the application server.
  • Navigate to the directory that contains your plugin-cfg.xml file and open it.
  • Look for https transports. If you see one with Protocol=”https” then the following line will show you what keyfile you are currently using.
<Transport Hostname="IBM-2F283EEE8BA" Port="9445" Protocol="https">
<Property Name="keyring" Value="/opt/[plugin_home]/ plugin-key.kdb"/>
  • If the name of the key file is NOT “plugin-key.kdb” or you don’t have any https transports, then you aren’t working with the originally shipped file from the install and it is probably safe to end here.

Next, you need to review the content of the key file to see if you are working with the problematic key file. The default name from WebSphere is also plugin-key.kdb.

z/OS provides the gskkyman utility.

Command to display all certificates:
    gskkyman -dc -k "plugin-key.kdb"

Command to display a specific certificate's details:
    gskkyman -dc -k Plugin-key.kdb -l "WebSphere Plugin Key"
      (you will be prompted for the password)
    If the record does NOT exist, you will get the following:
      Unable to get record.
      Status 0x0335300e - Record not found.
    If the record DOES exist, your results will be like the following:

    Label:
    <WebSphere Plugin Key>
    Trusted:
    Yes
    Version:
    3
    Serial number:
    3afffa86
    Issuer's Name:
    <CN=WebSphere Plugin Key,OU=SWG,O=IBM,C=US>
    Subject's Name:
    <CN=WebSphere Plugin Key,OU=SWG,O=IBM,C=US>
    Effective Date:
    2001/05/13 15:32:22
    Expiration Date:
    2012/04/26 15:32:22
    ..... More content here ..........
    Default key:
    Yes (indicates that this is the default certificate for mutual authentication)
    Certificate extensions:
    0

If you got this type of response with this date, then your keyfile does have the affected certificate.

2. Do I need this certificate?

You will need to determine if mutual authentication is turned on. Review the content within the Distributed section for Determining Mutual Authentication .

Delete the Certificate

To delete the certificate, you will need to use gskkyman's interactive mode.

1. Navigate to the affected plugin-key.kdb file and type gskkyman.
2. Select option 2 (open database)
3. When prompted, key in the kdb file name and provide the password.
4. Select option 1 (Manage keys and certificates)
5. Select the option number that corresponds to the "WebSphere Plugin Key".
6. Select option 8 (Delete certificate and key).
7. Select option 1 (Confirm).

At this point, you should get a "Record deleted." message. You can now exit the gskkyman utility.











IBM i:
Use of an IBM i user profile with *ALLOBJ and *SECADM special authorities is required for the steps below.

1. How do I know if I'm using the plugin-key.kdb which contains the expiring personal certificate?

- For IBM i, HTTP servers configured with version 6.0 of the Application Server can be affected.

- HTTP servers configured with WebSphere Application Server V6.1 and later can also be affected, but ONLY if the WebSphere Application Server Plugins product option is installed. Use GO LICPGM, option 10 to check for prduct option 7 of 5733W61, 5733W70, or 5733W80.

If one or more of these products are installed, then follow the steps below to determine whether your HTTP servers are affected.

Note: On IBM i, the plugin-key.kdb file with the expiring certificate can be located in the <plugin_install_root>/etc, /QIBM/ProdData/WebSphere/AppServer/V6/<edition>/etc, and /QIBM/UserData/WebSphere/AppServer/V6/<edition>/profiles/<profile_name>/etc directories. Invoke the querywasinstalls Qshell script located in directory /QIBM/WAS/bin from a Qshell session to list the installed WebSphere Application Server products and their locations (i.e. <plugin_install_root>).


- On your IBM i that hosts the HTTP servers, use the "IBM Web Administration for i" to display the configuration file for each HTTP server.

- Look for a WebSpherePluginConfig directive in the HTTP server configuration file. For example:

WebSpherePluginConfig /QIBM/UserData/WebSphere/AppServer/V6/ND/profiles/profile1/config/cells/my_cell/nodes/my_managednode/servers/webserver1/plugin-cfg.xml

If you do not see a WebSpherePluginConfig directive in the HTTP server configuration file, then this HTTP server is not affected.


- Open the <path>/plugin-cfg.xml file and look for https transports. If you see one with :
Protocol=”https” then the following line will show you what keyfile you are currently using. For example:

<Transport Hostname="MYHOST.IBM.COM" Port="10002" Protocol="https">
<Property Name="keyring"
Value="/QIBM/UserData/WebSphere/AppServer/V6/ND/profiles
/httpsvr/etc/plugin-key.kdb"/>
<Property Name="stashfile" Value="/QIBM/UserData/
WebSphere/AppServer/V6/ND/profiles/httpsvr/etc/plugin-key.sth"/>
</Transport>

If you don’t have any https transports, the keyring file is not “plugin-key.kdb” , or the directory is not one of <plugin_install_root>/etc, . /QIBM/ProdData/WebSphere/AppServer/V6/<edition>/etc, or /QIBM/UserData/WebSphere/AppServer/V6/<edition>/profiles/<profile_name>/etc then
this HTTP server is not affected.

- Check to see if the referenced plugin-key.kdb file exists in IFS. If the plugin-key.kdb file does not exist, then the https transport is not operational and this HTTP server is not affected by the expiring certificate problem.


Note: The web server plug-in automatically uses the http transport when the https transport is not operational.

- Start the HTTP Admin server if it is not already running:
STRTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN)
- In the browser, enter the following:
machine:2001 (enter credentials).

- Click Digital Certificate Manager.

Note: For IBM i 6.1 and later, you’ll need to expand IBM i management and click Internet Configurations before clicking Digital Certificate Manager.

- Click Select a certificate store.
- Select Other system certificate store, and then click Continue.
- Enter the path to the plugin-key.kdb file in the Certificate store path and file name field.

- Enter the password (WebAS is the default password) and click Continue.

- In the left hand panel, click Manage Certificates

- Select View certificate and click Continue

- Select Server or client and click Continue

- If the name of the certificate is not “WebSphere Plugin Key”, stop here. Your HTTP server is not affected. Otherwise, continue with the next step.

- Click View

- Check the validity period to see if yours has May 13, 2001 to April 26, 2012. If the validity period is May 13, 2001 to April 26, 2012, then this keystore is the plugin-key.kdb which contains the expiring personal certificate.

2. Do I need this certificate?

- From DCM, click OK to return from viewing the WebSphere Plugin Key certificate to viewing the list of server or client certificates in the plugin-key.kdb file.

- If there are other personal certificates listed and the “WebSphere Plugin Key” certificate is not the default certificate (not the certificate named in the Default certificate label field), then it’s not in use and you can stop here. Your HTTP server is not affected. Otherwise, continue with the next step.

- If you are running mutual authentication between the plugin and the application server and there are no other personal certificates listed, it is likely that this certificate is in use. If there are other personal certificates present or you don't use mutual authentication, then it may be safe to remove this certificate.

3. How do I determine if I’m using mutual authentication between the plugin and application servers

- See the answer to this question for the Distributed Platforms, above


4. What do I do if I use this certificate and need mutual authentication?

It would be best to create a new keyfile for the plugin. In doing so, you would be using the latest Signer Certificates and associated Personal Certificates.

Use the following URL’s to explain the steps for generating personal certificates and creating mutual authentication between WebSphere and the Plugin.

Note: It would be beneficial to remove the expiring personal certificate from the plugin-key.kdb file.

WebSphere Application Server V6.0:

Configuring the Web server plug-in for Secure Sockets Layer

WebSphere Application Server V6.1:


Configuring the Web server plug-in for Secure Sockets Layer

Implementing a non-default keyfile for the Web server

Note: The above two URL’s link to articles in the information center for WebSphere Application Server Express (Distributed Operating Systems), V6.1. However, these two articles apply to IBM i as well.

Related information

Password to the Plugin-key.kdb will expire on April 26


Change History
2/6/2012 Flash published
4/23/2012 Added IBM i & z/OS information




Related information

Password to the Plugin-key.kdb will expire on April 26

Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

WebSphere Application Server
Plug-in

Software version:

5.0, 5.1, 6.0, 6.1, 7.0, 8.0

Operating system(s):

AIX, HP-UX, IBM i, Linux, Solaris, Windows, i5/OS, z/OS

Reference #:

1577327

Modified date:

2012-04-24

Translate my page

Machine Translation

Content navigation