On Tue, Sep 12, 2023, at 6:23 AM, Vanush "Misha" Paturyan wrote:
> On Mon, 11 Sept 2023 at 20:19, Dan Langille <[email protected]> wrote:
>>
>> Yes, I think it's SSL erroring out, I agree with your theory.
>>
>> Which means: what Key Usage needs to be included for each of:
>>
>> * bacula-fd
>> * bacula-sd
>> * bacula-dir
>>
>> Thank you for sharing your details. Is this cert used with bacula-sd or
>> bacula-fd?
>
> That was a certificate from bacula-fd. bacula-sd certificate has the same
> extensions (Key Usage: Digital Signature, Non Repudiation, Key Encipherment,
> Data Encipherment). Its CN matches the value of SDAddress in the `Storage`
> section of bacula-sd.conf file. For completeness, the TLS related entries in
> that file are:
> TLS Enable = yes
> TLS Require = no
> TLS Verify Peer = yes
> TLS CA Certificate = <path to CA cert>
> TLS Certificate = <path to the sd certificate>
> TLS Key = <path to the key file>
We differ only in TLS Require
One thing I just realized: There are two clauses in configuration files, each
of which can take a certificate. Until now, I never considered that each one
could be a different cert; one client, one server.
Let me us my bacula-sd as an example:
Storage {
Name = "bacula-sd-04"
TLS Certificate = server key goes here
}
Director {
Name = "bacula-dir"
TLS Certificate = client cert goes here
}
Perhaps that is what I need to investigate. Also, I could look into a a
dual-use certificate: it's
possible for the EKU to assert both "Web Client" and "Web Server"
>
>>
>> I ask because yesterday I started running some copy jobs. The cert used by
>> bacula-sd was acceptable for receiving backups. It was not acceptable for
>> copy jobs.
>>
>> 09-Sep 10:19 bacula-sd-04 JobId 358322: Error: openssl.c:68 Connect failure:
>> ERR=error:1417C086:SSL routines:tls_process_client_certificate:certificate
>> verify failed
>> 09-Sep 10:19 bacula-sd-04 JobId 358322: Fatal error: bnet.c:75 TLS
>> Negotiation failed.
>> 09-Sep 10:19 bacula-sd-04 JobId 358322: Fatal error: TLS negotiation failed
>> with FD at "10.55.0.7:27230"
>> 09-Sep 10:19 bacula-sd-04 JobId 358322: Fatal error: Incorrect authorization
>> key from File daemon at client rejected.
>> For help, please see:
>> http://www.bacula.org/rel-manual/en/problems/Bacula_Frequently_Asked_Que.html
>> 09-Sep 10:19 bacula-sd-04 JobId 358322: Security Alert: Unable to
>> authenticate File daemon
>
> I wonder if your SD connects to itself here, and fails to validate itself?
> The log above does mention an FD at 10.55.0.7. Does that FD component have a
> certificate? maybe there's mis-match with the CN of that certificate and the
> FDAddress directive in the bacula-fd.conf file?
There is no bacula-fd at 10.55.0.7 - it is not running and not configured. It
is bacula-sd only at that IP address.
Yes, bacula-sd-04 is at 10.55.0.7 - I don't know why FD is mentioned in the
error.
>From the docs (https://bacula.org/13.0.x-manuals/en/main/Migration_Copy.html):
The Copy and the Migration jobs run without using the File daemon by copying
the data from the old backup Volume to a different Volume in a different Pool
My reading of that: an FD should not be involved here.
--
Dan Langille
[email protected]
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users
