On 4/5/23 1:36 PM, Patrik Schindler wrote:
From the messages provided, I'd say that telnet is trying to
authenticate with certificate/key against the remote IBM i, which
fails because it has not been set up. I think that's not what you had
in mind, instead just using a secure comms channel.
I've managed to get to a proof-of-concept on this.
First, if there's a way to set up the native Telnet client to do secured
Telnet in "privacy only" mode, I have no idea how, or where (as opposed
to the native Telnet server, where there is a setting for turning client
authentication on or off).
I once again tried connecting our V7 cloud box to our V6 box, after
installing the V6 box's private CA in its system store (in the process
discovering that doing so automatically adds it to the trust list for
the Telnet client), and found out that they had no protocols in common.
Dead end there.
Then I signed on to Pub400, and *HIT THE JACKPOT*
Not only did it have secured Telnet enabled; its root certificate was
*NOT* in our V7 box's trust list (giving me a "not signed by a trusted
CA" message), but *IS* the same as the root certificate in their web
site's chain. So I saved the root cert from my browser, and added it to
the system store (again automatically showing up in the TN client trust
list), tried another secured TN connection to Pub400, and IT WORKED!
So we will definitely be able to get a secured TN connection from our V7
box to any other box we're authorized to access, so long as (1) it has
at least one protocol in common with the V7 box, (2) it has a secured TN
server running, and (3) if the root cert isn't already in the trust
list, we can get it there.
--
JHHL
midrange.com
