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



Charles,

If you truely are using a client certificate you do this all in the Digital
Certificate Mananger (DCM). You can get there through the ADMIN HTTP
server (port 2001). Look around in there and it will make more sense.

Import the client certificate, then apply an application ID to it. Then on
your HTTP call you need to be sure to use the same application ID so that
it knows which client certificate to use.

But, I will say this. I would double check if you really need to use a
client certificate or if you're just making an HTTPS call that only
requires the CAs be installed in the *SYSTEM store.

I've worked with thousands of clients with projects like this (using our
GETURI product) and only 1 that I know of in 15 years used a client
certificate (and it didn't work because the SSL APIs had a bug because it
had never been truely tested... of course they did offer a PTF once we
worked through it).

SSL is confusing, yes, but rarely do I see client certificates in use.

Brad
www.bvstools.com


On Tue, Sep 10, 2013 at 8:45 AM, Versfelt, Charles <CVERSFELT@xxxxxxxxx>wrote:

Sorry about my last message, I forgot to change the subject line.

Scott,

Thank you very much for your help. I have a question... please forgive my
lack of knowledge on this, this is all very new to me.

When you say "create a NEW application ID" and "load the application
certificate (as a client certificate) directly into that new profile" I
don't know how to do this. Is this done in Certificate Manager? I may need
to have our VP of Operations do this step as well, but I will need to tell
him how.

The https_init part I think I can handle, of course, that's the easy part.

Thanks,
Charlie

----------------------------------------------------------------------
date: Fri, 06 Sep 2013 14:59:44 -0400
from: Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>
subject: Re: Certificate authentication through HTTPS

The error you posted explicitly means that it couldn't find a matching CA
certificate, so the root/intermediate certs are almost certainly the
problem.

You can't load CA certificates into a particular application (like FTP,
Telnet, SMTP, etc). So I guess I don't understand your question about "how
should he load them". He should load them as CA certificates, not
application certificates. Load the root one first, then the intermediate.

Once he has those loaded, you should create a NEW application ID (do not
use one of the existing ones) named for YOUR application. Maybe something
like MYRON_HTTPS or something... Whatever you want to call it, but I
strongly recommend starting it with your company name so that it does not
conflict with other company's certs. Then load the application certificate
(as a client certificate) directly into that new profile.

Then, use https_init('MYRON_HTTPS') in your RPG program that uses HTTPAPI
so it knows which DCM profile to use.


On 9/6/2013 1:52 PM, Versfelt, Charles wrote:
Hi,

I need to send a CSV through HTTPS from the iSeries, I don't think this
matters to my question but I plan to use HTTPAPI's http_url_post_stmf, I
know that's a topic for a different newsgroup.

The client uses Certificate authentication. The certificate they
provided was a .p12 extension. We have done certificate authentication from
the iSeries in the past, but only with FTP. No one here has much
experience with it. I have none.

We have two technical hurdles I hope someone can help with:

1.) Our Operations VP attempted to load the .p12 Certificate. He
received an error in Work with CA certificates: An error occurred during
certificate validation. The issuer of the certificate may not be in the
certificate store or the issuer may not be enabled.

Both the client and IBM told us we need the Root and Intermediate
certificates. The client provided them, and the VP loaded them. When he
tried to load the .p12 Certificate, the same error reoccurred.

I don't know if the message reoccurrence is related to the second
question. If the Root/Intermediate certificates were loaded incorrectly I
imagine it could cause the problem to continue.

2) The Operations VP incorrectly assumed I was doing FTP and used that
option to load the Certificates. When I told him I was transferring through
HTTPS he told me that's not one of his options in Digital Certificate
Manager. He gave me a print screen that included:
IBM Directory Server publishing
IBM Directory Server client
IBM I TCP/IP FTP Client
IBM I TCP/IP Telnet Client
SNDTWEET by Kisco
IBM I TCP/IP SMTP Client

How should he load the certificates for transferring from the iSeries
via HTTPS?

Might loading those Root/Intermediate certificates with the correct
method for HTTPS usage correct our initial problem of loading the .p12 file?

Any insight I can get on this is much appreciated!

Thanks,
Charlie V.
Myron

This email message has been delivered safely and archived online by
Mimecast. For more information please visit http://www.mimecast.com


This email message has been delivered safely and archived online by
Mimecast. For more information please visit http://www.mimecast.com

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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.