× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Correct me if I'm wrong, but Java apps don't use DCM, don't use the system store, and have their own key store.

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of James H. H. Lampert
Sent: Monday, February 01, 2016 3:46 PM
To: Midrange Systems Technical Discussion
Subject: 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


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.