How To
Summary
The default WebSphere self-signed certificate does not include the Subject Alternative Name (SAN), but with the latest Chrome browser, the SAN is required for a certificate to be considered as valid.
In addition, OpenPages Docker images create the WebSphere default certificate with virtual hostnames which are not real hostnames. Therefore, the Chrome browser could not validate the hostname in the certificate. In order to fix this, a new self-signed certificate with correct hostnames needs to be created.
Objective
Fix the invalid certificate issue with Chrome browser for OpenPages Docker images.
Environment
WebSphere's FixPack 9.0.0.6 or higher is required to create the certificates with Subject Alternative Name
Steps
Symptom of Problems
If you are using OpenPages Docker image you may see the error below with the latest Chrome browser.
And if you open the Developer Tools in Chrome you should the two error messages under the security section
The following step will lead you to fix those two errors showed above.
Include Subject Alternative Name in the self-signed certificate
- Log into WebSphere Administrative Console
- Click on “Security” on the left-hand side
3. Click on "Global Security" at the drop-down menu
4. On the Global Security page select "Custom Properties" link
5. Click "New" button to create a new property
6. In the "Name" field type in "com.ibm.websphere.security.addSANToSSLCertificate"
7. In the "Value" field type in "true"
8. After click on "Apply" button, please select "save" to confirm the change
9. Restart servers to let the new property to take effect
Create Self-Signed Certificates
1. Before you start, back up the deployment manager (dmgr) profile of your WebSphere Network Deployment server
|
| cd <DMGR_PROFILE>/bin ./backupConfig.sh -nostop |
Save a copy of the security.xml, key.p12, and trust.p12 files, which are in the following directories:
|
| <DMGR profile>/config/cells/<Cell Name>/security.xml <DMGR profile>/config/cells/<Cell Name>/nodes/<Node Name>/key.p12 <DMGR profile>/config/cells/<Cell Name>/nodes/<Node Name>/trust.p12 |
2. Create a self-signed root certificate with required parameters under the DmgrDefaultRootStore keystore
- Log in to the administration console of your server. Select Security>SSL certificate and key management>Keystores and certificates. From the Keystore usages menu, select Root certificates keystore
- Choose DmgrdefaultRootStore
- Under Additional Properties, click Personal certificates. Click Create, and select Self-signed certificate to create a self-signed certificate. In this example, the alias for the new certificate is root_2048_sha256.
- For the Common name field please make sure type in the full hostname in the URL that you will use to access OpenPages. For example, if the URL is "https://openpges.server.com:10111", please enter "openpages.server.com" in this field.
- Click Apply, and then click OK. Click Review, and then select Synchronize. Click Save.
3. Exchange signer certificates in the deployment manager root keystore and signers store
Exchange signer certificates between the root store (DmgrDefaultRootStore) and signer store (DmgrDefaultSignerStore) of the deployment manager. As a result, the selected root personal certificate in DmgrDefaultRootStore is added to the signers list of DmgrDefaultSignerStore.
- From your server's administration console, select Security>SSL certificate and key management>Key stores and certificates. From the Keystore usages menu, select All
- Choose DmgrDefaultRootStore and DmgrDefaultSignersStore, and then click Exchange signers
- Under Signers to exchange, select the root_2048_sha256 certificate. Then, click Add. The certificate is then added to the DmgrDefaultSignersStore keystore
4. Exchange signers with the cell's default truststore
Exchange signer certificates between the keystore of the deployment manager (DmgrDefaultRootStore) and the default trust store of the cell (CellDefaultTrustStore). As a result, the selected root personal certificate in DmgrDefaultRootStore is added to the signers list of CellDefaultTrustStore.
- Select Security>SSL certificate and key management>Key stores and certificates. From the Keystore usages menu, select All. Select DmgrDefaultRootStore and CellDefaultTrustStore, and then click Exchange signers.
- Select root_2048_sha256, and click Add to add the signer certificate to the CellDefaultTrustStore keystore
- Click Apply and OK. Click Review, select Synchronize, and then click Save
5. Create a default chained certificate in the default keystore for the cell
Create a chained certificate under CellDefaultKeyStore. The root certificate that you created in Step 2 is used as a signer certificate to this chained certificate.
- Select Security>SSL certificate and key management.
- Choose CellDefaultKeyStore. Click Personal Certificates, and then create a chained certificate
- The alias for the certificate is default_2048_sha256. Under Root certificate used to sign the certificate, select root_2048_sha256. For the Common name field please make sure type in the full hostname in the URL that you will use to access OpenPages. For example, if the URL is "https://openpges.server.com:10111", please enter "openpages.server.com" in this field
- Enter values for the parameters. Click Apply, and then click OK. Click Review, select Synchronize, and click Save to synchronize the changes with your nodes
6.Create a default chained certificate in the default keystore for the node
Create a chained certificate under NodeDefaultKeyStore. The root certificate that you created in Step 2 is used as a signer certificate to this chained certificate.
- Select Security>SSL certificate and key management>Key stores and certificates. Choose NodeDefaultKeyStore. Click Personal Certificates, and then create a chained certificate. The alias for the certificate is default_2048_sha256
- For the Common name field please make sure type in the full hostname in the URL that you will use to access OpenPages. For example, if the URL is "https://openpges.server.com:10111", please enter "openpages.server.com" in this field
- Expand the Root certificate used to sign the certificate menu, and select root_2048_sha256.
- Enter values for the parameters. Click Apply, and then click OK. Click Review, select Synchronize, and then click Save to synchronize the changes with your nodes
7. Update the endpoint security configuration for each cell and node
Manage the endpoint security configuration (both inbound and outbound) for each cell and node.
- Select Security>SSL certificate and key management. The following figure shows the inbound configurations CellDefaultSSLSettings and NodeDefaultSSLSettings, and the outbound configurations CellDefaultSSLSettings and NodeDefaultSSLSettings
- Under each configuration, change the value of the Certificate alias in KeyStore to default_2048_sha256
- Click Apply, and then click OK. Click Review, select Synchronize, and then click Save to synchronize the changes with your nodes
8.Restart the application server
When you stop the servers by using the command line, e.g. <OP_HOME>/bin/[start | stop]AllServers.[sh | bat], you are prompted to accept the new certificate that you created. Select Y to accept the certificate and continue. After all the processes stop, restart them. You may need to restart the server more than one time to let the new certificate to effect.
Import new OpenPages certificate to Cognos
1. Before starting the process please back the Java keystore at ${JAVA_HOME}/jre/lib/security/cacerts
2. After the new certificate is created for OpenPages, the SSL handshake between Cognos and OpenPages will be broken. Now if you try to access reports from OpenPages home page, you will see the error below
3. To solve this issue, you need to import the new OpenPages certificate into Cognos keystore. Login to the report server docker container and execute the three commands below in order. OP_EXT_HOST is the hostname that hosting the docker container. e.g. "openpages.server.com ". OP_EXT_POST is the port number in the URL to access OpenPages, in Docker, the port by default is 10111
# import certificate from opapp container
openssl s_client -servername ${OP_EXT_HOST} -connect ${OP_EXT_HOST}:${OP_EXT_PORT} </dev/null 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /home/opuser/opapp_cert.pem
# remove old certificate
(su -l opuser -c "\${JAVA_HOME}/jre/bin/keytool -delete -alias opcert -keystore \${JAVA_HOME}/jre/lib/security/cacerts -storepass changeit >/dev/null || /bin/true")
# create a new certificate
su -l opuser -c "\${JAVA_HOME}/jre/bin/keytool -import -alias opcert -trustcacerts -file /home/opuser/opapp_cert.pem -keystore \${JAVA_HOME}/jre/lib/security/cacerts -storepass changeit -noprompt"
For non-docker users above commands may not work for you. Then you can also extract the certificate from OpenPages server via WebSphere's administrative console. Please follow the document here:
4. Go to <Cognos_Home>/congiuration directory, then open OpenPagesSecurityProvider_OpenPagesSecurityRealm.properties file. Make sure property openpages.application.url has the correct application server container hostname. For now, the hostname is "opapp" by default, it should be replaced with the real hostname of the server. e.g. "openpages.server.com"
5. Restart Cognos. After the restart, you should be able to connect to Cognos and reports from OpenPages correctly.
Import Certificates to Local Keystore
1. To let Chrome browser trust the new certificate and show a green secure icon, you need to add the certificate to the local key store on the machine. The certificate has to be imported to every host where the Chrome browser is used for OpenPages
2. After the above step, if you still see "Not Secure" sign on Chrome browser, you can close the browser and restart it.
Related Information
Was this topic helpful?
Document Information
Modified date:
20 July 2018
UID
ibm10713751