Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-34730

Validation of SSL server certificate fails with non-selfsigned certificate

Details

    Description

      We are using wildcard certificate and we are getting error, while connecting to localhost or even connecting to UNIX socket.

      ERROR 2026 (HY000): TLS/SSL error: Validation of SSL server certificate failed
      

      There is no problem when we disable ssl_key, ssl_cert and ssl_ca settings and server is generating selfsigned cert. (but this will break old clients certificate validation?)

      Why localhost connection is validating certificate?
      Why UNIX socket connection is validating certificate?
      Why UNIX socket connection using SSL?

      Attachments

        Issue Links

          Activity

            The only reason I can think of is to not break existing applications that use

            CREATE USER ... REQUIRE { SSL | X509 | CIPHER 'cipher' | ISSUER 'issuer' | SUBJECT 'subject'
            

            And because TLS is established before the user name is known, the server cannot force TLS only for those users that REQUIRE it.

            serg Sergei Golubchik added a comment - The only reason I can think of is to not break existing applications that use CREATE USER ... REQUIRE { SSL | X509 | CIPHER 'cipher' | ISSUER 'issuer' | SUBJECT 'subject' And because TLS is established before the user name is known, the server cannot force TLS only for those users that REQUIRE it.

            On the other hand, the server can ignore REQUIRE SSL and REQUIRE X509 over a secure connection, just pretend it's satisfied. May be REQUIRE CIPHER too (this is questionable).

            And REQUIRE ISSUER and REQUIRE SUBJECT check the client side certificate. So the client only needs to establish TLS if it has a certificate or a connection is potentially MitM-able.

            serg Sergei Golubchik added a comment - On the other hand, the server can ignore REQUIRE SSL and REQUIRE X509 over a secure connection, just pretend it's satisfied. May be REQUIRE CIPHER too (this is questionable). And REQUIRE ISSUER and REQUIRE SUBJECT check the client side certificate . So the client only needs to establish TLS if it has a certificate or a connection is potentially MitM-able.
            erkia Erki Aring added a comment - - edited

            I've done some more tests and it seems my assumption, that TLS over UNIX socket is a new thing in 11.4, was wrong. Even earlier MariaDB versions are using TLS over UNIX socket, when `ssl_key`, `ssl_cert` and `ssl_ca` configuration is used, with an exception that server certificate is not verified by default.

            This indeed makes it possible that there are existing applications, which were successfully using `REQUIRE SSL` while connecting through UNIX socket and disabling TLS altogether (like my PR) would break them.

            In that sense, I understand, that not checking TLS hostname for non-MitM-able connections is probably the easiest and safest fix.

            I'm not sure about making UNIX socket satisfy `REQUIRE SSL`. For me it would be enough to have a way to disable TLS over UNIX socket by default (without extra command-line options) and keep living my simple life with local connections and no `REQUIRE SSL`-s. I still like the idea of having TLS over TCP/IP by default, so I don't want to disable that.

            erkia Erki Aring added a comment - - edited I've done some more tests and it seems my assumption, that TLS over UNIX socket is a new thing in 11.4, was wrong. Even earlier MariaDB versions are using TLS over UNIX socket, when `ssl_key`, `ssl_cert` and `ssl_ca` configuration is used, with an exception that server certificate is not verified by default. This indeed makes it possible that there are existing applications, which were successfully using `REQUIRE SSL` while connecting through UNIX socket and disabling TLS altogether (like my PR) would break them. In that sense, I understand, that not checking TLS hostname for non-MitM-able connections is probably the easiest and safest fix. I'm not sure about making UNIX socket satisfy `REQUIRE SSL`. For me it would be enough to have a way to disable TLS over UNIX socket by default (without extra command-line options) and keep living my simple life with local connections and no `REQUIRE SSL`-s. I still like the idea of having TLS over TCP/IP by default, so I don't want to disable that.
            georg Georg Richter added a comment -

            Since the current implementation of Connector/C 3.4 accepts self signed certificates for local connections which are considered secure (unix socket, 127.0.0.1, ::1) we should disable hostname verification for these connections too.

            Other checks such as revocation or time period validity checks should still be performed for secure connections

            georg Georg Richter added a comment - Since the current implementation of Connector/C 3.4 accepts self signed certificates for local connections which are considered secure (unix socket, 127.0.0.1, ::1) we should disable hostname verification for these connections too. Other checks such as revocation or time period validity checks should still be performed for secure connections
            noonedeadpunk Dmitriy Rabotyagov added a comment - - edited

            Folks, I don't want to disappoint you, but it seems there's still issue left, now I can see it only in mariabackup only in 11.4.4. I've created a separate bug report for it: MDEV-35368

            noonedeadpunk Dmitriy Rabotyagov added a comment - - edited Folks, I don't want to disappoint you, but it seems there's still issue left, now I can see it only in mariabackup only in 11.4.4. I've created a separate bug report for it: MDEV-35368

            People

              georg Georg Richter
              BB Silver Asu
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

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