Failed to login when changing from LDAP to LDAPS against AD Server

Hi all,

our AD Admin informed us that we must change our LDAP connection to LDAPs because LDAP connections will be blocked within 2 weeks.

We are using grafana 10.1.2 on a Debian 11 system.
Our Grafana uses LDAP without problems.

So i switched to LDAPS in the ldap.toml file.
Our config now looks like this:
host = “our.ldaps.server”
port = 636
use_ssl = true
start_tls = false
tls_ciphers =
ssl_skip_verify = true

and the normal bind, pw and other settings for LDAP which worked very fine when using LDAP.

On restarting the grafana server and trying to log in with my LDAP user results in:
Login failed
Invalid username or password. → this worked fine before when using LDAP!!!

The grafana Log now tells me this weird message:
logger=authn.service t=2023-10-04T15:40:47.410734483+02:00 level=warn msg=“Failed to authenticate request” client=auth.client.form error=“[password-auth.failed] failed to authenticate identity: tls: server sent certificate containing RSA key larger than 8192 bits\n[password-auth.invalid] invalid password”

Which tells me nothing at all.

We have other applications using LDAPS against AD working quite fine.

Can please someone help me with that weird error and getting Grafana working with LDAPS?


That’s current Golang limit

Solution will be to use cert with snaller rsa key on ldap server.
Dirty workaround: compile own Grafana binary with older Golang version, which doesn’t have this limitation.

Hi Jangaraj,

shorter RSA is unfortunately nothing to discuss about.
Is there another way to use an official and modern grafana which is capable to deal with the large RSA?

I mean the larger an RSA key is the besser is the security … ???

As I said: compile own Grafana with older Golang version, which doesn’t have this limit

BTW: what’s is RSA key size in used ldap cert?

I would say 8k+ key size is overkill: TLS Key Size: Why Bigger isn't Always Better | Fastly

Hi Jangaraj,

keysize is about 9k and no own compile is no option for us.


I would ask that person (AD admin?), who decided to use 9k RSA key. That looks like overkill, which is causing a problems as you see. Bigger is not better.

Hi Jangaraj,

this is standard in Microsoft Azure AD and i am quite sure they won’t use smaller keys only if a small linuxer using grafana asks for.


Did you ask your Azure support? This will not affect only small linuxer, but whole Golang world.
IMHO I don’t see a reason for 9k RSA key, when there is an option for much smaller ECDSA key.

You may try to build hackish “tls reverse proxy” for AD, so Grafana doesn’t communicate with AD directly, but through proxy, which has more suitable tls cert for Golang app (Grafana).

Hi Jangaraj,

yes i have. This is that what they told me. The can use a smaller key, but the next update will reinstall the large one and in near future this will be disabled to use a smaller key.


What is a point of using 9k RSA key, which is weaker than 1k ECDSA key?

Did you talk with Azure (Microsoft) employees? Where is any documentation that they use 9k RSA key?