[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Client Certificates



Hi Ron,

SSL "handshaking" (trading parameters to established an encrypted 
session) involves up to 4 different certificates:

1) There's *always* a server certificate assigned to the server 
application.  This is sent to the client that connects.

2) There's almost always a CA certificate.  This is the certificate of 
the entity that digitally "signed" the server certificate.  The idea is 
that the CA (certificate authority) "vouches" for the server.  Example: 
If VeriSign says that ibm.com is really International Business Machines, 
then I can believe them because I trust VeriSign.

So the client takes the server's certificate and verifies 
(cryptographically) that it was really created by a CA certificate that 
it trusts.  If the server certificate really was signed by a trusted CA 
certificate, then the client knows it's connected to a legitimate server.

3) The client certificate.   After the server certificate has been 
verified, the server can OPTIONALLY ask the client to submit a 
certificate identifying itself.  This way the server can determine that 
it trusts the client (just as the client has already determined that it 
trusts the server).

In SSL, client certificates are optional, but they are certainly available.

4) Another CA certificate, this one on the server's side, to validate 
the (optional) client certificate.


The steps I provided you before are for assigning a CLIENT certificate 
(#3, above) which sounds like what you are asking for.

Despite my telling you that this is what these instructions are for, you 
seem to want to believe that my instructions tell you how to install a 
CA certificate.  That's NOT what my instructions do.  My instructions 
tell you how to install a client certificate.




Ron wrote:
> What I am thinking is this authenticates the Server to our Client
> Application. Now we know that this is the correct server that we are
> connecting to.
> 
> What I am wanting to do here comes when the Server wants to Authenticate all
> the Client's connecting.
> 
> To do this in our other software we generally either get a Private Key from
> the Company hosting the Server or create a private Key at the client
> location. Then create and export a public Certificate created from this
> private key. Then either self sign the certificate or send the certificate
> to a company like VeriSign to have it signed. Then send the Certificate to
> the company hosting the Server.
> 
> The Server uses this Certificate as part of the Client Authentication.
> 
> This is the part I am trying to figure out using the DCM. I know the DCM
> uses User Certificates for this process, but we would like to allow one
> Certificate for anyone who signs on.
> 
> I hope this explains it correctly and that I am understanding this
> correctly.
> 
> Thanks again for all your help
> 
> Ron
> 
> 
> 
> 
> 
> -----Original Message-----
> From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
> [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klement
> Sent: Saturday, October 31, 2009 3:19 AM
> To: HTTPAPI and FTPAPI Projects
> Subject: Re: Client Certificates
> 
> I've just told you how it's handled.  Please read my steps again.
> 
> 
> Ron wrote:
>> I have used the method you showed below when I want to verify the server I
>> am connecting to.
>> I need to verify their Server Certificate.
>> To do this I have been following the process you have stated below.
>>
>> But now if I want to send a client certificate to the Server so they know
> I
>> am who I say I am.
>>
>> How is that handled?
>>
>> Thanks
>>
>> Ron
>>   
>>
>> -----Original Message-----
>> From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
>> [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klement
>> Sent: Friday, October 30, 2009 4:46 PM
>> To: HTTPAPI and FTPAPI Projects
>> Subject: Re: Client Certificates
>>
>> Hi Ron,
>>
>>> In HTTPAPI I see where to put in the application tied to the server
>>> certificate   https_init('SERVERCERT');
>>> But I do not see the place to add in the client application that we want
>> to
>>> use for the client certificate
>> The SSL code isn't a part of HTTPAPI.  It's part of OS/400. I think it's 
>> critical to realize this, because you seem to be looking for an option 
>> in HTTPAPI to set a certificate.  That's not how it works.  You have to 
>> tell OS/400 to set a certificate.
>>
>> OS/400 has a tool called the Digital Certificate Manager (DCM) where you 
>> can manage applications, assign the SSL settings appropriate for that 
>> application, and so on and so forth.
>>
>> So, the first issue is to set up your application in the DCM.  Setting 
>> it up makes it possible to assign settings to it, including assigning a 
>> certificate to it.  This is a critical step.
>>
>> They keep changing the interface for the DCM, so I'll tell you the steps 
>> on my V5R4 system, and hopefully you can extrapolate what they should be 
>> on another release...
>>
>> Keep in mind that this is part of IBM i (OS/400) and not part of 
>> HTTPAPI, I provide instructions to help you out, but there may very well 
>> be better ones in the Information Center?
>> -----------------------------------------------------------------------
>> a) If necessary, start the *ADMIN instance of the HTTP server.
>>
>> b) Log in to the *ADMIN instance of the HTTP server
>>
>> c) Click "Digital Certificate Manager"
>>
>> d) Click "Select Certificate Store"
>>
>> e) Choose the *SYSTEM certificate store, and click "continue"
>>
>> f) enter the *SYSTEM certificate store password, and click "continue"
>>
>> g) In the pane on the left, expand "Manage Applications"
>>
>> h) Choose "Add Application"
>>
>> i) Choose "Client", then "continue"
>>
>> j) You should now be on the screen where you can setup an application. 
>> Here are details of this step:
>>
>> Application ID:
>>
>> IBM recommends that it start with something to identify the company 
>> (they use QIBM, and ask that you do not use that!)  followed by the name 
>> of the software package, followed by the name of the component. What you 
>> name it is up to you.  I might put something like this:
>>
>>     KLEMENTS_GIFTBOX_UPSTRACK
>>
>> That would be a name I'd use for the UPSTRACK component of the Giftbox 
>> software provided by Klement's Sausage.  Yours might be something like:
>>
>>     LINOMA_CRYPTOCOMPLETE_SENDTOWEB
>>
>> This is just to give you the idea.  It can be anything you like, up to 
>> 100 characters.  You can click the help button (upper-right) to see 
>> IBM's help file that explains what characters are allowed in this field. 
>>   It should be one word (no spaces) and can be up to 100 characters long.
>>
>> Exit program info:
>>
>> I always take the default, because I don't use an exit program when my 
>> cerificates are changed. So just take the default here, unless you want 
>> to use this feature.  (HTTPAPI doesn't care)
>>
>> Application user profile:
>>
>> I've never used this feature... just take the default.
>>
>>
>> Define the CA trust list:
>>
>> This is up to you.  Do you want to specifically list which CA's you 
>> trust?  Or take the same defaults as all other SSL apps on the system? 
>> I generally choose "No", so it uses the general-purpose CA trust list.
>>
>> Certificate revocation processing: Yes
>>
>> I don't use CRLs, but it doesn't hurt to choose "Yes" here, anyway.
>>
>>
>> Application description:
>>
>> Click the radio button on the left, next to "Application Description". 
>> Type a human-readable description of your application here.  This is 
>> what will show up when the user is viewing the applications in the DCM. 
>>   Something like "Klement's Sausage UPS Tracking Application".  Whatever 
>> makes sense for your users to see.
>>
>>
>> k) click "Add" and it should add the new application to the DCM.
>>
>> l) It'll tell you that it has added it successfsully... click "OK"
>>
>> m) You can now use the "Manage Applications" interface to view, update, 
>> etc the application.
>>
>> n) Click "Update Certificate Assignment"
>>
>> o) Click "Client"
>>
>> p) Your program should now be listed as one of the client programs on 
>> the system.  Select the radio button next to it, then the "Update Cert
>> Assignment" button at the bottom.
>>
>> q) It should list the certificates available.  Select the one you want 
>> to use as your client certificate, and then click "Assign New
> Certificate".
>> r) At the top of the screen, it says "cerificate was assigned to 
>> application"
>> -----------------------------------------------------------------
>>
>> So now you've created a profile of sorts in the DCM, and it tells the 
>> SSL settings for a particular application.  Any program that identifies 
>> itself to the DCM as "KLEMENTS_GIFTBOX_UPSTRACK" (or whatever you put 
>> for the application id) will use the settings provided to the DCM, 
>> above.  This is how you tell it that you want a certificate, and which 
>> certificate to use.
>>
>> Back in HTTPAPI, prior to using SSL for the first time in your program, 
>> do this:
>>
>>        callp https_init('KLEMENTS_GIFTBOX_UPSTRACK');
>>
>> (again -- or whatever ID you've assigned)  This tells HTTPAPI how to 
>> identify itself to the Digital Certificate Manager -- and therefore, 
>> HTTPAPI is requesting that the DCM uses the settings you provided in the 
>> application configuration in the DCM.  (Including the client certificate)
>>
>> If you have multiple client certificates that need to be assigned 
>> separately for separate applications, then create a second, third, (or 
>> whatever) application profile in the DCM for those other certificates. 
>> Tell HTTPAPI to use those alternate profiles.
>> -----------------------------------------------------------------------
>> This is the FTPAPI mailing list.  To unsubscribe, please go to:
>> http://www.scottklement.com/mailman/listinfo/ftpapi
>> -----------------------------------------------------------------------
>>
>>
>> __________ NOD32 4559 (20091030) Information __________
>>
>> This message was checked by NOD32 antivirus system.
>> http://www.eset.com
>>
>>
>> -----------------------------------------------------------------------
>> This is the FTPAPI mailing list.  To unsubscribe, please go to:
>> http://www.scottklement.com/mailman/listinfo/ftpapi
>> -----------------------------------------------------------------------
>>
> 
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list.  To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> -----------------------------------------------------------------------
> 
> 
> __________ NOD32 4562 (20091101) Information __________
> 
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
> 
> 
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list.  To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> -----------------------------------------------------------------------
> 

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------