Re: cert from webservice

["Jay Peasley" <jpeasley@xxxxxxxxxxx>]

Sender: "Jay Peasley" <jpeasley@xxxxxxxxxxx>

Scott,

Thanks for the reply.

Oddly enough I was able to import their cert, despite the fact that it was
self signed. The CN = XXXXXX XXXX/emailaddress=XXXXX@xxxxxxxx, the O is the
company name and the L,ST and C are the city state and country,
respectively.

Now I had loaded their cert(s) from their website(s) prior to loading in
this cert, which they claim is the merchant (client?) certificate.

Though I am no SSL expert, I believe I understand what you are saying and a
CA cert cannot be a Server cert. That does makes sense. I am wondering if
their mercahnt cert is really a user cert in iSeries terms. I have setup
user certs before for iSeries Access, but I believe the iSeries generates
them.

But back to your last statement, if the client certificate is installed I
will be able to assign it to my application. How does one do that?

Thanks,

Jay

----- Original Message ----- 
From: "Scott Klement" <sk@xxxxxxxxxxxxxxxx>
To: <ftpapi@xxxxxxxxxxxxx>
Sent: Wednesday, November 16, 2005 7:24 PM
Subject: Re: cert from webservice


> Sender: Scott Klement <sk@xxxxxxxxxxxxxxxx>
>
>
> > When I imported the certificate DCM placed it as a CA cert, though I was
in
> > manage client applications at the time. When I try to update the
certificate
> > assignment for a client application, the list of available certificates
are
> > ones specific to the iSeries and not from any CA.
>
> CA certificates can't be used as client certificates.  They are two
> different things that serve two different purposes.
>
> When you connect with SSL, a certificate is sent from the server to your
> computer. It's purpose is to let your program know that the bank is really
> who it claims to be.  No imposter has usurped your network connection or
> anything like that -- it's REALLY the bank.
>
> So it receives this wonderful cryptographic certificate from the bank's
> server. We'll call it the "server certificate".
>
> How does it know that this server certificate is valid? It looks very
> nice, but how can you be sure that it's a real one?   The answer is... you
> compare it against a CA certificate.  There are cryptographic checks that
> can be done to be absolutely sure that the server cert was created by the
> CA that's listed in the CA certificate.  If you trust the CA, you'll know
> that the server really is who it claims to be, because otherwise the CA
> wouldn't have cryptographically signed it.
>
> So that's what the CA is for...   how about a client certificate?
>
> Well... after you've verified that the bank is really who you think it is,
> what happens if the bank wants to do the same thing to you?  It wants you
> to send a certificate and then it needs to be able to check if you are
> really you. That's what client certificates are for.  Your program sends
> them a client certificate, and the bank checks it against CA certs that
> they already have installed on their system to see if you're really you.
>
> Client certificates are used in less than 2% of the SSL transactions
> happening today.  Server certificates and CA certificates are used in 100%
> of all SSL transactions.
>
>
> > YourPay is sending us a self signed cert that they want to be sent with
the
> > SSL transaction, not a cert signed by a CA for the server. If http-api
uses
> > DCM to get the cert and I can't specify a CA cert for a client
application,
> > then I am kinda stuck.
>
> They're sending you a self-signed certificate.  That means you NEED a CA
> certificate from them.
>
> When you use a certificate that's signed by a big name certificate
> authority like VeriSign or Thawte, the system downloads the certificate
> and compares it (cryptographically) against the CA certificate that it was
> signed by.  VeriSign and Thawte's CA certificates are included in the DCM
> when you install it, so it'll work.
>
> When a certificate is self-signed, that means that they created their own
> certificate authority instead of using one of the established ones like
> VeriSign.  Consequently, you don't have their CA certificate on your
> system.  That means that the DCM won't trust their server certificate, and
> won't allow you to connect.
>
> And that's why you need their CA certificate.  Once installed, and marked
> as "trusted" for your application, It'll be able to successfully verify
> the certificate, and therefore will allow certificates signed by YourPay
> as well as those signed by VeriSign or Thawte.
>
> Once again, this is still all processing the server certificate.  It has
> nothing to do wiht a client certificate.
>
>
> You can't use a CA certificate as a client cert. They aren't the same
> thing, and they don't work the same way.  No Java wrapper will change
> that.
>
> If YourPay does require a client certificate, they'll have to send you
> that in addition to the CA certifificate.  (You have to install the CA
> certificate first, or the iSeries won't even allow you to install the
> client certificate, because it won't be trusted.)
>
> Once the client certificate is installed, you'll be able to assign it to
> your application.
>
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list.  To unsubsribe from the list send mail
> to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
> -----------------------------------------------------------------------
>


-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------