Uploaded image for project: 'MariaDB Connector/C'
  1. MariaDB Connector/C
  2. CONC-538

Can't connect via SSL

Details

    • Bug
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • 3.1.11, 3.1.12
    • None
    • TLS/SSL
    • None
    • Server: Binary package mariadb-10.5.9-linux-systemd-x86_64 on Debian buster
      Client: Windows 10 mariadb-connector-c 3.1.12 / 3.1.11

    Description

      I have a serious problem to SSL connect the mariadb server instance.

      The server is a binary package mariadb-10.5.9-linux-systemd-x86_64 on Debian buster.
      The client is running on latest Windows 10 64 bit, mariadb-connector-c 3.1.12 / 3.1.11

      The according SSL certificates are standard, self-signed and generated after this manual:
      https://mariadb.com/kb/en/certificate-creation-with-openssl/ on the server.
      Verification of the client/server certs are fine.

      SSL connecting using Windows DBeaver (v21.0.1) works fine, DBeaver uses mariadb-connector-J internally. So it proofs, that server and the certs are fine.

      I compiled and tried the latest mariadb-connector-c (3.1.12) which gives the following error:
      SSL connection error: An unknown error occurred while processing the certificate. Error 0x80090327(SEC_E_CERT_UNKNOWN)
      Given are client-key.pem, client-cert.pem and ca-cert.pem. ca-folder and ciphers are null (unused).

      I tried the same with latest HeidiSQL which uses an older libmariadb.dll version (3.1.7). But same error here.

      So I suspect, there's a SSL problem, perhaps in using Schannel.
      The error code above gives:

      0x80090327
      This error translates to "An unknown error occurred while processing the certificate."
      This usually means that the server requires SSL client authentication and a new certificate is specified. Check the SSLStatus Event for details.

      Attachments

        1. ca-cert.pem
          1 kB
        2. client-cert.pem
          1 kB
        3. client-key.pem
          2 kB
        4. server-cert.pem
          1 kB
        5. server-key.pem
          2 kB

        Issue Links

          relates to

          Task - A task that needs to be done. MDEV-25701 Two-way TLS does not work with WolfSSL and version1 certificates

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            georg Georg Richter added a comment -

            Can you please check if the connection works without client certificates?

            georg Georg Richter added a comment - Can you please check if the connection works without client certificates?
            mpaland Marco Paland added a comment -

            Without client-cert and client-key (just ca-cert given) the connection works.
            You are right, normally, only ca-cert (or server-cert) should be fine to connect the client.
            I just thought, client-cert and key are mandatory params.
            Does it have any drawbacks not to use the client-cert?

            Anyway, IMHO wouldn't it be more consistent to use WolfSSL as TLS lib?
            mariadb server is using it and it would be the same code basis for connector-c on different platforms.

            mpaland Marco Paland added a comment - Without client-cert and client-key (just ca-cert given) the connection works. You are right, normally, only ca-cert (or server-cert) should be fine to connect the client. I just thought, client-cert and key are mandatory params. Does it have any drawbacks not to use the client-cert? Anyway, IMHO wouldn't it be more consistent to use WolfSSL as TLS lib? mariadb server is using it and it would be the same code basis for connector-c on different platforms.
            georg Georg Richter added a comment -

            Client certificate is only required, if the user account was defined with REQUIRE X509, in this case client will send certificate to the server.
            WolfSSL can't be used with MariaDB Connector/C since licenses are not compatible (LGPL vs. GPL)

            However it would be good to know what exactly fails. If these are self signed certificates, do you mind to attach them to this report?

            georg Georg Richter added a comment - Client certificate is only required, if the user account was defined with REQUIRE X509, in this case client will send certificate to the server. WolfSSL can't be used with MariaDB Connector/C since licenses are not compatible (LGPL vs. GPL) However it would be good to know what exactly fails. If these are self signed certificates, do you mind to attach them to this report?
            mpaland Marco Paland added a comment -

            Georg, thanks a lot for giving advice here.

            I uploaded the according test files.
            REQUIRE X509 or REQUIRE SSL on the according 'ssluser' doesn't make a difference concerning the error result.

            Yes, too bad that WolfSSL can't be used, I didn't notice its license.

            mpaland Marco Paland added a comment - Georg, thanks a lot for giving advice here. I uploaded the according test files. REQUIRE X509 or REQUIRE SSL on the according 'ssluser' doesn't make a difference concerning the error result. Yes, too bad that WolfSSL can't be used, I didn't notice its license.
            georg Georg Richter added a comment -

            With fix of CONC-527 I'm not able to reproduce this error anymore, even if the alter codes (71 vs. 42 or 43) were different.

            georg Georg Richter added a comment - With fix of CONC-527 I'm not able to reproduce this error anymore, even if the alter codes (71 vs. 42 or 43) were different.

            People

              georg Georg Richter
              mpaland Marco Paland
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.