× 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.




Thanks for the responses....

Scott,

Thanks, and no I don't want to secure all telnet clients. I didn't think this was necessary but I just wanted to make sure. We have one or two users external to the LAN we may want to secure, and possibly system administrators/DBAs, but definitely not everyone.

Just to clarify your final statement, is the QIBM_QTV_TELNET_CLIENT application only for telnet from another system? In other words, does Client Access use this? And no, we wouldn't want to secure telnet from another system, the only traffic using this is from other LPARs on the same system and is all over the internal VLAN anyway.

Chris,

I already had both of those settings (secure and non-secure on the server properties and client authentication required No), so that's not the problem. I may raise a PMR with IBM I think.

One final question for everyone on the list....

Is the Telnet server the only one I need to apply the certificate to? Is it necessary to also secure the Signon server for example?

Thanks

Adam Driver
IBM Certified Systems Administrator - System i
Consultant - Infrastructure Technician
Exacta Corporation
608.661.6697 ext 2581
adriver@xxxxxxxxxxxx<mailto:adriver@xxxxxxxxxxxx>
Please consider your environmental responsibility before printing this e-mail.


date: Wed, 09 Nov 2011 16:33:01 -0600

from: Scott Klement <midrange-l@xxxxxxxxxxxxxxxx<mailto:midrange-l@xxxxxxxxxxxxxxxx>>

subject: Re: Telnet SSL question



Hello,





Anyway, I guess my question is do I need to secure the client side?





You don't _have_ to do. The question is whether you want the added security of client authentication. In my experience, 90% of SSL telnet installations do NOT use client certificates.



That is, can I just do what I've done above, allow the Telnet server

to start both secure and non-secure and then control which users use

SSL by the relevant configuration setting on the 5250 session





The "secure and non-secure" is not related to client-side certificates.

It's talking about SSL connections vs. non-SSL connections.



If you allow non-secure connects, then users with no SSL at all will be able to connect. Anything they send over the wire may be viewed by sniffing the Internet connection. Is that what you want? Personally, I only allow non-SSL from the local network. Remote users must use SSL (or a VPN, or SSH)





or do I also have to secure the QIBM_QTV_TELNET_CLIENT side with the

certificate and generate a user certificate?





Err... are you using the telnet client? (The TELNET or STRTCPTELN

command). If so, do you want it to be secured?





------------------------------



message: 2

date: Wed, 9 Nov 2011 22:49:02 +0000

from: Chris Bipes <chris.bipes@xxxxxxxxxxxxxxx<mailto:chris.bipes@xxxxxxxxxxxxxxx>>

subject: RE: Telnet SSL question



You have client authentication turned on. Turn if off at the server.



iSeries navigator / Network / Servers / select telnet and click on properties.



Make sure both secure and non-secure is selected



Then make sure you are not requiring client authentication.



More Info: https://www-304.ibm.com/support/docview.wss?uid=nas108194148dc7aa44286256e1b0071b1cf





--

Chris Bipes

Director of Information Services

CrossCheck, Inc.



707.665.2100, ext. 1102 - 707.793.5700 FAX chris.bipes@xxxxxxxxxxxxxxx<mailto:chris.bipes@xxxxxxxxxxxxxxx> www.cross-check.com<http://www.cross-check.com>



[Like us on Facebook!]<http://on.fb.me/t7A5KE>

- WEA Trust Confidentiality Notice -

This electronic mail message and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. Dissemination, forwarding, printing, or copying of this electronic mail without the consent of the sender is strictly prohibited. If you are not the intended recipient or the person responsible for delivering the electronic mail to the intended recipient, be advised that you have received this electronic mail in error; please immediately notify the sender by return mail.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.