why do we need to set an SNI manually?

When the collector connects to instrumented applications via TLS, it needs to specify what hostname it will connect to the MongoDB driver. The server's TLS certificate must match this hostname, which is required for external MongoDB hosts deployed outside of the kubernetes cluster. Otherwise, the MongoDB driver in the coroot cluster-agent operates on the host's IP address and a TLS error occurs. Further here, if MongoDB is deployed inside the kubernetes cluster, the SNI is overridden to pod.Id.Name. Since MongoDB is usually deployed in a cluster as a statefulSet (other options are dangerous due to data loss), the host name is fixed and contains an increment by the number of statefulSet replicas

Perhaps I should extend the settings in coroot for MongoDB TLS, if you find it necessary, by adding support for the option:

• MinVersion, so as not to hardcode it here
• InsecureSkipVerify, so that self-signed certificates work without specifying a CA
• caCertPool, so that self-signed certificates are validated

I understand how SNI works, but you're suggesting we try to guess the SNI configured on the server. I think it should either be explicitly defined by the user or left empty with InsecureSkipVerify. For monitoring purposes, it's usually enough that the traffic between the agent and the server is encrypted—certificate validation isn’t always necessary.

Can we keep the config as simple as possible? Something like:
tls=true|false,InsecureSkipVerify=true|false

Let me describe the case I’m trying to solve.

I have several MongoDB 8.0.x hosts that are not inside a Kubernetes cluster, under the domain example.com (for example). Each host has an FQDN like:

• mongo1.example.com
• mongo2.example.com
• ...
• mongoX.example.com

I issue Let's Encrypt certificates for these hosts using a DNS challenge, for the wildcard *.example.com. It’s important for me that certificate verification is enforced (InsecureSkipVerify=false), to prevent MITM attacks.

Ideally, I’d like to have an option to explicitly specify the SNI hostname as a parameter. That way, even if in the future I add a second domain like example2.com or a third like example3.com with new MongoDB hosts, I can issue a universal certificate covering all domains (although due to some security concerns this might be problematic—in such cases, using separate Coroot projects or installations would be acceptable).

The issue is that if I enable TLS for MongoDB without SNI support, the connection fails due to a SAN error, since the connection goes via IP address, which is not listed in the certificate’s SAN. However, I believe that if the FQDN of the host or container inside the pod were used automatically, it would be the correct approach.

I propose the following solution to avoid overloading Coroot’s web interface:

• TLS: false|true (default: false)
• InsecureSkipVerify: true|false (default: true) - editable only if TLS is set to true
• CApath: absolute_path (default: "" - system/container CA is used) - editable only if InsecureSkipVerify is set to false
• ServerName: string (default: "" - the FQDN of the host or container is used) - editable only if InsecureSkipVerify is set to false

The same applies to annotations in Kubernetes.

As an example, I’m using the configuration approach recommended by the Percona MongoDB Operator for self-signed certificates.

I don't think we should rely on container or host names extracted from metrics. The user should either explicitly define ServerName or leave it empty, in which case the client will likely fall back to using the IP address.

Regarding CAPath, how is the CA file supposed to get into the cluster-agent container?