Renewing SSL Certificates for IBM WebSphere and Apache Tomcat

Renewing a certificate for IBM WebSphere or Apache Tomcat is a relatively straightforward process.  There are, however, some subtle differences between renewing and installing a fresh certificate that I would like to document here primarily so I make it easier on myself the next time I need to simply renew a certificate.  If you are looking for more advanced information please consider these articles on configuring IBM WebSphere for SSL and installing or importing certificates into a WebSphere Trust Store.

If an IBM WebSphere or Apache Tomcat application server is nearing the validation end of their SSL certificates you can follow these steps to ensure that your servers remain secure and your user’s experiences are not interrupted.

IBM WebSphere

Step 1: Backup the existing certificate in case you need to revert.

  • Connect to the server where IBM WebSphere HTTP Server is installed. Navigate to the folder [IBM_HTTPServer_Home]\.
  • Backup or move the existing SSL certificate to an expired_certs folder Ex: C:\IBM\HTTPServer

renewing_ssl_certificate_websphere_apache_tomcat_ibm_maximo_update_ugrade_support_blog_help_tip_troubleshoot

Step 2: Copy the new certificate to IBM WebSphere HTTP Server home folder.

  • Copy the new Maximo SSL certificate to the [IBM_HTTPServer_Home]\ folder. If you need help requesting a new certificate, please refer to our article configuring IBM WebSphere for SSL.

Step 3: Launch IBM Key Management application to import new certificate

  • Launch the IBM Key Management application.
  • Click Export/Import button from the right-side button menu.
  • Select the Import Key radio button.
  • Change the Key file type to PKCS S12 using the drop-down menu.
  • Browser to the file name of the certificate that was copied in Step 3

ibm_maximo_blog_updating_ssl_certificate_websphere_server_security_renew_maximosecrets

  • Click the OK button. Supply the password associated with this certificate.

ibm_maximo_blog_renew_ssl_certificate_security_update_credentials_managed_service_self_help_how to

  • Click the OK button.
  • Select the label under Select a label to change. In the Enter a new label textbox provide a new label for this certificate.

  • Click the OK button.
  • Double-click the certificate that was just added with the new label.

ibm_maximo_blog_supprt_troubleshoot_fix_security_renew_ssl_certificate_update_websphere_apache_tomcat

  • Click the Set the certificate as the default checkbox at the bottom left.

ibm_maximo_blog_validation_of_ssl_certificate_update_websphere_apache_tomcat_troubleshoot_security

  • Click the OK button.
  • The certificate that was just added with the new label should now have an * next to its name.

ibm_maximo_websphere_update_apache_tomcat_renew_ssl_certificate_blog_troubleshoot_support

  • Click the OK button.
  • The certificate that was just added with the new label should now have an * next to its name.

 

Apache Tomcat

Step 1: Backup the existing certificate in case you need to revert.

  • Connect to the server where Apache Tomcat server is installed. Navigate to the folder [Apache_Tomcat_Home]\conf. Ex: C:\Apache\Tomcat\conf
  • Backup or move the existing SSL certificate to a certs folder.
  • Open the server xml file using a text editor.

ibm_maximo_suppprt_renew_new_ssl_cerificate_server_security_validation_websphere_apache_tomcat_blog

 

Step 2: Edit the server.xml file.

  • Locate the section <Connector port=”443” scheme=”https” . Change the name of the certificate if necessary.  Update the keystorePass value to the new password for the certificate.
  • NOTE: This is an XML document. Consequently, any ampersand or quote characters will need to be replaced.  For example, if your password is 1234”& then the value for keystorePass would be keystorePass=”1234&quot;&amp;”

How_to_renew_ssl_certificate_websphere_apache_tomcat_ibm_maximo

  • Save the server xml document and restart the Apache Tomcat service.

Log4J Security Vulnerability System Patching for WebSphere

At the end of 2021, many companies were faced with the log4j security vulnerabilities. This was a worldwide security that has caused a lot of problems. For users of IBM Maximo, their Maximo environments were not affected, however WebSphere was impacted. The vulnerability caused Apache Log4j to allow a remote attacker to execute arbitrary code on the system. If an attacker were to access the system they would be able to write access to the Log4j configuration and de-serialize untrusted data. If the deployed application is configured to use JMSAppender, an attacker could exploit this vulnerability to execute arbitrary code on the system. IBM has released a fixed for this issue in which the update removes the Apache Log4j from Admin Console and UDDI Registry application. The Log4j security vulnerability is resolved by upgrading WebSphere to 9.0.5.10 or newer versions. If you are running on any 8.0 version of WebSphere then upgrading to 8.5.5.20 or newer version will remedy the issue as well.

 

How to update WebSphere to the current version.

  1. Log into Maximo and go to System Information. Observe the WebSphere version.

ibm maximo system information websphere log4j security vulnerability blog

  1. Next, open the Services application and stop the following WebSphere services: IBM HTTP Server V9.0, IBM WebSphere Application Server V9.0-ctgCellManager01, IBM WebSphere Application Server V9.0-ctgNode01.

ibm maximo security patch log4j update fix

  1. Open the application, “IBM Installation Manager”.

a3j group troubleshooting ibm maximo blog log4j issue update

  1. After IBM Installation Manager opens, Click on “Update”

ibm installation manager update ibm maximo websphere log4j issue

5. Observe to see all of the packages that are available for an update. Click on the checkbox, “Update all packages with recommended updates and recommended fixes”

troubleshoot ibm maximo update websphere log4j issue a3j group

6. Log into your IBM account to download the recommended updates and fixes, then click “Next” after it finishes searching for the updates.

a3j group blog ibm maximo issue fix log4j websphere update

7. Accept the terms in the license agreements to proceed with the update.

ibm maximo patch log4j issue websphere update system

  1. In this view you can observe all of the updates that are going to occur before you click on the “Update” button. Then, click on Update.

a3j group blog patch ibm maximo log4j security vulnerability websphere update

  1. At this point, we have successfully updated WebSphere with all the recommended fixes and updates. Click “Finish”

ibm maximo blog a3j group websphere fix log4j security update

  1. Open the Services application, Start WebSphere back up by starting the following services: IBM HTTP Server V9.0, IBM WebSphere Application Server V9.0-ctgCellManager01, IBM WebSphere Application Server V9.0-ctgNode01.

security patch ibm maximo websphere integration log4j update a3j group blog

  1. Log into Maximo and go to System Information. Observe the new WebSphere version.

ibm maximo websphere integration security patch log4j issue blog update a3j group

Once, you have confirmed that your WebSphere system has been updated, you can rest assured that your Log4J security vulnerability has been remedied. As humans become more involved with technology and dependent on systems to run daily business operations, it is increasingly important to stay mindful of these types of breach opportunities. Emphasizing monitoring and remaining informed on the latest security vulnerabilities is imperative if you want your systems to remain impenetrable. Hopefully, this guide served you well in patching the Log4J security vulnerability! If you would like to receive an email when we post a new blog, subscribe below.

 

 

 

Securing Attachments in IBM Maximo

Need help securing attachments in IBM Maximo?

 

So you have secured your IBM Maximo installation using SSL, perhaps by following one of the secure articles in our A3J Group blog library, and are feeling pretty comfortable that your IBM Maximo users are protected. Just as you are about ready to lean back in your chair and enjoy the fruits of your labor you receive an urgent communication with a screenshot showing an IBM Maximo attachment being served up with the unsecured HTTP rather than HTTPS. Sound familiar? Thankfully you will be back to your feeling of tranquility in no time as this fix is a piece of cake.

*Note you could have been prevented the above scenario from occurring by not binding IBM Maximo to an unsecure port. This would not have allowed the attachment to work but would have prevented an unsecure connection.

Import SSL Certificates into WebSphere Trust Store

Ever tried to connect your Maximo system with an external secured URL? By default, WebSphere is designed not to trust secured external URLs. It will only allow the connection if an administrator specifically instructs WebSphere to do so by importing the certificate into its Trust Store.

Here are some examples of where this may be useful:

  • Connection to a GIS REST service for integrating GIS data with Maximo
  • Connection to a secured Office 365 Email server
  • Connection to a financial system, such as SAP, that uses secured APIs to communicate
  • Connection to an SMS service for texting users when certain system events occur

… and there are many more.

Here is the message you may encounter:


BMXAA1477E - The connection failed to the HTTP handler for the endpoint. Review the error and server log files for information to indicate the cause of the issue, for example, incorrect properties in the DefaultHTTPExit.java handler class. 
com.ibm.jsse2.util.j: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is: 
java.security.cert.CertPathValidatorException: The certificate issued by CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2 is not trusted; internal cause is: 
java.security.cert.CertPathValidatorException: Certificate chaining

Look familiar? Let’s fix it.

  1. Log into WebSphere as an administrative user.
  2. Click on the Security > SSL Certificate and Key Management link in the left navigation pane.
  3. Click on the Related Items > Key stores and certificates link on the right side of the main pane.
  4. Click on the CellDefaultTrustStore item in the table.
  5. Click on the Additional Properties > Signer certificates link on the right side.
  6. Click on the Retrieve from Port button.
  7. Fill out the Host, Port and Alias fields. For example:
    1. Host: www.google.com
    2. Port: 443
    3. Alias: www.google.com

  8. Press the Retrieve signer information button. Ensure that the values seem reasonably correct (i.e. you don’t get an error back.)
  9. Press the OK button.
  10. Click the Save to Master Configuration link.
  11. Press the OK button after the changes have been synchronized with all of the nodes.

At this point you’ll need to restart Maximo, your node agents, and your deployment manager for the changes to take effect. From here forward, Maximo will now trust that URL and allow the connection.

 

Disable Anonymous Integration Access to Maximo

In older versions of Maximo, the product would ship with the ability to process inbound messages through an anonymous super user account when the system was configured to use native Maximo authentication. The user MXINTADM, which comes configured with MAXADMIN privileges when Maximo is installed, would be used as the default account to broker any inbound traffic through the Integration Framework. This made integrating with other systems via Web Services or standard HTTP very easy; simply supply a properly formatted message to the integration framework and you can do just about anything in the system. Common tasks such as creating Service Requests and updating Purchase Order details were very easy to accomplish.

While this method offered ease, it also came with an inherent security risk. Anyone familiar with the Maximo integration framework and its messaging structure could send inbound transactions to Maximo without having to identify themselves. The transaction would show as having been performed as the MXINTADM user in the system.

Luckily, the folks at IBM identified this risk and took steps to ship the product with this feature disabled by default in recent versions. Here is an IBM support article that identifies the security risk and outlines a mitigation procedure:

http://www-01.ibm.com/support/docview.wss?uid=swg21968191

Now, let’s walk through how to check that your environment has anonymous integration access disabled, and how to disable it if necessary.

Maximo System Property: mxe.int.allowdefaultlogin

In Maximo 7.6.0.3 IBM introduced a new System Property called mxe.int.allowdefaultlogin. This property is a boolean value that controls whether anonymous access is allowed. A property value of 1 will allow anonymous access, while a property value of 0 will not. If you are running Maximo 7.6.0.3 or higher and do not have this property, you can add it through the System Properties application.

Maximo EJB Deployment Descriptor

If your environment does not have the mxe.int.allowdefaultogin property, or is at a patch level less than 7.6.0.3, then you must modify the Maximo EJB Deployment Descriptor file to disable anonymous access. This file is located in the following directory (substitute the proper Maximo home directory for C:\IBM\SMP\maximo):

C:\IBM\SMP\maximo\applications\maximo\mboejb\ejbmodule\META-INF\ejb-jar.xml

C:\IBM\SMP\maximo\applications\maximo\mboejb\ejbmodule\META-INF\ejb-jar_notf.xml

Each of these files have 4 instances of the ALLOWDFLTLOGIN environment entry. These descriptors look like:

<env-entry>
  <env-entry-name>ALLOWDFLTLOGIN</env-entry-name>
  <env-entry-type>java.lang.String</env-entry-type>
  <env-entry-value>0</env-entry-value>
</env-entry>

Change the value of 1 to 0 in each of the 4 locations within each file. Then rebuild the MAXIMO.EAR file and re-deploy the file to WebSphere.

Making these changes will force any systems that are integrating with Maximo to supply proper authentication header credentials. In environments that utilize native Maximo security, these means supplying the MAXAUTH header with a Base64 encoded username:password combination.

If you have any trouble, or have questions on how this works, please leave feedback in the comments below.