Secure Telnet problem, was Re: Restarting Telnet

I was able to find Network/Servers in "IBM Systems Director Navigator for i5/OS" and successfully stop and restart Telnet from there.

As a backup, I also had iNav and a LAN Console terminal session open. And I was relieved to be able to monitor the process from the LAN Console terminal session.

Here is why I'm even doing this exercise:

It seems that if our Java-based TN5250e client runs in SSL mode under the most recent releases of Java, it throws a "Certificates does not conform to algorithm constraints" [sic] error, and refuses to connect.

According to some research a colleague did, it's because Java doesn't like the key length.

There is no way in Hell that I'm going to do anything to reproduce the problem from my desktop; being able to open secured TN5250 sessions to any reachable box on a moment's notice is too mission-critical. Fortunately, a colleague can reproduce it readily from his desk.

Up until I changed the certificate, our Telnet server was running a keylength 1024 certificate, signed by the internal CA. The new one is keylength 2048. And the current JRE still doesn't like it.

I don't know anything about the server certificate other than what's shown in DCM "View Certificate." It tells me that it's keylength 2048, but it doesn't tell me whether it's running an algorithm that Java no longer supports. The Admin HTTP server is apparently on an IBM-supplied certificate for its secured ports, because if I click the padlock in my browser on Systems Director, it shows a certificate entirely different from anything I've created. Likewise, the only other secured web server running on the box is a Tomcat server, which of course is running SSL out of a Java keystore, rather than anything that goes through DCM.

If I do a "View Certificate" on the internal CA's certificate, IT is still keylength 1024; could that be what's killing Java SSL?

--
James H. H. Lampert