Bacula-users

Re: [Bacula-users] TLS Question

2008-08-18 11:23:18
Subject: Re: [Bacula-users] TLS Question
From: Franky Almonte <falmonte AT onemax DOT com>
To: Dan Langille <dan AT langille DOT org>
Date: Mon, 18 Aug 2008 11:23:00 -0400
Dan Langille wrote:
> 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.
I'm also using only one certificate for the Director. The 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.
>
This is the part i don't understand. How i setup the FD for this?
Actually i'm using client certificates.


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

<Prev in Thread] Current Thread [Next in Thread>