Application Manager upgrade from V9.1.1 to V9.3.1 using user_keystore files.

[Richard_Blumlein_8490]

Hi everyone

I wonder if you would help me to understand some of the problems I am having with getting the
user_keystore files to work for me. I have read the installation guide section on getting this
setup, but I am not sure what I am doing wrong with the files in place.

I wanted to say that Applications Manager support has been very helpful in the cases I opened.
I thought maybe it would be nice if I could here how other companies are handling this change.

From what I understand these keystore files are required now when you are using Oracle Java levels
like Java 8 201, and higher on the host, and client environments. I found a Broadcom document that
describes the problem with the newer releases of Java. We noticed this in the past on our V9.1.1
systems when users tried to login from there PC's with a Java 8 201, and higher. The solution was
to have them downgrade there Java to a level lower that 201 to get in. We figured when we upgrade
to Applications Manager V9.3.1 there was a fix or workaround. I did not understand the problem
at first, but the support center told me this was all due to the Oracle Java changes that require
these files in place at the higher levels of Java 8 201. I also heard there is now support for
OpenJDK which I wanted to ask some things on.

https://ca-broadcom.wolkenservicedesk.com/external/article?articleId=124912

It took me a little while to understand this, but the installation guide section on setting this
up Step 1 was to create the files. I had to figure out the usage of the keytool command which I
later got working. Since each user site might be different, I was told this is something your site
needs to figure out. I was able to figure it out with help from support.

I recently upgraded our AMUPGD instance from V9.1.1 to V9.3.1. I am using Java 8 131 on our
Oracle Linux hosts, and I have Java 8 151 on my PC. Since these are lower than 201 I figured I would
be ok without the user_keystore files in place yet. I did not know what to expect till I get this
upgraded, and start testing.

I was able to upgrade the master, remote agent, OAE, and Banner solution successfully. To allow me to
login, I had to change the connections.properties file to http, and port 80 which is a concern to my m
anagement. When I try to use https, port 443 I cannot login I get a socket error. For now this is ok
since this is my upgrade instance. In a few weeks I am expected to upgrade my test, and in January prod
instance.

Well I tried to perform testing with the user_keystore files to see how this work. I become the user
the master runs as and ran the keytool. I also ran the java command to encrypt the password into the
master's data directory. This all went well, I can run a keytool list command to the user_keysore.
After I started my instance, I noticed the remote agent did not start, it got the java awapi timeout
error. So I copied the user_keystore files to it's data directory. Low and behold I was able to start the
remote agent. What this tells me is if you create the files on the master, you need them on the remote
agents to match. This is the case whether you are at the newer Java or not.

Well I then tried to login, I could not get in. I got a AwE-5103 network socket error. I select details
and see the PKIX path building failed, unable to valid certification path error. This seems to indicate
it could not find the user_keystore files on my PC. So what I did then was copy the two files
user_keystore, and user_keystore_config to my PC. The documenation says for V9.3.0 you use
"C:\Users\<user id>\.Appworx", and on V9.3.1 you "C:\Users\<user id>\.Appworx\<master name>".

What I did was create a AMUPGD directory under my ".Appworx" with the keystores in them Still, I could
not login. I keep getting the socket error I mentioned. I see the handshake messages in the logs when
I try to connect. I even tried to copy the files to different locations like ".Appworx" directly outside
of the instance directory.

So now I decided to shutdown the instance, and rename the files to ZZZ_user_keystore*, then startup.
Now I am able to login successully. I am thinking I am probably able to do this since we are not at the
documented Java 8 201. But I am only making assumptions on what to expect from these tests.

So now a few thoughts come to mind. What if I was able to use OpenJDK on my Oracle Linux hosts for the
master, and remote agents instead of Oracle Java. Since this is OpenJDK the master, and remote agents
probably don't require the usage of the user_keystore files, but I am not sure???

But then what about the PC clients. Our users will be using the Java on there PC's, and they will most
likely be using Oracle Java (Sun) that will require it to connect to our hosts. I am not a PC expert
but I am thinking this would trigger the need to have these user_keystore files in place on the hosts
for the PC clients connecting in. This is even if I am using OpenJDK on the hosts???

I think this is also a possibily users can use OpenJDK on there PC's instead of the Oracle Sun Java
that would require the user_keystore most likely? This kind of thing is always hard since we have
so many users that have different environments on there PC's.

My PC is running Windows 10. I have Java 8 151 as the Java being used to connect. I want to try using
a newer Java 8 201 or higher to test at some point. I might even try to install a newer Java 8 on the
host to try that out. This is making me wonder if it will still work without the keystore files in place
using a higher level of Java???

I want to see if I can break this and have it force me to use the user_keystore files. I might even try
switching to OpenJDK if this is something worth trying???

When I build the user_keystore files I went in as the user the Appman instance runs under. It used the
Java the appman instance is currently using. If one day we need a newer Java does the user_keystore files
need to be created at the same level as the Java you run the Appman instance under???

Once I get this all figured out, we will need to package up these user_keystore files and push the change
out to our user community that uses our Appman systems.

Thank you for the help, and insite everyone.

Rich

[Phearith Mao]

Hello Rich,

There was some confusion to the changes to 9.3.1 so the documentation was a type for a short period of time and has been fixed. The typo was:

For v9.3.1: Create a C:\Users\<user name>\.AppWorx\<master name> folder for each master in the connections.properties file on each user's client machine where <user name> is the actual user's name and <master name> is the name of the master. Then put copies of the user_keystore and user_keystore_config files for each master the sub-directory for that master. This allows for different keystores to be used on each master.

This has been corrected to say:

For v9.3.1: Create a C:\Users\<user name>\AppWorx\<master name> folder for each master in the connections.properties file on each user's client machine where <user name> is the actual user's name and <master name> is the name of the master. Then put copies of the user_keystore and user_keystore_config files for each master the sub-directory for that master. This allows for different keystores to be used on each master.

The change was to remote the . in the .Appworx. So if you are upgrading to version 9.3.1, you will need to create the following directory to place your user_keystore and user_keystore_config files:

C:\Users\<user name>\AppWorx\<master name>

Regards,
Phearith Mao

[Richard_Blumlein_8490]

Hi everyone,

Phearith, thank you for replying to the thread with this information. I am very glad we got
this to work.

I appreciate all the help you, and the other support people give me.

Thank you very much,

Rich