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

SST silly issue, it seems verify only is concatenated with the certificate name

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 10.1.34
    • Fix Version/s: 10.1
    • Component/s: Galera SST
    • Labels:
      None

      Description

      Folks,

      The error being discussed here is:

      WSREP_SST: [INFO] Evaluating mbstream -c ${INFO_FILE} | socat -u stdio openssl-connect:db02:4444,cert=/etc/my.cnf.d/certs/server-cert.pem,key=/etc/my.cnf.d/certs/server-key.pem,cafile=/etc/my.cnf.d/certs/ca-cert.pemverify=0; RC=( ${PIPESTATUS[@]} ) (20180629 19:48:28.728)
      2018/06/29 19:48:28 socat[7166] E SSL_CTX_load_verify_locations(): error:02001002:system library:fopen:No such file or directory
      

      Just having a new fight with the SST + SSL with MariaDB Server 10.1.34. I've got this working without disabling the certificates verification executed by the latest version of socat when default enables the verify option. As the names for the new machines I'm working with are longer than before, it seems the CN cannot be tested, and that means, I'm using the sockopts under the [sst] section to disable the socat SSL verification when the certification CN (commonName) should be equal to the hostname.

      By the way, I have this below on my configuration file for a new cluster:

      [sst]
      progress=1
      time=1
      encrypt = 3
      tca     = /etc/my.cnf.d/certs/ca-cert.pem
      tkey    = /etc/my.cnf.d/certs/server-key.pem
      tcert   = /etc/my.cnf.d/certs/server-cert.pem
      sockopt = "verify=0"
      

      When having the sockopt = "verify=0", I wonder if the error about a file not found is not related to the concatenation of the option verify=0 with the name of the ca certificate...

      I can tweak the script and adjust it, but, how many will have the same problem as I'm having right now?

      Thanks, folks!

        Attachments

          Activity

            People

            • Assignee:
              jplindst Jan Lindström
              Reporter:
              wagnerbianchi Wagner Bianchi
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: