On 5/18/23 1:57 PM, Thomas Hoffmann (Speed4Trade GmbH) wrote:
So the error is raised not by tomcat but by the ibm JDK.
Yes. The results reported in my latest email say as much.
Those results also say that there's something different -- radically
different, judging from the amount of red that showed up in Hex Fiend --
between a keystore signed and chained on my new M2 Mac Mini, and a
keystore signed and chained on my old 2017 iMac, both starting from the
same original keystore, and the same CA certs, using the same version of
KeyStore Explorer.
Just now, I thought I'd found something: I thought maybe it was the
"Zulu-8" ARM-native Java 8 JVM that is currently the default on the M2
Mini. I temporarily pulled Zulu-8 out, forcing KeyStore Explorer to run
under an Intel-native JVM. I tried signing and chaining the keystore,
putting it on the customer box, and doing a keytool -list -v on it. It
liked it. No out-of-memory, no excessive (and maddeningly unspecified)
chain length. And I was immediately certain that it was the Zulu-8.
But then I tried putting Zulu-8 back in, and doing the sign-and-chain
operation under it. And it passed the keytool test just fine. Twice,
with a reboot of my Mini in between.
Just for grins, I also ran the keytool test on all five keystore
versions on our cloud AS/400 (where it would NOT be good to shut down
the Tomcat server). There, too, the *only* one that failed was the one
that failed on the customer box. I did, however, notice something else:
all five of them are 5486 bytes long at this end. As is the one that I
sent back from the customer box. And all of the ones that worked
properly are 5486 bytes as received on both remote AS/400s. But the bad
one was 5515 bytes long as received on both remote AS/400s!
I'm sorely tempted to fire up the local AS/400 I was using earlier
today, AGAIN!, and see how big it was, as received (being transferred
directly, rather than through a private FTP server).
At this point, I'm calling it a fluke. Some freak glitch with that
specific sign-and-chain operation, that caused AS/400s to not like it.
Unless somebody else has a better explanation.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
