Franky Almonte wrote:
> 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?

Yes.

> Is what i did. And
> it's working.

Good.

> Is not explained explicitly in the article.

Feel free to add a comment to the article and explain what was not well 
explained.  :)

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