Mysql error 2026

Last updated: 2021-02-10

I’m trying to connect to my Amazon Relational Database Service (Amazon RDS) DB instance or cluster using Secure Sockets Layer (SSL). I received the following error:

«ERROR 2026 (HY000): SSL connection error»

How can I resolve ERROR 2026 for Amazon RDS for MySQL, Amazon Aurora for MySQL, or Amazon Aurora Serverless?

Short description

There are three different types of error messages for ERROR 2026:

• ERROR 2026 (HY000): SSL connection error: SSL certificate validation failure
• ERROR 2026 (HY000): SSL connection error: Server doesn’t support SSL
• ERROR 2026 (HY000): SSL connection error: ASN: bad other signature confirmation

See the following troubleshooting steps for each error message.

Resolution

ERROR 2026 (HY000): SSL connection error: SSL certificate validation failure

To troubleshoot this error, first validate whether you’re using the cluster endpoint or the DB instance endpoint. To learn how Amazon RDS supports SSL, see Using SSL with a MySQL DB instance or Using SSL with Aurora MySQL DB clusters.

If you use a client that supports Subject Alternative Names (SAN), then you can use only the cluster endpoint. If your client doesn’t support SAN, you must use the endpoint of the primary DB instance.

Note: The default MySQL command line client doesn’t support SAN.

If you receive this error when trying to connect to the cluster endpoint, try connecting to the endpoint of the primary DB instance in the connection string. For example, you can connect to the cluster endpoint. In the following example, the cluster endpoint is abcdefg-clust.cluster-xxxx.us-east-1.rds.amazonaws.com. The DB instance endpoint is abcdefg-inst.xxxx.us-east-1.rds.amazonaws.com.

Connect using the cluster endpoint

[ec2-user@ip-192-0-2-0 ~]$ mysql -h abcdefg-clust.cluster-xxxx.us-east-1.rds.amazonaws.com --ssl-ca rds-combined-ca-bundle.pem --ssl-mode=VERIFY_IDENTITY -u test -p test
Enter password:
ERROR 2026 (HY000): SSL connection error: SSL certificate validation failure

Connect using the DB instance endpoint

[ec2-user@ip-192-0-2-0 ~]$ mysql -h abcdefg-inst.xxxx.us-east-1.rds.amazonaws.com --ssl-ca rds-combined-ca-bundle.pem 
--ssl-mode=VERIFY_IDENTITY -u test -p test
Enter password: 
Welcome to the MySQL monitor. Commands end with ; or g. 
Your MySQL connection id is 26

ERROR 2026 (HY000): SSL connection error: Server doesn’t support SSL

You can receive this error if the server or engine version that you use doesn’t support SSL. To resolve this error, migrate to an engine that supports SSL connections.

ERROR 2026 (HY000): SSL connection error: SSL_CTX_set_default_verify_paths failed or ERROR 2026 (HY000): SSL connection error: ASN: bad other signature confirmation

You can receive this error if the certificate identifier (certificate file name) isn’t correct. You can also receive this error if the certificate identifier isn’t supported by the MySQL client, for example with Aurora Serverless. If you use Aurora Serverless clusters and you use the MySQL client to connect to Aurora Serverless, then you must use the MySQL 8.0-compatible MySQL commands.

Be sure to use the correct certificate identifier name and the correct path to the certificate to connect successfully. Before connecting, confirm that you have downloaded the correct certificate. For more information, see Using SSL to encrypt a connection to a DB instance.

The root certificate file is in the Downloads directory in an Amazon Elastic Compute Cloud (Amazon EC2) instance. In the following example, you enter the incorrect path, which results in ERROR 2026:

[ec2-user@ip-192-0-2-0 ~]$ mysql -h abcdefg-clust.cluster-xxxxx.us-east-1.rds.amazonaws.com --ssl-ca rds-combined-ca-bundle.pem --ssl-mode=VERIFY_IDENTITY -u test -p test
Enter password:
ERROR 2026 (HY000): SSL connection error: SSL_CTX_set_default_verify_paths failed

Note: This example uses the connection string in the home directory, but the root certificate is in the Downloads directory.

In the following example, you use the path to the root certificate to connect successfully:

[ec2-user@ip-192-0-2-0 ~]$ mysql -h abcdefg-clust.cluster-xxxx.us-east-1.rds.amazonaws.com --ssl-ca /home/ec2-user/Downloads/rds-combined-ca-bundle.pem 
--ssl-mode=VERIFY_IDENTITY -u test -p test
Enter password: 
Welcome to the MySQL monitor. Commands end with ; or g. 
Your MySQL connection id is 26

You can also receive this error if you don’t have permissions to the directory that the certificate is stored in. Be sure that the certificate is in a directory that you have permissions to access. See the following examples to connect with and without permissions:

Connecting with insufficient permissions

[ec2-user@ip-192-0-2-0 ~]$ sudo chmod 700 rds-combined-ca-bundle.pem 
[ec2-user@ip-192-0-2-0 ~]$ mysql -h abcdefg-inst.xxxx.us-east-1.rds.amazonaws.com --ssl-ca rds-combined-ca-bundle.pem --ssl-mode=VERIFY_IDENTITY -u test -p test
Enter password: 
ERROR 2026 (HY000): SSL connection error: SSL_CTX_set_default_verify_paths failed

Connecting with the correct permissions

[ec2-user@ip-192-0-2-0 ~]$ sudo chmod 755 rds-combined-ca-bundle.pem
[ec2-user@ip-192-0-2-0 ~]$ mysql -h abcdefg-inst.xxxx.us-east-1.rds.amazonaws.com --ssl-ca rds-combined-ca-bundle.pem --ssl-mode=VERIFY_IDENTITY -u test -p test
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or g.
Your MySQL connection id is 810

---

Did this article help?

---

Do you need billing or technical support?

AWS support for Internet Explorer ends on 07/31/2022. Supported browsers are Chrome, Firefox, Edge, and Safari.
Learn more »

Debugging MySQL SSL problems

This is not necessarily going to be a comprehensive post, but I learned somethings about MySQL SSL today that I thought would be worth sharing.

I was setting up a PRM install for a customer and one of the requirements was SSL replication. In this particular case, I had setup PRM first, and then was working to get the other requirements configured. I knew from experience that it was best to ensure SSL was working properly from the command line first before trying to get replication to use it via PRM’s automation that does the CHANGE MASTER for you. Eliminate the variables.

The customer provided me with the CA cert, the private key, and the server key, and this was already working on an existing environment with the same MySQL version. I had already added the relevant config options in the ‘mysqld’ section of the my.cnf:

Now, maybe the rest of the world finds it easy to understand the difference between the server and client keys and certs, and if you need all these options on the client side to connect with SSL to mysql, but I’ve always found it confusing. From what I can tell, the client-side key and cert is really only necessary if you need the server to authenticate the client. If you just need raw encryption without that validation, it’s enough to just give the client the CA cert:

However in my case, I immediately got the dreaded:

As is normally the case when one encounters this error, the following steps were taken (in no particular order, or many times in some cases):

• Checking the mysqld error log (clean as a whistle!)
• Trying to find an option for the mysql cli that will output the actual SSL error (nary to be found!)
• Running: SHOW VARIABLES LIKE ‘%ssl%’ (mysql was adamant that had openssl and ssl, and it had my SSL files correctly)
• Checking grants
• Double-checking the my.cnf for misspellings
• Restarting mysql
• Checking file perms of the ssl files
• Confirming that SSL worked fine on the old environment
• Contemplating a nice career in baking

I went through a variety of theories before I found the right one. They included:

• Something was just wrong with the SSL files
• This env was a major OS version newer than the old, but we were using the same MySQL packages built for the old OS, so maybe an openssl compatibility error
• This just wasn’t my day
• Maybe it was the chroot requirement

“Aha!”, you say. chroot, you fool, of course that’s the problem! And indeed it was, but I’m getting ahead of myself. How did I make such a revelation? Well, the openssl cli lets to setup a simple SSL client and server, which turns out to be a great way to verify your SSL environment and keys/certs are working properly. The basic test goes like this:

Источник

How can I resolve an ERROR 2026 SSL connection error when connecting to an Amazon RDS for MySQL or Aurora DB instance?

Last updated: 2021-02-10

I’m trying to connect to my Amazon Relational Database Service (Amazon RDS) DB instance or cluster using Secure Sockets Layer (SSL). I received the following error:

«ERROR 2026 (HY000): SSL connection error»

How can I resolve ERROR 2026 for Amazon RDS for MySQL, Amazon Aurora for MySQL, or Amazon Aurora Serverless?

Short description

There are three different types of error messages for ERROR 2026:

• ERROR 2026 (HY000): SSL connection error: SSL certificate validation failure
• ERROR 2026 (HY000): SSL connection error: Server doesn’t support SSL
• ERROR 2026 (HY000): SSL connection error: ASN: bad other signature confirmation

See the following troubleshooting steps for each error message.

Resolution

ERROR 2026 (HY000): SSL connection error: SSL certificate validation failure

To troubleshoot this error, first validate whether you’re using the cluster endpoint or the DB instance endpoint. To learn how Amazon RDS supports SSL, see Using SSL with a MySQL DB instance or Using SSL with Aurora MySQL DB clusters.

If you use a client that supports Subject Alternative Names (SAN), then you can use only the cluster endpoint. If your client doesn’t support SAN, you must use the endpoint of the primary DB instance.

Note: The default MySQL command line client doesn’t support SAN.

If you receive this error when trying to connect to the cluster endpoint, try connecting to the endpoint of the primary DB instance in the connection string. For example, you can connect to the cluster endpoint. In the following example, the cluster endpoint is abcdefg-clust.cluster-xxxx.us-east-1.rds.amazonaws.com. The DB instance endpoint is abcdefg-inst.xxxx.us-east-1.rds.amazonaws.com.

Connect using the cluster endpoint

Connect using the DB instance endpoint

ERROR 2026 (HY000): SSL connection error: Server doesn’t support SSL

You can receive this error if the server or engine version that you use doesn’t support SSL. To resolve this error, migrate to an engine that supports SSL connections.

ERROR 2026 (HY000): SSL connection error: SSL_CTX_set_default_verify_paths failed or ERROR 2026 (HY000): SSL connection error: ASN: bad other signature confirmation

You can receive this error if the certificate identifier (certificate file name) isn’t correct. You can also receive this error if the certificate identifier isn’t supported by the MySQL client, for example with Aurora Serverless. If you use Aurora Serverless clusters and you use the MySQL client to connect to Aurora Serverless, then you must use the MySQL 8.0-compatible MySQL commands.

Be sure to use the correct certificate identifier name and the correct path to the certificate to connect successfully. Before connecting, confirm that you have downloaded the correct certificate. For more information, see Using SSL to encrypt a connection to a DB instance.

The root certificate file is in the Downloads directory in an Amazon Elastic Compute Cloud (Amazon EC2) instance. In the following example, you enter the incorrect path, which results in ERROR 2026:

Note: This example uses the connection string in the home directory, but the root certificate is in the Downloads directory.

In the following example, you use the path to the root certificate to connect successfully:

You can also receive this error if you don’t have permissions to the directory that the certificate is stored in. Be sure that the certificate is in a directory that you have permissions to access. See the following examples to connect with and without permissions:

Источник

SSL Connection to MySQL 8.0.16 fails

We updated our MySQL-Server to 8.0.16 and I am not able to establish an SSL connection to the server. I am getting the following error message:

SSL connection error: The message received was unexpected or badly formatted

It is noteworthy that I had the same issue with the MySQL Workbench 6.3 CE, there was also some SSL-handshake-related error when connecting but after updating to the latest version 8.0 CE I can establish the connection again.

HeidiSQL Official release 10.1.0.5464

I investigated this issue with our database administrator and the issue is the TLS version and has most likely nothing to do with the MySQL version.

Formerly we had no specifics about the TLS version. Now the server is configured with tls_version=TLSv1.2 and HeidiSQL is not able to build up a TSL 1.2 connection. After disabling this configuration I was able to connect again. But since our administrator does not want to disable this configuration in production (in fact he would force TLS 1.3 if MySQL would support it without additional software) I am in desparate need of HeidiSQL supporting TLS 1.2.

Please look up in your HeidiSQL application directory, e.g. c:Program FilesHeidiSQL — whether you have libmariadb.dll and libmysql.dll in there, and via rightclick on them, then click on «Details», find the version of both. Please post these version numbers here, so I can verify they were updated by your installation. libmariadb.dll should have v3.0.8, while libmysql.dll should have v5.6.6.0 .

Normally, HeidiSQL uses libmariadb.dll, even when connecting to MySQL. libmysql.dll is just left for backwards compatibility.

In the meantime there is libmariadb.dll v3.0.10, but the changelogs don’t say a word about TLS 1.2 support, and I can’t believe it’s the library which is outdated. There must be some setting, maybe one which I can set via mysql_options()

I found they seem to work on TLS 1.2 support in MariaDB’s connector: https://github.com/MariaDB/mariadb-connector-c

So you could give it a try and delete libmariadb.dll or rename it before you start heidisql.exe. Then HeidiSQL should fall back to use libmysql.dll and you will see if there is support for TLS1.2.

But I’m unsure whether there is a todo for me in HeidiSQL. There is the MARIADB_OPT_TLS_VERSION setting, which I probably have to set when connecting.

Set MARIADB_OPT_TLS_VERSION to define which TLS protocol versions are allowed. See https://www.heidisql.com/forum.php?t=27158

I just pushed 51da7c8e which probably support TLS up to v1.3. Please update to the next build and report back if that works for you.

Thanks for your quick help.

Now I can connect with TLS 1.2 but connecting to the «old» server without the configuration is not possible anymore. It given the error message

SSL connection error: The message received was unexpected or badly formatted

Your above tip with using the fallback libmysql.dll did not work for the Official release version. I still was not able to connect with TLS 1.2.

Ok, then what TLS version is your old server running? Heidi now allows «TLSv1.0,TLSv1.1,TLSv1.2,TLSv1.3» — while I read of another writing for «TLSv1», which is probably the cause.

SHOW SESSION STATUS LIKE ‘ Ssl_version ‘ yields TLSv1.1

I have same problem, but MySQL has not updated (5.7.26), only HeidiSQL has updated about 3 days ago.

Test with MariaDB 10.3.15 is perfect.

SHOW SESSION STATUS LIKE ‘Ssl_version’ TLSv1

Ok, so lascjr has «TLSv1» running, while HeidiSQL tries to support «TLSv1.0» — I should maybe remove that trailing «.0» or add «TLSv1» to the comma separated list.

Hi ansgar, problem still with revision 5579

I just fixed the wrong writing to «TLSv1». Please update to the next nightly build (5580) and report back if that works now.

In revision 5580, the error message has changed, now is: Unknown SSL error (0x80090308)

Hm shit. So to summarize things: you formerly said

Test with MariaDB 10.3.15 is perfect

So what exactly does not work yet? Is it probably the same as mf posted:

Now I can connect with TLS 1.2 but connecting to the «old» server without the configuration is not possible anymore.

And if so, what server version is it exactly? I cannot reproduce that here, on various servers with no tls_version configuration. So we need to be most exact here, with as many details as you have.

I tested the following HeidiSQL versions (all 64 Bit):

• 10.1.0.5464 — latest official release
• 10.1.0.5572 — 1 revision before MARIADB_OPT_TLS_VERSION
• 10.1.0.5573 — MARIADB_OPT_TLS_VERSION fix
• 10.1.0.5579 — 1 revision before TLSv1
• 10.1.0.5580 — TLSv1 fix

MySQL server 5.7.22-log (variable tls_version : TLSv1,TLSv1.1 , status Ssl_version : TLSv1.1 )

• 5464 connectable
• 5572 connectable
• 5573 SSL connection error: The message received was unexpected or badly formatted
• 5579 SSL connection error: The message received was unexpected or badly formatted
• 5580 Unkonown SSL error (0x80090308)

MySQL server 8.0.16 (variable tls_version : TLSv1.2 , status Ssl_version : TLSv1.2 )

• 5464 SSL connection error: The message received was unexpected or badly formatted
• 5572 SSL connection error: The message received was unexpected or badly formatted
• 5573 connectable
• 5579 connectable
• 5580 connectable

With libmysql.dll instead of libmariadb.dll I get on all Heidi versions:

• MySQL 5.7.22-log connectable
• MySQL 8.0.16 SSL connection error: unknown error number

We created you a user on our test databases. I will send you the credentials via e-mail.

MariaDB 10.3.15 — is perfect work MySQL 5.7.26 — Unknown SSL error (0x80090308)

@mf — thanks a lot for consistent testing results! I’m sure this helps. Also thanks for the credentials you sent me.

Use full path when loading libmariadb.dll or libmysql.dll, so we don’t accidentally prefer a libmariadb.dll somewhere on the users harddisk over the local libmysql.dll. Only if that also fails, fall back to load it from somewhere else. This hopefully helps for debugging SSL connection problems. See https://www.heidisql.com/forum.php?t=27158#p27219

Ok, found out a few things:

• removing the MARIADB_OPT_TLS_VERSION option call fixes connecting to 5.7 with SSL, but fails for 8.0 (this is what you already found out with your tests, mf)
• it makes no difference to additionally set MYSQL_OPT_TLS_VERSION , with any library.
• removing libmariadb.dll did not necessarily cause HeidiSQL to load libmysql.dll from its directory. Instead — if you have another libmariadb.dll on your harddisk and in your path (like me), that one was preferred. This was an issue I just fixed for the next build: the local libmysql.dll now has precedence over another libmariadb.dll or libmysql.dll on your system.
• you did not encounter that issue, so you likely do not have a MariaDB server installed locally
• finally my testing results are consistent with yours — and we still have a problem with a default installation connecting with SSL on 5.7
• I had the idea to offer a new advanced setting for the session, where the user can select the library to use. But that would be awful, as most users won’t know what to select here.

• I had the idea to offer a new advanced setting for the session, where the user can select the library to use. But that would be awful, as most users won’t know what to select here.

It’s not such a bad idea. In summary, there are only two libraries.

I could leave it with a checkbox automatically, and the option, distilling the checkbox in manual, to choose the library.

I found there is a parallel discussion in issue #519, so let’s please proceed there with comments. The reporter closed the issue, but that was probably by mistake.

Also, there is a ticket on https://jira.mariadb.org/browse/MDEV-13492 about that «Unknown SSL error». Probably that will also be helpful to solve this here.

How to resolve hp error code 0xc0000185? if you have any idea then, please share.

Please login to leave a reply, or register at first.

Источник

AWS shows ERROR 2026 (HY000): SSL connection error while trying to connect to Amazon Relational Database Service (Amazon RDS) DB instance or cluster using Secure Sockets Layer (SSL).

Here, at Bobcares, we assist our customers with several AWS queries as part of our AWS Support Services.

Today, let us see how to troubleshoot this error in different scenarios.

ERROR 2026 (HY000): SSL connection error

Generally, there are three different types of error messages for ERROR 2026.

Moving ahead, let us see the troubleshooting steps for each error message.

ERROR 2026 (HY000): SSL connection error: SSL certificate validation failure

In this case, initially, we validate we use the cluster endpoint or the DB instance endpoint.

Suppose we receive this error when trying to connect to the cluster endpoint. Then we try the endpoint of the primary DB instance in the connection string.

For example, we can connect to the cluster endpoint. Here, the cluster endpoint is abcdefg-clust.cluster-xxxx.us-east-1.rds.amazonaws.com. The DB instance endpoint is abcdefg-inst.xxxx.us-east-1.rds.amazonaws.com.

• Connect using the cluster endpoint:

[ec2-user@ip-192-0-2-0 ~]$ mysql -h abcdefg-clust.cluster-xxxx.us-east-1.rds.amazonaws.com --ssl-ca rds-combined-ca-bundle.pem --ssl-mode=VERIFY_IDENTITY -u test -p test
Enter password:
ERROR 2026 (HY000): SSL connection error: SSL certificate validation failure

• Connect using the DB instance endpoint:

[ec2-user@ip-192-0-2-0 ~]$ mysql -h abcdefg-inst.xxxx.us-east-1.rds.amazonaws.com --ssl-ca rds-combined-ca-bundle.pem
--ssl-mode=VERIFY_IDENTITY -u test -p test
Enter password:
Welcome to the MySQL monitor. Commands end with ; or g.
Your MySQL connection id is 26

ERROR 2026 (HY000): SSL connection error: Server doesn’t support SSL

On the other hand, we may receive this error if the server or engine version we use doesn’t support SSL.

To resolve this error, we migrate to an engine that supports SSL connections.

ERROR 2026 (HY000): SSL connection error: ASN: bad other signature confirmation

An incorrect certificate identifier can result in this error.

In addition, there is a possibility of this error if the MySQL client does not support the certificate identifier.

Ensure correct certificate identifier name and the correct path to the certificate to connect successfully. We confirm we have the correct certificate before proceeding to connect.

The root certificate file is in the Downloads directory in an Amazon EC2 instance.

For example, an incorrect path below results in ERROR 2026:

[ec2-user@ip-192-0-2-0 ~]$ mysql -h abcdefg-clust.cluster-xxxxx.us-east-1.rds.amazonaws.com --ssl-ca rds-combined-ca-bundle.pem --ssl-mode=VERIFY_IDENTITY -u test -p test
Enter password:
ERROR 2026 (HY000): SSL connection error: SSL_CTX_set_default_verify_paths failed

In the following example, we use the correct path to the root certificate and it connects successfully:

[ec2-user@ip-192-0-2-0 ~]$ mysql -h abcdefg-clust.cluster-xxxx.us-east-1.rds.amazonaws.com --ssl-ca /home/ec2-user/Downloads/rds-combined-ca-bundle.pem
--ssl-mode=VERIFY_IDENTITY -u test -p test
Enter password:
Welcome to the MySQL monitor. Commands end with ; or g.
Your MySQL connection id is 26

On the other hand, we may receive this error if we don’t have permission to the directory that the certificate is stored in. So we ensure the certificate is in a directory that we have permission to access.

See the following examples to connect with and without permissions:

• Connect with insufficient permissions:

[ec2-user@ip-192-0-2-0 ~]$ sudo chmod 700 rds-combined-ca-bundle.pem 
[ec2-user@ip-192-0-2-0 ~]$ mysql -h abcdefg-inst.xxxx.us-east-1.rds.amazonaws.com --ssl-ca rds-combined-ca-bundle.pem --ssl-mode=VERIFY_IDENTITY -u test -p test
Enter password: 
ERROR 2026 (HY000): SSL connection error: SSL_CTX_set_default_verify_paths failed

• Connect with the correct permissions:

[ec2-user@ip-192-0-2-0 ~]$ sudo chmod 755 rds-combined-ca-bundle.pem
[ec2-user@ip-192-0-2-0 ~]$ mysql -h abcdefg-inst.xxxx.us-east-1.rds.amazonaws.com --ssl-ca rds-combined-ca-bundle.pem --ssl-mode=VERIFY_IDENTITY -u test -p test
Enter password:
Welcome to the MySQL monitor. Commands end with ; or g.
Your MySQL connection id is 810

[Stuck with the connections? We’d be happy to help you]

Conclusion

In short, we saw how our Support Techs fix the AWS ERROR 2026 (HY000): SSL connection error.

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;