Can't connect to MySQL datasource since switch to "--require_secure_transport=ON" mode

Hi Grafana Community,

some time ago our MySQL database changed its configuration and enabled “–require_secure_transport=ON” and we connect using TLS with our SQL tooling (for me IntelliJ).

Error message I get:
“logger=tsdb.mysql t=2023-01-16T10:32:40.287979533+01:00 level=error msg=“Query error” error=“Error 3159: Connections using insecure transport are prohibited while --require_secure_transport=ON.””

I can connect using IntelliJ just by enabling TLS/SSL checkox. No certificate or any other file is needed.

I tried the checkboxes in various constellations but none were successful. I didn’t add any information in the appearing boxes as this shouldn’t be necessary.

Can you please help me how I can configure this or is this a bug?

Thank you in advance

Using v9.3.2 (21c1d14e916)

Hi @otakun85,

Welcome to the :grafana: community support forums !!

We are excited that you joined our OSS community. Please read about some of the FAQs in the community :slight_smile:

I understand that your MySQL server is now secured by enabling this configuration parameter:


Is the SSL configured to work with the remote host?

Might be good to check this link:

Let us know if this helps.

Hello and thank you for the quick reply.

If I read the content of the link correctly than this describes how I can setup in general a mysql server and client to connect from with TLS.

Yet in my situation the server is already setup.

I configured following in MySQL Workbench or IntelliJ and it just works:
username and password
(Use SSL if available, default setting)

So I’m wondering why it’s not working in Grafana data source setting?

Updating this post as the same user @otakun85 also reported it at:

will help others to keep track and follow the update on resolution.

A year after the problem seems to persist, I’ve tried with latest 9.4.17 and I still can’t configure a datasource using secure transport.
In my case I’m using Azure Mysql Flexible Server. I’ve been able to configure the database for grafana using secure connection but the datasource is not able to connect. Always throws an error

[xorm] [info]  2024/02/26 13:29:32.122745 PING DATABASE mysql
logger=tsdb.mysql t=2024-02-26T13:29:32.152392869Z level=error msg="Query error" error="Error 3159: Connections using insecure transport are prohibited while --require_secure_transport=ON."
logger=context userId=1 orgId=1 uname=admin t=2024-02-26T13:29:32.15256794Z level=info msg="Request Completed" method=GET path=/api/datasources/uid/XW_8ALoIz/health status=400 remote_addr= time_ms=39 duration=39.459766ms size=91 referer=http://localhost:8080/grafana/datasources/edit/XW_8ALoIz/ handler=/api/datasources/uid/:uid/health

Hi @rmacian1

Looking at the error message is not related to Grafana but to the MySQL in general as it says:

Connections using insecure transport are prohibited while --require_secure_transport=ON.

Now this can be easily fixed by MySQL config to turn require_secure_transport=OFF

But the drawback will be that it is insecure for production usage.

The alternative (more secure) method is to configure SSL/TLS so that the client connects MySQL server via SSL/TLS protocol config.

Here is a reference link

I hope this helps.

It’s a grafana issue as specified in the github ticket.You are e.g. not using the “preferred mode” for mysql as most mysql clients do. And you allow TLS only when a certificate file is provided, which is actually optional.

But since the bug was not solved I stopped using it. I don’t wanna keep my own grafana patched source code just for this.

The problem is not in the server side. Indeed I am using the same MySQL as grafana backend , but the datasource to enable dashboards to connect to mysql does seems to contemplate an SSL connection without client authentication

That’s I am gonna do. I asked on the ticket too. I was only setting it up because of a mysql dashboard found that requires it. I will left it a part because even the latest version of grafana released suffers from the same issue.

Hi @otakun85 and @rmacian1

You are right, I looked into the above GitHub issue link and it is marked as a bug. I have added some more info to it.


Got some updates from the Engineering folks. Currently, they are working on a fix for the same error in PostgreSQL and then MySQL will be next.

1 Like