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


  1.  Home
  2. MIDRANGE-L
  3. July 2021

Re: HTTPS connections

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



As an Amazon Associate we earn from qualifying purchases.

This thread ...
Follow-Ups:
Replies:
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.