* Franky Almonte [2008-08-18 07:41:38 -0400]:
> Sergio Gelato wrote:
> > * Franky Almonte [2008-08-17 23:26:51 -0400]:
> >> Ryan Novosielski wrote:
> >>> One last question should fix me up -- which counts as a client?
> >>> Just bconsole, or some of the other connections as well?
> >>>       
> >> Every host running the Bacula FileDaemon (Client).
> >>     
> >
> > That's not quite my understanding.
> >
> > By definition, the client initiates the connection to the server:
> > 1) bconsole is a client of the director;
> > 2) the director is a client of the FDs and of the SDs;
> > 3) the FDs are clients of the SDs, *but* they don't need a certificate
> > to authenticate themselves: instead, they use the cookie that the
> > director hands them for this purpose. This saves the administrator
> > the trouble of maintaining a list of TLS Allowed CN for all the FDs
> > on every SD (and of creating client certificates for the FDs; they only
> > need server certificates).
> >   
> Yes, your right about clients. But, now i have a question about "Client
> certificates". I don't need to create certificates for clients ? 

What I'm saying is that the FDs only need server certificates (for
securing incoming connections from the director and for authenticating
themselves to the director). The FDs will only contact the SDs on the
director's instructions, and along with these instructions the director
will provide a one-time cookie that the FD can present to the SD for
authentication. (The director will have talked to the SD directly,
authenticating to the SD with its client certificate, and conveyed
a copy of that same cookie.) So the SD doesn't check the FD's
certificate in order to authenticate the transaction: it checks the
cookie instead.

> They just use the one from the Director ?

Indirectly; see above.

> > The director needs both a server and a client certificate. (One could
> > set the extendedKeyUsage so that the same certificate can be used for
> > both purposes, but I prefer to issue two different certificates.)
> >   
> Why the server needs both a server and a client certificate? 

That's not what I said. A server needs a server certificate; a client
*may* need a client certificate. The director needs both, because it acts 
both as a server (accepting bconsole connections) and as a client (connecting
and authenticating to the FDs and to the SDs). The FDs also act both as
servers (accepting director connections) and clients (connecting to the
SDs) but they authenticate to the SD through a mechanism that doesn't
require them to present a client certificate.

I also said it's possible to mint dual-purpose (server+client) certificates;
but it's usually more secure to use different keys for different purposes,
and in any case the conceptual distinction needs to be drawn.

> Because of the Director and the FileDaemon?

I'm not sure what you meant by this.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users