TLS Encryption: Director cannot access storage daemon

[Tilman Glötzer]

Dear all


Running "status storage=<StorageName>" does not complete. The logfile
reveals the following message:
18-Jan 00:00 backup-dir JobId 0: Fatal error: bnet.c:190 TLS host
certificate verification failed. Host name "backup.fritz.box" did not
match presented certificate

a) understand that the director cannot connect to the storage daemon
because the certificate was signed with a different common name. What
entries of the client daemon's and the director's configuration need to
reference to the same TLS certificate to make this work?
b) The storage daemon and the director live on one machine behind a
firewall. On the WAN side of the firewall, there is a file daemons using
the FQDN to access the storage daemon. I used this FQDN as Common Name
for the TLS certificate. Storage director and storage daemon however use
the internal DNS name backup.fritz.box. May this be contributing to the
presented problem? Does accessing the storage daemon from the director
require an additional certificate (with the local common name
"backup.fritz.box")?

Many thanks

Tilman

[Tilman Glotzner]

Dear all

(ad a) Now, it seems to work -- even though I am not sure that the communication is now indeed protected by TLS.

in bareos-dir.conf, I changed the storage section to
Storage {
Name = FileStorage1
Address = backup.fritz.box # N.B. Use a fully qualified name here
SDPort = 9103
Password = "password"
Device = FileStorage1
Media Type = File

TLS Enable = yes
TLS Require = yes
TLS CA Certificate File = /etc/bareos/ssl/cacert.pem
TLS Certificate = /etc/bareos/ssl/qtron.gloetzner.net.crt
TLS Key = /etc/bareos/ssl/qtron.gloetzner.net.key

}

In bareos-sd.conf, I have changed the director section to:
Director {
Name = backup-dir
Password = "<password>"
TLS Certificate = /etc/bareos/ssl/qtron.fritz.box.crt
TLS Key = /etc/bareos/ssl/qtron.fritz.box.key
TLS CA Certificate File = /etc/bareos/ssl/cacert.pem
TLS Allowed CN = backup.dns,net
TLS Allowed CN = backup.fritz.box
TLS Enable = yes
TLS Require = yes
TLS Verify Peer = yes
}

Is it possible to check if the communication runs indeed encrypted? I have seen posts of other with the same question, but the responses were somewhat unsatisfying: The suggestion was to issue a status command to the storage daemon...

Thanks

Tilman

[Tilman Glotzner]

Dear all

1) I did some more research. The following sections and with it, the certificates in the configuration files need to match- Please correct me, if I am wrong
a) The certificates of file daemon's [director] section need to match that of the corresponding [client] section of the director daemon.
b) The file daemon's [FileDaemon] section needs to have the same the TLS certificates as the [storage] section of the storage daemon
c) The certificates in the [storage] section of the director daemon needs to be the same as those of the [director] section of the storage daemon

2) My configuration works with clients external to the firewall. If I try to run a job using a file daemon behind the firewall, i.e. storage daemon and file daemon are both behind the firewall, I get this
01-Feb 00:23 qtron-fd JobId 244: Fatal error: bnet.c:190 TLS host certificate verification failed. Host name "qtron.fritz.box" did not match presented certificate.

For the external clients I need a certificate with the external FQDN -- and for the internal clients I need one with the internal FQDN. I guess this is the root cause for the error message.
Setting TLS verify = no in the FileDaemon section of the (internal) file daemon resolves this problem.

Now, the root of all this seems to be a design issue: The TLS certificates are bound via the common name of the certificates to the DNS name of the machines that host the corresponding daemon.

If I would want to leave TLS verify = yes, would I need to define 2 identical storage devices in the storage daemon's configuration that differ only in the DNS name and the certificate ? Is there another way of decoupling the certificate's common name from the DNS names or FQDNs?

Going forward, I would like to suggest to the development community a command with which one can check if a connection or channel between the daemons runs encrypted. I understand that technically that is not really necessary, as the communication will fail in case something is wrong. I think however, it helps to verify the configuration and prevents to overlook links that should be encrypted but are not due to a configuration mistake.

In addition, I do not find the procedure any more in the web with which I created the certificates. I found a couple of other procedures, but they seem to differ, and the certificates produced don't work with the existing CA certificate. I would appreciate a link to a procedure to create the certificates that is know to work.

Many thanks

Tilman

[Philipp Storz]

Hello Tilman,

CNs that are configured in "TLS allowed CN" will be accepted even if the certificate does not
exactly match the name.

--
Mit freundlichen Grüßen

Philipp Storz philip...@bareos.com
Bareos GmbH & Co. KG Phone: +49 221 63 06 93-92
http://www.bareos.com Fax: +49 221 63 06 93-10

Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
Geschäftsführer: Stephan Dühr, M. Außendorf,
J. Steffens, P. Storz, M. v. Wieringen

[Tilman Glotzner]

Dear Philipp

> CNs that are configured in "TLS allowed CN" will be accepted even if the certificate does not
> exactly match the name.

It only worked after I set "TLS verify Peer = no" in the Storage Section of bareos-sd.conf. Not sure what TLS verify Peer does -- also reference manual does not shed light on that. Is TLS verify Peer = yes checking if the name of the certificate matches the DNS name ?

Many thanks

Tilman