RE: SSL and iSeries as a consumer of a web service on a PC workstation

Well if you are programming at a low level, not using some packaged
HTTPAPI call, you can test or ignore the certificate information. It is
usually programmed to verify the CERT against the URL and follow the
chain up to the CA. But you do not have to do all that work if you are
doing your own low level secure socket communications. Find and
download LIBHTTP. It holds many examples. (I took a short cut and
purchased GETURI which does the same thing but in a single API or
Command.)

Chris Bipes
Director of Information Services
CrossCheck, Inc.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of John Duenweg
Sent: Friday, April 23, 2010 7:16 AM
To: midrange-l@xxxxxxxxxxxx
Subject: SSL and iSeries as a consumer of a web service on a PC
workstation

I have a question about the options that exist when the iSeries is
establishing an *SSL connection* to a PC workstation acting as a server.



This scenario occurs when the iSeries is operating as a client and the
destination is a workstation that operates as the web-server.



The only caveat regarding this scenario that is different than with a
standard call via SSL is that the destination *may not* have a correct
digital certificate for itself. The destination *may* have a digital
certificate where the *name* of certificate *does not match* the name of
the
machine.



These are the things that we may know about the destination and the
digital
certificate returned:

* The name of the machine may be: workstation4.myurl.com.... or
the
name may not be known.

* The machine could be called based on an IP address.

* The name of the digital certificate returned by the
destination
may be: application.certname.com

* The iSeries can determine that the digital certificate is my
digital certificate



*What I would like to happen:*
* The iSeries operates as a client and calls the workstation
* The iSeries may call the workstation using the ip address and
not
a name. example: https://192.168.1.12/remote_service

* The workstation will return a digital certificate that was
generated by us.

* The digital certificate may have a 'generic' name... such as:
CN="
application.certname.com"

* The iSeries (during the setup of the SSL connection) is OK
with
the digital certificate, even though the name (CN) doesn't match the
name
that was used to call the workstation.

* The SSL connection is established and everyone is happy.
(Subsequently, the data passed on the connection is encrypted just like
any
normal SSL connection.)