IBM Support

Problem Configuring Root/Leaf certificates with the same DN

Troubleshooting


Problem

Problem when creating root certificates without unique DN.

Symptom

Error in the browser over HTTPS connections which prevents users from accessing the Integrated Solutions Console and any other running applications.

Cause

DN of the leaf certificate presented by WAS matches the DN of its root signing certificate; browsers consider this a malformed certificate chain.

Diagnosing The Problem

When WAS certificates are configured in this manner, you can expect to see errors like the following in your browser when attempting to access the Integrated Solutions Console or other applications running on the server's secure transports.

Google Chrome:

Microsoft Internet Explorer:

Mozilla Firefox:

Resolving The Problem

1. Though the root keystore is visible in the ISC, it's not configurable there. In order to modify it, we'll have to use iKeyman. Open iKeyman from the java/jre/bin directory of your WAS installation.

2. Load the cell's root-key.p12 into iKeyman. In ND environments, it's located in DMGR_PROFILE_ROOT/config/cells/CELL_NAME/nodes/CELLMANAGER_NODE/. For Standalone environments, it's located in SERVER_PROFILE_ROOT/config/cells/CELL_NAME/nodes/NODENAME/. The default password for root-key.p12 is "WebAS" just like the other WAS keystores.


3. Take a moment to view the current root certificate DN, and perhaps compare it to the DN of the certificate in the server's keystore in order to verify that they are identical. Here's an example:

4. Create a new root certificate. You won't be able to delete the current one before creating a new one, because empty key.p12 files are not allowed by iKeyman.

a. Click "New Self-Signed..."

b. Use temporary key label "root2" so that we don't conflict with the current root.

c. Fill out the certificate DN details as needed, but be sure to add a field which will NOT be present in the new personal certificate on the node which we'll create in the next step. For example, by default WAS adds OU=Root Certificate to the root certificate in order to prevent this type of conflict.

*NOTE: By default, WAS sets the expiration date on the root certificate to 15 years (5475 days). Be sure to specify this on the new certificate if desired.

5. Delete the old root certificate using the Delete button.

6. Click the "Rename" button to rename your "root2" certificate to "root".

7. Create a leaf certificate signed by the new root.

a. Disable security on the WAS server so that the ISC can be accessed: https://www-304.ibm.com/support/docview.wss?uid=swg21405302

b. Navigate to the "Security > SSL certificate and key management > Key stores and certificates" panel.

c. Repeat the following process for each keystore

i. Select the keystore

ii. Click the "Personal certificates" link

iii. Click Create > Chained certificate

iv. Fill in the information for this cert, and ensure that the new root certificate is selected as the "Root certificate used to sign the certificate. BE SURE to fill out these fields such that this new leaf certificate has a different DN (Issued To) field than the root's DN (Issued By).

v. Select the old Personal Certificate and click Delete.

8. Navigate to the "Security > Global Security" panel and enable administrative security, and application security if desired.

9. Restart all WAS JVMs for the changes to take effect.

[{"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"Java Security (JSSE\/JCE)","Platform":[{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"},{"code":"PF010","label":"HP-UX"},{"code":"PF002","label":"AIX"}],"Version":"7.0","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
15 June 2018

UID

swg21614578