LDAPS bind fails with `SERVER_DOWN` due to missing CA trust source

[Pingumania]

Describe the bug
LDAPS binds fail with ldap.SERVER_DOWN: Can't contact LDAP server, even with a valid, publicly trusted cert (Let's Encrypt).
I have an lldap instance setup with ldaps, but Fireshare can't establish the cert chain.
Setting LDAPTLS_CACERT=/etc/ssl/certs/ca-certificates.crt or LDAPTLS_REQCERT=never "fixes" it, but the error message makes it look like a network/DNS problem instead of a cert problem.

To Reproduce

1. Enable LDAP with LDAP_URL=ldaps://your-ldap-host:636
2. Point it at a server with a valid cert (public CA)
3. Start the container
4. See ldap.SERVER_DOWN: Can't contact LDAP server on startup, even though the LDAP server is reachable and the cert is fine

Expected behavior

1. The log/error message should reflect a certificate issue in this case.
2. Fireshare should trust the system's CA bundle (already present in the image via ca-certificates) by default for LDAPS connections, the same way tools like curl do automatically.
   Or the LDAP documentation should reflect this.

Additional context
Side note: LDAP_ENABLE=false doesn't actually disable LDAP. Only leaving the var completely unset disables it.

[ShaneIsrael]

Unfortunately this is the one feature that I have no easy way to test or update as I have 0 experience with LDAP. This is unlikely to be fixed and it was added a long time ago by someone else.

I've actually been wanting to remove it because of that. Probably not the response you were hoping for but if you can use regular sign in option I would use that as LDAP might not exist in one of the future updates.

[Pingumania]

Since its working for me with the above workaround, I can live with that. My only request would be to wait with the LDAP removal until something else (like #486) is implemented.

[ShaneIsrael]

OpenID Connect will also not be implemented, at least not anytime soon. Main reason being is that I need to be able to actively test and make sure it works always and if it breaks being able to implement a fix and test fast. (basically the same situation LDAP is in right now). Because the project isn't very large I don't have anybody other than myself that can immediately be available to fix and test it if it is broken. And since I don't use OpenID Connect for anything (I personally hate single sign on apps for reasons I'm not going to dive into here) I don't have a reliable way to test code changes and updates with it.

Even if somebody were to volunteer to implement it, they would need to also be available immediately (i.e within minutes/hour) of a first reported issue since it deals with logging into the system and I do not have anybody that I can trust to do that. If it gets implemented and a bunch of people start using it and then either OpenID connect updates or Fireshare itself has an update that breaks it having it go unfixed for more than a couple hours is not acceptable. Luckily with LDAP only a handful of people are using it, but this is also why I will be removing it at some point.

[Pingumania]

Maybe some sort of disclaimer for LDAP in the docs is enough?
"Use this at your own risk, this feature is not thoroughly tested, dont expect it to work and support will be limited if at all"

Since LDAP is around long enough I dont expect breaking changes and it's working at the moment. Would be a bummer if it got removed.
I don't want to tell you how to handle your project, but I at least want to give my thoughts 😄

Even without an external identity provider I will probably still use it.

[ShaneIsrael]

If it's still working I won't touch it but if I start getting hammered with reports orlf it not working or not working correctly I will remove it since I can't support it or verify myself whether or not it is actually broken or if the person reporting is just not configuring it right.

And I really don't like having a feature that is half broken in the app.