Dan Langille wrote:
> Franky Almonte wrote:
>> 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.
>
> Does this help?
>
>   http://www.freebsddiary.org/bacula-tls.php
>
> I documented my setup as I went.  The above is exactly what I did.
>
>
Good article.

Then i need to create a certificate for each client? Is what i did. And
it's working.
Is not explained explicitly in the article.



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