You don't assign certificates to client applications unless it's
specifically a requirement.
Most certificates are assigned to server applications (HTTP, etc).
On Tue, Oct 4, 2022 at 11:05 AM James H. H. Lampert via MIDRANGE-L <
On 10/4/22 5:43 AM, Brad Stone wrote:
You don't need to create a local certificate. Just create the *SYSTEM
Dear Brad, et al.:
"Just create the *SYSTEM store"?
If I look at the *SYSTEM store, all I see is:
Expires in 7299 days
ECDSA (256 bits)
Certificate Authority (Enabled)
and if I go to "Manage Application Definitions" (something I definitely
remember from the old V6 and V4 DCMs), I see a box for
IBM i TCP/IP Telnet Server
No certificates assigned
If I click "View" on that box, I see "None assigned" under Assigned
Certificates, and if I click "Assign Certificates," nothing is listed to
assign. Is an empty *SYSTEM store really all I need now, for secured
Telnet? No assignments?
Also, as I recall, bringing up the Telnet server in Secured mode
requires cycling that server, varying it off and back on. Is that still
true? It's easy enough to do when you also have a physical terminal on a
Twinax line, and I vaguely recall using it through the separate system
console Ethernet port on our E4A, but how do I do this without physical
access? Through iNav?
And what about the other thing we need, enabling HTTPS support in Scott
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
Help support midrange.com by shopping at amazon.com with our affiliate
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.