Re: HTTPS connections

The problem was most likely was just the expired cert. For some reason
sometimes IBM's system will see one, even if it's not related to anything
you're doing, and throw and error. It's really silly.

That's why I encourage my customers to keep an eye on expired certs and CAs
and delete them.

On Fri, Jul 9, 2021 at 2:35 PM Rick Rauterkus <rick.a.rauterkus@xxxxxxxxxx>
wrote:

ok, never mind. He did figure out a way to get rid of the default. He had
an old expired cert in the store yet, so he set that to the default, and
then deleted that cert. That changed the default back to none. And now
the call to the web service is working.

Thanks everybody for your help!


On Fri, Jul 9, 2021 at 2:03 PM Rick Rauterkus <rick.a.rauterkus@xxxxxxxxxx

wrote:

ok, more information.

The call to web service today is being done on a system that will be
retired. It is working there, and using the debug in HTTPAPI we know it

is

not presenting a certificate to the server.

We are trying to set up the call to the web service on a different system
where it will be used once the other system is retired. But we are

having

issues because this system is presenting a certificate when the call is
done.

I don't have access to the DCM on either system, but after talking with
the admins on both I think I found the issue. The old system does not

have

a default certificate specified in the DCM. The new system does, and

that

is the certificate that is being presented. And the admin says there

isn't

a way to set the default back to none. So, hoping somebody might be able
to help with some questions.

Does anyone know if the default certificate can be reset? And how?

If that can't be done, could we set up an application ID in the DCM, not
assign a cert to it, then use that ID in HTTPAPI? Or will it still go

back

to the default since the ID doesn't have one?

Or could we set up a new store? Does each store have it's own default?


On Thu, Jul 1, 2021 at 2:15 PM Brad Stone <bvstone@xxxxxxxxx> wrote:

I've never heard of that before... the system presents a cert as a

client

by default without an application ID.

On Thu, Jul 1, 2021 at 1:17 PM Rick Rauterkus <
rick.a.rauterkus@xxxxxxxxxx>
wrote:

No, we are not using application IDs. We also are not calling

https_init

at all, which if I interpret that correctly is the same as calling it

with

blanks. So I am thinking our admins must have the system configured
somehow that it will present a cert even when we are acting as the

client.

Which is why I am wondering if we can prevent that on a HTTPAPI call.


On Thu, Jul 1, 2021 at 9:27 AM Christopher Bipes <
chris.bipes@xxxxxxxxxxxxxxx> wrote:

Found this in the HTTPAPI example:
If you want to use client certificates, or configure which
certificate authorities your program trusts, you should always
register an application ID, and configure the settings manually
in the Digital Certificate Manager. (Most banks require this!)

If you don't need/want to set up individual settings for the
application, you can pass *BLANKS for the application ID, and
HTTPAPI will use the default settings for a client application
in the *SYSTEM certificate store (as below)

eval rc = https_init(*BLANKS)

Chris Bipes
Director of Information Services
CrossCheck, Inc.


-----Original Message-----
From: Christopher Bipes
Sent: Thursday, July 1, 2021 7:17 AM
To: Midrange Systems Technical Discussion <

midrange-l@xxxxxxxxxxxxxxxxxx

Subject: RE: HTTPS connections

Are you using an APPLICATION_ID in your SSL calls? If so, that is

telling

the software to use an identifying certificate on the SSL

connections.

Do

not use the APPLICATION_ID and see if you can still connect.

Chris Bipes
Director of Information Services
CrossCheck, Inc.

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf

Of

Rick Rauterkus
Sent: Thursday, July 1, 2021 5:24 AM
To: Midrange Systems Technical Discussion <

midrange-l@xxxxxxxxxxxxxxxxxx

Subject: Re: HTTPS connections

The issue is not that we don't trust them. I can connect from my

PC,

but

could not from the IBM i.

The sys admin had me send them our certificate which they imported

into

their system and now we can connect. Their concern though is when

our

certificate expires the connection will be broken again. So they

would

like us to not present a certificate when making the web service

call.

Which Scott seems to be saying is normal.

So the question is, how do we not use a cert when we make the web

service

call? Or maybe the question is why are we presenting a cert when we

are

the client if the default behavior is not to? Is it the way the sys

admin

has something set up? If it is, I'm sure they will be reluctant to

change

it in fear that it would affect something else. Is there a way we

can

force it not to present a cert using HTTPAPI?

Based on the debug logs of other web service calls we do, it looks

like

we

are always presenting a cert. I'm guessing most servers are just

ignoring

it. But for this connection, they have said if a cert is used, they

will

validate it. I guess we have just gotten lucky all these years.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)

mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription

related

questions.

Help support midrange.com by shopping at amazon.com with our

affiliate

link: https://amazon.midrange.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription

related

questions.

Help support midrange.com by shopping at amazon.com with our

affiliate

link: https://amazon.midrange.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription

related

questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com