Bacula-users

Re: [Bacula-users] TLS Question

2008-08-18 11:16:18
Subject: Re: [Bacula-users] TLS Question
From: Dan Langille <dan AT langille DOT org>
To: Sergio Gelato <Sergio.Gelato AT astro.su DOT se>
Date: Mon, 18 Aug 2008 11:15:41 -0400
Sergio Gelato wrote:
> * 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.

Are you sure that the Director needs both a client and a server 
certificate?  My Director has only one. A server certificate.

And, FWIW, I use only Server certificates for my TLS.  I use them on the 
SD, the FD, and the Director.  I do not use Client certificates, AFAIK.


-- 
Dan Langille

BSDCan - The Technical BSD Conference : http://www.bsdcan.org/
PGCon  - The PostgreSQL Conference:     http://www.pgcon.org/

-------------------------------------------------------------------------
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