Felix Schwarz wrote:
Hi all,

I'm experiencing some configurations issues enabling TLS on 1.37.38.

bacula-dir.conf

Director {                            # define myself
 Name = maindirector

 TLS Enable = yes
 TLS Require = yes
 TLS Certificate = /etc/bacula/certs/server1.schwarz.local.crt
 TLS Key = /etc/bacula/keys/server1.schwarz.local.key
 TLS Verify Peer = yes
 TLS Allowed CN = server1.schwarz.local
 TLS Allowed CN = workstation.schwarz.local
 TLS CA Certificate File = /etc/bacula/certs/root.crt


bconsole.conf

Director {
 Name = maindirector
 address = server1.schwarz.local

 TLS Enable = no
 TLS Require = yes
 TLS Certificate = /etc/bacula/certs/server1.schwarz.local.crt
 TLS Key = /etc/bacula/keys/server1.schwarz.local.key
 TLS CA Certificate File = /etc/bacula/certs/root.crt
}


Allthough TLS should be disabled ("TLS Enable = no") the console can
connect to the director which requires TLS ("TLS Enable = yes", "TLS
Require = yes").

Maybe you would consider this as an invalid configuration (due to
contradicting TLS Enable/TLS Require in bconsole.conf) but there is no
warning or error message when using the bconsole. I assume that the
connection uses TLS and "TLS Enable = no" is ignored.

If this behavior is expected, I think it should be mentioned in the
manual that TLS Require may override TLS Enable (I assumed the
opposite initially).

I will put together a patch that prevents the usage of contradicting TLS Enable and TLS Require settings.

And one maybe irritating error message when using TLS:

25-Sep 21:53 bconsole: ERROR in tls.c:86 TLS read/write failure.:
ERR=error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
Bad response to Hello command: ERR=Keine Daten verfügbar
Director authorization problem.
Most likely the passwords do not agree.


Despite the "wrong version number" thing this may be caused by a
client connecting with a common name that is not listed in "TLS
Allowed CN".

This is due to the server unceremoniously dropping the client in bnet_tls_server(). The server will log a useful error message:

"TLS certificate verification failed. Peer certificate did not match a required commonName\n"

The client has no way of knowing this -- the authorization protocol doesn't provide authorization failure information to the client.

That said, the error message you are quoting appears to be missing some information:
   "Director authorization problem.\n"
   "Most likely the passwords do not agree.\n"
   "If you are using TLS, there may have been a certificate validation
   error during the TLS handshake.\n"
   "Please see
http://www.bacula.org/rel-manual/faq.html#AuthorizationErrors for help.\n"));

Which at least provides some indication that a certificate validation failure occurred. Does your client not print that full message?

-landonf

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to