[prev in list] [next in list] [prev in thread] [next in thread] 

List:       racf-l
Subject:    Re: IBM TDS and Digital Certificates
From:       Rob Schramm <rob.schramm () GMAIL ! COM>
Date:       2013-01-28 23:53:44
Message-ID: CAN3vrrmdG8j7B+d0D1rvMqEBymsqYHd5h9AsWpXCi-OObTYgLA () mail ! gmail ! com
[Download RAW message or body]

Or you could do a CSR on Windows to RACF.

Rob Schramm

Rob Schramm
Senior Systems Consultant
Imperium Group



On Mon, Jan 28, 2013 at 4:30 PM, Michael Kearney <kearney@us.ibm.com> wrote:

> I agree with Nigel.
> 
> The LDAP client must have a copy of the RACF certificate you used to sign
> the TDS server's cert.  And the TDS keyring must have a copy of the cert
> that signed the LDAP client's cert. You will save a few steps if you
> create the client's cert in RACF, and sign it with the same RACF cert used
> to sign the TDS server.
> 
> Regards,
> Mike
> 
> 
> 
> Nigel Pentland <nigel@NIGELPENTLAND.NET>
> Sent by: RACF Discussion List <RACF-L@listserv.uga.edu>
> 01/28/2013 04:19 PM
> Please respond to
> RACF Discussion List <RACF-L@listserv.uga.edu>
> 
> 
> To
> RACF-L@listserv.uga.edu,
> cc
> 
> Subject
> Re: IBM TDS and Digital Certificates
> 
> 
> 
> 
> 
> 
> Juan,
> 
> Personally, I'd create using RACDCERT, export from RACF as PKCS12 file
> and name it to be a .pfx file and import into Windows.
> 
> If you want to generate on Windows there are two mainstream options
> (assuming you don't have Microsoft PKI that is) either Microsoft's
> makecert utility or OpenSSL.
> 
> makecert is deceptively powerful, having the ability to create CA signed
> certificates. OpenSSL goes even further, but get much more complicated.
> 
> http://msdn.microsoft.com/en-us/library/bfsktky3%28v=vs.80%29.aspx
> 
> or
> 
> http://slproweb.com/products/Win32OpenSSL.html
> 
> Hope that helps,
> 
> Nigel...
> 
> ps here are some samples of makecert
> 
> rem This first makecert command generates a self signed root certificate
> which is placed in the certificate store for the current user.
> "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\makecert.exe" -a sha1
> -cy authority -n "CN=makecert test root" -r -ss my -sr currentuser
> test-root.cer
> rem When the root certificate is generated it was also saved to a file
> to enable easy loading into the Trust Root Certificate Authorities store
> - just click install.
> test-root.cer
> rem This second makecert command generates a certificate signed by the
> root generated before.
> "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\makecert.exe" -a sha1
> -cy end -n "CN=me@email.com" -eku 1.3.6.1.5.5.7.3.4 -ss my -sr
> currentuser -is my -ir currentuser -in "makecert test root"
> rem Running Certificate Manager like this displays the contents of the
> current user's certificate store.
> certmgr.msc
> 
> 
> 
> On 28/01/2013 20:02, Mautalen Juan Guillermo wrote:
> > Bruce, thanks for the link.
> > 
> > I have already configured the TIVOLI Directory Server (TDS) to accept
> secure connections on an specific port. I have also created in RACF both a
> self signed certificate and another certificate for the TDS signed with
> the former. Both connected to a ring I created, whose name is referenced
> in the TDS configuration. All this seems to be ok.
> > 
> > My problem arises on the client side. How do I create my client
> certificate? Should I create it in windows, and then export it to z/OS and
> add it to RACF? If so, what is the way to go to create a client
> certificate in Windows? Self signed?
> > Or can I also create my client certificate in RACF (using RACDCERT
> GENCERT) and then export it to my Ldap client (along with its private
> key)?
> > 
> > Thanks for your help,
> > 
> > Juan G. Mautalen
> > 
> > -----Mensaje original-----
> > De: RACF Discussion List [mailto:RACF-L@LISTSERV.UGA.EDU] En nombre de
> Bruce Wells
> > Enviado el: viernes, 25 de enero de 2013 06:47 p.m.
> > Para: RACF-L@LISTSERV.UGA.EDU
> > Asunto: Re: [RACF-L] IBM TDS and Digital Certificates
> > 
> > Mautalen Juan Guillermo <jmautalen@ANSES.GOV.AR> wrote on 01/25/2013
> > 08:06:46 AM:
> > 
> > > Hi:
> > > 
> > > We have implemented IBM TIVOLI Directory Server with SDBM backend
> > > (z/OS 1.11, but migrating to 1.13 soon). It is intended to be used
> > > by a JAVA application that is currently under developement. The
> > > simplest idea is binding to the server using a fixed RACF userid,
> > > whose password will be embedded somewhere into the application code.
> > > This has obviously some big cons, as you can easily figure out:
> > > 
> > > 
> > > -          The password of this powerful userid will be exposed in
> > > the clear in some source program, residing in some server...
> > > 
> > > -          The fixed userid can be intentionnaly REVOKed, achieving
> > > a sort denial of service attack
> > > 
> > > I believe a better alternative may be to bind to the server using a
> > > digital certificate. Is this possible?
> > > I am pretty ignorant about authenticating to RACF using digital
> > > certificates, but my understanding is that RACF, after somewhat
> > > verifying the received certificate, maps it to a valid RACF userid.
> > > In this context, can the mapped userid be PROTECTED? Making it
> > > PROTECTED should address the issue of intentional revocation.
> > > 
> > Juan,
> > 
> > You should be able to accomplish your goals.  The following section in
> > "IBM Tivoli Directory Server Administration and Use for z/OS" should get
> > you started.
> > 
> > 
> 
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/glpa2ac0/1.7.12.8?SHELF=glpabk50&DT=20110623103934
>  
> > 
> > Regards,
> > Bruce R. Wells, CISSP
> > z/OS Security Server Design and Development
> > Phone: Tie 8-295-7498  External: (845) 435-7498
> > Internet: brwells@us.ibm.com
> > Poughkeepsie, NY  USA
> 


[prev in list] [next in list] [prev in thread] [next in thread]