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

Parsing of forward slash '/' behaving differently between OpenSSL 3 vs OpenSSL 1

    XMLWordPrintable

Details

    • Can result in unexpected behaviour
    • Hide
      MariaDB matches a client certificate against a REQUIRE ISSUER/REQUIRE SUBJECT value exactly, but SSL libraries render a / or + inside a certificate field differently: OpenSSL 3.0+ escapes it with a backslash, OpenSSL 1.1/WolfSSL don't. So a working grant could silently stop matching after an SSL library change.

      The new old_mode value X509_LENIENT_COMPARE restores it: on a failed exact match, it also accepts the value with that escaping added or removed.
      It's primarily meant to be a migration aid, rather than permanent setting — while enabled, a literal backslash before / or + in a certificate field can no longer be told apart from an escaped separator, making REQUIRE less precise.
      Show
      MariaDB matches a client certificate against a REQUIRE ISSUER/REQUIRE SUBJECT value exactly, but SSL libraries render a / or + inside a certificate field differently: OpenSSL 3.0+ escapes it with a backslash, OpenSSL 1.1/WolfSSL don't. So a working grant could silently stop matching after an SSL library change. The new old_mode value X509_LENIENT_COMPARE restores it: on a failed exact match, it also accepts the value with that escaping added or removed. It's primarily meant to be a migration aid, rather than permanent setting — while enabled, a literal backslash before / or + in a certificate field can no longer be told apart from an escaped separator, making REQUIRE less precise.
    • Q3/2026 Server Development, Q4/2026 Server Maintenance

    Description

      OpenSSL 1 vs 3 difference in escaping for ISSUER string complicating migration from 1 to 3

      Migration to MariaDB + a supported SSL lib needed a solution to the problem of MariaDB+OpenSSL 1 behaving differently in parsing/matching the ISSUER compared to MariaDB+OpenSSL 3. WolfSSL behaves the same as OpenSSL 1 in this regard.

      As there is no way to make the same user compatible on both OpenSSL versions given Issuer string has forward slashes and with OpenSSL 3 MariaDB compares a version with escapes to the stored version without escapes (and without escapes works with OpenSSL1, with escapes breaks with OpenSSL 1).

      Apparently it comes down to the use of “X509_NAME_oneline” which behaviour has changed and is not recommended to use in general. See https://manpages.opensuse.org/Leap-15.6/openssl-3-doc/X509_NAME_oneline.33ssl.en.html#NOTES.

      Basically the same issue described here: https://bugs.mysql.com/bug.php?id=120912&utm_source=chatgpt.com

      Attached is a docker based reproduction of the issue.

      Patch context (patch itself in attachments):
      Patch was applied against MariaDB Community Server 10.6.22 source (mariadb-10.6.22.tar.gz from archive.mariadb.org; Git tag mariadb-10.6.22), file sql/sql_acl.cc, function acl_check_ssl (the strcmp on X509_NAME_oneline() for issuer at line 14235 and subject at line 14252).

      Attachments

        2. Screenshot 2026-08-30 at 17.05.15.png
          48 kB
          Koustuv Chatterjee
        3. sql_acl-x509-oneline-cmp.patch
          2 kB
          Koustuv Chatterjee

        Activity

          People

            wlad Vladislav Vaintroub
            Koustuv Koustuv Chatterjee
            Votes:
            0 Vote for this issue
            Watchers:
            10 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Time Tracking

                Estimated:
                Original Estimate - 1h 38m Original Estimate - 1h 38m
                1h 38m
                Remaining:
                Remaining Estimate - 0d
                0d
                Logged:
                Time Spent - 2d 2h 10m
                2d 2h 10m

                Git Integration

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