Re: [Condor-users] SSL authentication with WinXP

["Smith, Ian" <I.C.Smith@xxxxxxxxxxxxxxx>]

> -----Original Message-----
> From: condor-users-bounces@xxxxxxxxxxx 
> [mailto:condor-users-bounces@xxxxxxxxxxx] On Behalf Of Ian Alderman
> Sent: 15 March 2007 16:47
> To: Condor-Users Mail List
> Subject: Re: [Condor-users] SSL authentication with WinXP
> 
> On Thu, Mar 15, 2007 at 02:25:02PM -0000, Smith, Ian wrote:
> >  
> ... 
> > but the big question is what I do with them. I can't work 
> out exactly 
> > what these parameters refer to
> > 
> > AUTH_SSL_SERVER_CA_FILE
> > AUTH_SSL_SERVER_CA_DIR
> > AUTH_SSL_SERVER_CA_CERTFILE
> > AUTH_SSL_SERVER_CA_KEYFILE
> > AUTH_SSL_CLIENT_CA_FILE
> > AUTH_SSL_CLIENT_CA_DIR
> > AUTH_SSL_CLIENT_CA_CERTFILE
> > AUTH_SSL_CLIENT_CA_KEYFILE
> 
> That's not quite right; it's
> AUTH_SSL_SERVER_CAFILE
> AUTH_SSL_SERVER_CADIR
> AUTH_SSL_SERVER_CERTFILE
> AUTH_SSL_SERVER_KEYFILE
> AUTH_SSL_CLIENT_CAFILE
> AUTH_SSL_CLIENT_CADIR
> AUTH_SSL_CLIENT_CERTFILE
> AUTH_SSL_CLIENT_KEYFILE
> 
> The distinction between the SERVER and CLIENT parameters is 
> that the client initiates the communication.  For example, 
> when the collector receives an update from an execute host, 
> the execute host initiates the connection and is therefore 
> the client.  When a schedd transfers a job to an execute 
> host, the schedd is the client and the execute host is the server.  
> 
> This distinction is made in the interest of flexibility; but 
> if no one cares or uses it we can remove it in the interest 
> of simplicity.  In the simple case, both the client and the 
> server entries are the same.
> 
> The KEYFILE and CERTFILE parameters are set to the host or 
> user private key and certificate files, repectively.  
> 
> AUTH_SSL_SERVER_KEYFILE = 
> /opt/condor/run/certs/pvt/foo.cs.wisc.edu.key
> AUTH_SSL_SERVER_CERTFILE = /opt/condor/run/certs/foo.cs.wisc.edu.crt
> 
> The DIR and FILE are used to determine the validity of certificates.
> Each side needs a way of determining whether the credentials 
> offered by a the other side are acceptable.  Each side 
> therefore needs to specify a list of certificate authorities 
> (CAs) which are acceptable.  If you create a CA, the CA 
> certificate is what you want here.  
> 
> Some CAs have multiple levels: a root CA and intermediate signing CAs.
> Some installations want to be able to trust several CAs.  
> OpenSSL provides two ways to specify the trusted CAs: put all 
> the certs in one file (FILE), or put them all in one directory (DIR).
> 
> In the most basic case:
> 
> AUTH_SSL_SERVER_CAFILE = /opt/condor/run/certs/cas/cacert.pem
> or
> AUTH_SSL_SERVER_CADIR = /opt/condor/run/certs/cas
> 
> > Do I need to set these on the execute hosts and the central manager 
> > and submit host ? Presumably I need to create one host cert per 
> > execute host but how do I tie it to that machine. Surely 
> someone could 
> > just copy it to another machine ?
> 
> Permissions need to be set on the key file so that the key 
> file is only readable by the condor daemons (which run as 
> root).  So, in the example above, 
> 
> chmod 0700 /opt/condor/run/certs/pvt
> 
> Cheers,
> 
> -Ian

Thanks for this. I'm trying to experiment with this on our
production (Solaris based) central manager which a bit fraught 
as we have real users accessing it. This machine also acts a submit
host. 
When I change the config to

SEC_DEFAULT_AUTHENTICATION = OPTIONAL
SEC_DEFAULT_AUTHENTICATION_METHODS = SSL

I can no longer submit jobs and get this error:

Submitting job(s)
ERROR: Failed to connect to local queue manager
AUTHENTICATE:1003:Failed to authenticate with any method

although it thought it was optional ? condor_q works OK.

any ideas,

regards,

-ian.