[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Condor-users] SSL authentication with WinXP
- Date: Mon, 19 Mar 2007 12:06:11 -0000
- From: "Smith, Ian" <I.C.Smith@xxxxxxxxxxxxxxx>
- Subject: Re: [Condor-users] SSL authentication with WinXP
> -----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
> 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 =
> 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
> 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
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
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:
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.