DETAIL: ws_common: websphereFindTransport: Setting the transport(case 1): servis2 on port 9443
As is apparent in the logs, the plug-in opens a stream through WebSphere Application Server HTTPS transport port (9443). However the certificate sent by WebSphere Application Server to the plug-in cannot be authenticated by the plug-in key file. The reason is that the plug-in key file does not have the adequate signer to authenticate the certificate sent by WebSphere Application Server.
In earlier releases of WebSphere Application Server, it was suspected that the certificate might have become expired. However, WebSphere Application Server V6.1 has a new function called “certificate monitoring” which does the following:
Notifies the user in defined time intervals before a certificate expires
Automatically replaces self-signed certificates that are about to expire
Updates all trust stores in the cell
If you want to check it anyway, you can click on the “view certificate button” that will appear on your browser when you send the HTTPS request. Also, you can use the new WebSphere Application Server V6.1 embedded key management feature, or iKeyman, to view the certificate.
Before attempting to describe how, which, and in which stores proper signer certificates must be added, WebSphere Application Server V6.1 SSL management enhancements must be closely examined.
In WebSphere Application Server V6.1, each profile is created with its unique self signed certificates. All profiles have their own node level key and trust stores. For Network Deployment, there is also a cell level key store, CellDefaultKeyStore, and a cell level trust store, CellDefaultTrustStore, which are pointed out by all nodes in default cell settings. To establish a proper SSL configuration in which all nodes (including the dmgr node) can communicate with each other, their default certificates are added to the cell level trust store as signer certificates. In addition, for SSL to be properly configured between a web server and WebSphere Application Server V6.1, its plugin-key.kdb file must include all nodes’ default certificates as signer certificates, and web server node’s default certificate must exist in the CellDefaultTrustStore considering that a web server also works in a node.
As the facts show, SSL configuration between plug-in and WebSphere Application Server is completely different for version 6.1. In earlier releases, default dummy certificates were exchanged between plug-in and WebSphere Application Server. These dummy certificates are also included in version 6.1, yet only for backwards capability issues. The rest of the document will show you how to establish proper configuration in WebSphere Application Server V6.1.
Resolving the problem
For Network Deployment
1. In the administrative console, go to Security > SSL certificate and key management.
Before doing any changes, put select Dynamically update the runtime when changes occur on this page. This option makes sure that changes are propagated to runtime immediately after they are saved. This option requires a restart to become active after it is selected. If this option is enabled, make sure that you make SSL configuration changes when the system does not have a high burden on it to prevent performance impacts.
2. Click the Manage endpoint security configurations link.
3. Expand Inbound or Outbound, expand the cell name to see the list of nodes.
For all the nodes that appear in the list:
Opening an empty text file will help you through the process.
4. Go to Key stores and certificates which is under Related Items.
5. Click on the NodeDefaultKeyStore. Under Additional Properties, click on Personal Certificates.
6. Note down the serial number of the default certificate. Select the box near the default certificate. Click Extract.
7. Write the file name to be extracted with the full path, leave the data type as it is, note down the file path after the serial number. Click OK.
If you chose to create a cell profile after your initial WebSphere Application Server installation, the cell manager node and the stand alone node you have created that time might have the same certificate with the same serial number. Do not let it confuse you.
After the previous instructions are done for all nodes, continue with the following steps.
8. Come to the Manage endpoint security configurations page where you see the node list again (instructions 1-3).
9. Expand the node which includes the web server.
10. Click on the web server, then click on Key stores and certificates.
11. Click on the CMSKeyStore.
12. Click on the Signer certificates. You can either add here all the certificates you have extracted, or you can click on default certificates in this page, if there are any, and compare their serial numbers with the numbers that you have taken note of to determine which default certificates are missing.
For all the certificates or just the missing ones apply the instructions below.
13. Click Add on the current page.
14. Enter the certificate file path, an alias as you wish, and leave the data type as it is. Click OK.
When you are sure that you have the complete set of default certificates added as signer certificates, save the changes, and synchronize.
Verifying that changes are propagated
Now, check if the changes are propagated to runtime. If you have enabled the option Dynamically update the runtime when changes occur on the SSL certificate and key management page, they are propagated automatically. Here is the checking procedure:
1. Open the httpd.conf file of your web server. Find the line that starts with “WebSpherePluginConfig“. This line points to the path of your plugin-cfg.xmlfile that is used in runtime. Take note of the directory that this file resides.
2. Run iKeyman. There are copies of iKeyman you can use in the follownig locations:
3. httpserver_root/bin if you are using IBM HTTP Server
3. Click on the Key Database File menu and choose Open. Select CMS as the key database type, click on browse, and browse to the path that you have taken note of in step 1. Double-click plugin-key.kdb, and click ok to open it. The password is WebAS.
4. Click Personal Certificates. Select Signer Certificates from the drop down list.
5. Check to see that all the signer certificates that you have added in previous steps 12 – 14 are also added as signer certificates in this file. If they are not, add them by using the add button. Again you need to keep the data type as it is. You just need to browse to the key files and click “ok”.
6. Restart the web servers.
For stand alone (Base and Express)
The procedure is the same for these products. The only difference is the number of nodes.
Note 1: If you still have the error after these changes make sure that:
For Network Deployment, CellDefaultTrustStore has all nodes’ the signer certs.
For Stand Alone, NodeDefaultTrustStore has all nodes’ the signer certs. You might also need to extract the web server’s certificate and add it to the web server node’s signer certificates, which can be done by using the administrative console’s certificate management as in steps before verification, and plugin-key.kdb which can be done by using iKeyman as in the verification steps.
Note 2: From Fix Pack 5 (188.8.131.52) onwards, if a new node is federated after the web server definition has been created, the signer for the new node will be automatically updated to the plugin-key.kdb. It is recommended to apply this fix pack.
1.IHS User’s Guide中的Chapter 5中的securing communications
2.WebSphere Application Server V6.1 Security Handbook(sg246316).pdf中的7.2和7.3
3.WebSphere Security Fundamentals(redp3944).pdf
——Start of DE processing—— = [07-1-26 15:48:29:228 CST] , key = javax.management.MBeanException com.ibm.ws.management.AdminServiceImpl.invoke 679
Exception = javax.management.MBeanException
Source = com.ibm.ws.management.AdminServiceImpl.invoke
probeid = 679