RE: Client Access, Access Client and certificates

Mike,

There have been several SSL PTFs recently.
These have all been related to disabling SSLv2, SSLv3, and TLSv1.0, only allowing TLSv1.1 or TLSv1.2.
Along with this is disabling SHA1 certs, using new SHA256 certs.
SHA1 certs will be expiring, and will not be able to be renewed.
If the remote device, whether be a desktop or sever, was using one of the older versions and/or certs, and not updated for the new, this would cause a failure.
We also had issues with 3rd party i5 products, still waiting for those TLSv1.1 upgrades..
There are more changes scheduled for 2016.
We were just informed that if our credit card system is running TLSv1.0 on 7/1/2016, credit cards will stop working because the banks will no longer be accepting TLSv1.0.
We are currently awaiting for the TLSv1.1 upgrade from Curbstone.

I now have a SSL socket trace running on a daily basis, monitoring all the SSL versions and certs being used.

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mike Cunningham
Sent: Saturday, December 19, 2015 2:10 PM
To: Midrange Systems Technical Discussion
Subject: RE: Client Access, Access Client and certificates

We install all PTFs every quarter. The old Power 6 box had all PTFs install one month prior to the upgrade to Power 8. Our installer did apply PTFs to the new system after the upgrade to be sure any hardware specific PTFs were applied to the new system. So if the certificate issue was caused by a PTF it was either a very new PTF or a Power 8 hardware specific PTF that did it.

From the desktop side, I agree, Client Access service packs and new versions should have also been getting installed and they were supposed to have been but a bad decision was made by a desktop support person that stopped the update procedure because they could not figure out how to push updates with group policy or with our KACE software deployment. That has now come pack to bite that group since they are the ones who need to visit these 500 clients ________________________________________

From: MIDRANGE-L [midrange-l-bounces@xxxxxxxxxxxx] on behalf of Charles Wilt [charles.wilt@xxxxxxxxx]
Sent: Friday, December 18, 2015 12:30 PM
To: Midrange Systems Technical Discussion
Subject: Re: Client Access, Access Client and certificates

Not terribly rare in my experience.

If you chose not to stay up to date, sooner or later, you're force into updating something. Then you find that in order to update that one little something, you have to update some other stuff first.

I suspect that the POWER6 box was out of date on PTFs...so even though you stayed at the same OS level, your new box used a more up to date version of
the OS. Add in an outdated iAW and there you go.

Personally, I be using this as Exhibit A for staying reasonably current vs the old "if it an't broke..."

Charles

On Fri, Dec 18, 2015 at 11:44 AM, Mike Cunningham <mike.cunningham@xxxxxxx>
wrote:

Well, for one, right now we can even start testing IBM I Access Client
because it will not work with our current certificate setup. And we
can't change the certificate to make Access Client work without
breaking Client Access. So I don't see any other path then to update
all the Client Access versions so we can then install the new
certificate so we can then start testing and finally deploy Access Client and remove Client Access.

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
rob@xxxxxxxxx
Sent: Friday, December 18, 2015 10:04 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: Client Access, Access Client and certificates

<snip>
It looks like the only solution for us is to get around 500 clients
upgraded to the most recent version of Client Access </snip>

No, it freaking isn't!!!! (Sorry, now let me calm down...)

Why are you running a mix of "IBM i Access Client Solutions" and the
deprecated "IBM i Access for Windows"? And why would you go through
the pain of upgrading the deprecated "IBM i Access for Windows" to
some newer patch instead of replacing it with "IBM i Access Client Solutions"?

I think we've covered this replacement in a thread or two recently.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600
Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Mike Cunningham <mike.cunningham@xxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 12/18/2015 09:57 AM
Subject: Client Access, Access Client and certificates
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



Just want to share a situation that we are having related to Client
Access, Access Client and certificates. After upgrading from a Power 6
to a Power 8 system (staying at the same OS level 7.1) we had trouble
using System I Navigator in SSL mode. Client Access Telnet SSL worked
OK but Navigator would not work under SSL. It would work non-SSL. We
also could not get Access Client (new java tool) to connect using SSL.
Even Telnet under Access Client would not work SSL when Client Access
telnet SSL did work. IBM got involved, IBM got Verisign involved.
Traced it back to a G4 Verisign Intermediate certificate. We got a new
G5 certificate from Verisign and applied it. That fixed the problem
with Navigator and with Access Client. But it broke Client Access
telnet SSL for most of the campus. Client Access has to be at certain
patch level of version 7.1 to work with the new G5 Verisign
certificate. We had to remove the G5 cert and go back to the G4 cert
to get our users back on the sy stem. It looks like the only solution
for us is to get around 500 clients upgraded to the most recent
version of Client Access before we can put the
G5 certificate back on so we can again use Navigator under SSL and
start using Access Client.

Mike Cunningham
PA College of Technology
--
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.



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

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

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

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