Frontend: Configuration of TLS-encrypted communication with Redis not possible without CA

mocdaniel commented 1 year ago

Describe the bug

When configuring IcingaDB-Web via the UI, it is not possible to configure Redis endpoints with TLS encryption without entering a CA - in many cases, e.g. using managed solutions by public cloud providers or a propagated enterprise-internal CA, this is not necessary.

To Reproduce

Provide a link to a live example, or an unambiguous set of steps to reproduce this issue. Include configuration, logs, etc. to reproduce, if relevant.

Navigate to IcingaDB-Web's configuration of Redis endpoints in Icingaweb2: Modules -> icingadb -> Redis
Toggle Use TLS switch
Enter connection details, omit certificate details
Try submitting, it won't work

Expected behavior

Providing a CA should not be required just because TLS encryption has been configured.

Your Environment

Include as many relevant details about the environment you experienced the problem in.

Icinga DB Web version (System - About): 1.0.2
Icinga Web 2 version (System - About): 2.11.4
Web browser: Firefox/Edge
Icinga 2 version (icinga2 --version): r2.13.7-1
Icinga DB version (icingadb --version): 1.1.0
PHP version used (php --version): 7.2.24
Server operating system and version: RHEL8.8

Additional context

Configuring TLS encryption without providing a CA works fine when doing it in /etc/icingaweb2/modules/icingadb/redis.ini//etc/icingaweb2/modules/icingadb/config.ini, it's just blocked from the frontend - once configured from the backend, I can't even test the valid(!) configuration from Icingaweb2 because it keeps complaining about a missing CA.

nilmerg commented 1 year ago

Making the CA certificate optional is the very same as disabling peer verification, which we opted against to support it for the connection to redis. If it's possible to achieve by manually adjusting the configuration, I'd identify this as bug. :sweat_smile:

mocdaniel commented 1 year ago

I guess it's a bug, then.

Consider this minimal configuration which works for us:

# /etc/icingaweb2/modules/icingadb/config.ini
[...]

[redis]
tls = "1"

# /etc/icingaweb2/modules/icingadb/redis.ini
[redis1]
host = instance1.someurl.on.aws.com

[redis2]
host = instance2.someurl.on.aws.com

I just want to stress that making CAs required adds overhead for provisioning and maintaining the setup for aforementioned environments where the CA is already propagated.

nilmerg commented 1 year ago

Propagated as in part of the system ca certificate stack?

mocdaniel commented 1 year ago

Propagated as in part of the system ca certificate stack?

Exactly. E.g. most managed services would have TLS certificates signed by a well-known CA for the provided endpoints.

Al2Klimov commented 1 year ago

Then you can still copy and paste the specifically used root CA. Nowadays all the security fanatics (incl. me) pin at least the root CA via DANE. But not all apps check it. But if yours (Icinga DB Web) even supports such CA pinning independently of DANE – this is a no brainer. Just do it.

CC @julianbrost CC @Thomas-Gelf CC @pdolinic

pdolinic commented 1 year ago

https://github.com/aapooksman/certmitm : )

Icinga / icingadb-web