Alexey,
I have quite long history with Maximo but my experiences with these *.key files are as old as one day ;-)
I have never seen any piece of documentation about this myself, therefore whatever I say further down is based on experimenting and yet, it still covers only a fraction of the full picture.
It looks like MXServer during boot time scans for *.class, *.license and *.key files located under psdi/app/signature/apps/ package and deciphers them using psdi.util.MXCipher but it doesn't use CRYPTO/CRYPTOX keys that are environment specific as of MAS Manage, but rather uses static set of keys.
Decryption result is expected to be of type String and contain comma-separated entries. I will not get into more details as I'm not 100% sure about that, but what I'm sure of is that entries other than ISPERMANENT, EVALUATION, MAXIMOPRODUCT, TIVOLIPRODUCT, LICENSEKEY, PRODUCTKEY and FORINTERNALUSEONLY are considered as valid application names. Therefore the STLABEL.key file contains STLABEL, as it's the internal name of the custom Label Configuration application.
Why is all that? Apparently Maximo/MAS Manage by default filters out applications which haven't been created as clones of one of standard apps (MAXAPPS.ORIGINALAPP is NULL) and are not in the list of valid application names. Having said, since STLABEL application is being created as "standalone" (without any original app reference, see V1000_02.dbc), therefore valid *.key file need to be provided in order to enable this custom application.
You may ask: why don't I need any *.key file when creating completely new application directly in Maximo using Application Designer?
The answer is quite simple - whenever you create application using Application Designer then MAXAPPS.ORIGINALAPP is set either to the name of the app which you're cloning or to CUSTAPP, in case you're adding brand new custom application.
Just by looking at this case we might have fixed the problem by providing re-encrypted STLABEL.key file or simply removing the STLABEL.key file and running following update statement:
update maxapps set originalapp = 'CUSTAPP' where app = 'STLABEL';
I hope that helps. I must admit that it's been really interesting challenge!
------------------------------
Andrzej Więcław
Maximo Technical Consultant
AFRY
Wrocław, Poland
------------------------------
Original Message:
Sent: Tue October 01, 2024 12:33 AM
From: Alexey Potanin
Subject: MAS 9 - zebra-label - BadPaddingException
guys (@Andrzej Więcław and @Jason VenHuizen), can you please explain the purpose of the STLABEL.key file?
I've never seen this solution and would be glad to learn about it.
Thank you in advance!
------------------------------
Alexey Potanin
Original Message:
Sent: Mon September 30, 2024 04:47 PM
From: Andrzej Więcław
Subject: MAS 9 - zebra-label - BadPaddingException
Hi Alexey,
I'm sorry, I indeed missed the fact that the error is being reported in runtime, rather than during the build process.
I must admit that have never used this Sharptree's product but I did some investigations during the day and this is what I came up with.
The long story short - you cannot use Github release archive directly with MAS Manage, but you should rather build your own customization archive, first adjusting few things.
First of all it looks like Github repository contains STLABEL.key which is required by Maximo framework to load STLABEL custom application. This file contains STLABEL, value encrypted using Maximo 7.6.1.x version of the psdi.util.MXCipher utility. The thing is that it looks like static encryption keys (don't mix them with MAS Manage CRYPTO/CRYPTOX keys used to encrypt database values like I originally suggested) have been changed between Maximo 7.6.1.x and MAS Manage 8+ and therefore STLABEL.key cannot be properly deciphered by MAS Manage during boot time. The trick here is to cipher STLABEL, value using MAS Manage version of the psdi.util.MXCipherX.encData(String) method and save result to file. Please check whether attached STLABEL.txt works for you. After downloading simply rename it to STLABEL.key and replace the file located under <repo-root>/src/main/dist/applications/maximo/businessobjects/classes/psdi/app/signature/apps.
Secondly, it looks like this Zebra Label extension package out of the box it supports single all server bundle deployment (ref. adjustments to the maximo-all.xml and maximouiweb web.xml files). If you're running any other server bundle types (ui, mea, cron, report) then you need to add buildmaximoui-war.xml, buildmaximomea-ear.xml, buildmaximocron-war.xml, buildmaximoreport-war.xml under <repo-root>/src/main/dist/deployment/was-liberty-default and adjust them in a similar manner like @Jason VenHuizen did that with maximo-all.xml. To understand what changes are required I highly recommend you to extract your current maximo-all.xml file from the maxinst POD and compare it with the Github version of the same file.
Furthermore for each server bundle type you need to update maximouiweb module's web.xml files located under /opt/IBM/SMP/maximo/deployment/was-liberty-default/config-deployment-descriptors/[maximo-all|maximo-ui|etc.] directories and include the same changes as were applied to the web.xml in the Github repository (same comparison procedure as with maximo-all.xml).
It sounds like a lot but I believe it's still worth all great @Jason VenHuizen's and Sharptree's work. I tried it in my MAS Manage environment and I succeeded installing and running Zebra Label extension. I guess up to some point mentioned changes can be turned into the code and included in the Github repository, especially generating STLABEL.key file dynamically. With all those XML files it's not so easy though as they evolve frequently. I can imagine though implementing a kind of build time hook, similar to the one I described in my LinkedIn article IBM MAS Manage - Automatic Root Context Redirect (ref. MAS Manage Build Time Hook section) which would adjust XML files during container image build process and therefore relax dependency on keeping copies of specific MAS Manage version XML files which need to be updated
------------------------------
Andrzej Więcław
Maximo Technical Consultant
AFRY
Wrocław, Poland
Original Message:
Sent: Mon September 30, 2024 02:27 AM
From: Alexey Potanin
Subject: MAS 9 - zebra-label - BadPaddingException
Hi Andrzey,
I believe V9000-127 is just a version of MAS or Manage. We are subscribed to the latest release channel, so it must be it.
I followed the instruction here: https://github.com/sharptree/zebra-label/tree/main?tab=readme-ov-file
Build was fine, no issues. UpdateDB run fine, no issue.
But when one of the server bundles start it fails with this error.
------------------------------
Alexey Potanin
Original Message:
Sent: Mon September 30, 2024 02:11 AM
From: Andrzej Więcław
Subject: MAS 9 - zebra-label - BadPaddingException
Hi Alexey,
it sounds like some kind of incompatibility of your CRYPTO/CRYPTOX keys that your'e experiencing.
I quickly reviewed zebra-label-1.1.2.zip package content and I can't see any script called V9000-127.* there. It's quite hard then to point out what might be the other cause.
Could you please provide wider context of the error so that we can see what product scripts are actually being executed when this error occurs?
Did you by any chance did any other change in this environment?
------------------------------
Andrzej Więcław
Maximo Technical Consultant
AFRY
Wrocław, Poland
Original Message:
Sent: Sun September 29, 2024 11:35 PM
From: Alexey Potanin
Subject: MAS 9 - zebra-label - BadPaddingException
Hi guys,
I am trying to deploy zebra-label solution (version zebra-label-1.1.2.zip) to MAS 9.0.
After updating the configuration masinst pod would finish fine and build of ui, mea, cron, report images would be done successfully.
Unfortunately Manage would be not working. Checking logs of the ui pod shows following error (full stack is below):
[err] javax.crypto.BadPaddingException: Given final block not properly padded. Such issues can arise if a bad key is used during decryption.
I tried:
- download zip file to my local server and point the customization to it
- Point directly to zebra-label-1.1.2.zip at the github
- Used version 1.1.0
No issues with the build but it fails on the ui start :( Nothing helped.
30 Sep 2024 03:17:19:015 [INFO ] [maximo] BMXAA6453I - The server is connecting to database version: V9000-127
[err] javax.crypto.BadPaddingException: Given final block not properly padded. Such issues can arise if a bad key is used during decryption.
[err] at java.base/com.sun.crypto.provider.CipherCore.unpad(CipherCore.java:1065)
[err] at java.base/com.sun.crypto.provider.CipherCore.fillOutputBuffer(CipherCore.java:1145)
[err] at java.base/com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:919)
[err] at java.base/com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:446)
[err] at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2202)
[err] at psdi.util.MXCipher.decData(MXCipher.java:293)
[err] at psdi.server.MXServer.getPkgFromJar(MXServer.java:2251)
[err] at psdi.server.MXServer.packagingCheck(MXServer.java:1867)
[err] at psdi.server.MXServer.boot(MXServer.java:1685)
[err] at psdi.server.MXServer.start(MXServer.java:3905)
[err] at psdi.servlet.MAXIMOStartupServlet.init(MAXIMOStartupServlet.java:116)
[err] at com.ibm.ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:301)
[err] at [internal classes]
[err] at com.ibm.ws.webcontainer.osgi.WebContainer.access$100(WebContainer.java:113)
[err] at com.ibm.ws.webcontainer.osgi.WebContainer$3.run(WebContainer.java:996)
[err] at [internal classes]
[err] at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
[err] at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
[err] at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[err] at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[err] at java.base/java.lang.Thread.run(Thread.java:839)
Would much appreciate your help!
------------------------------
Alexey Potanin
------------------------------