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

SST + SSL/TLS broken due to socat CN check

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Not a Bug
    • 10.1.28
    • N/A
    • Galera SST
    • None
    • CentOS 7.2

    Description

      Folks,

      Configuring a running MariaDB Cluster 10.1.28 with self-signed SSL certs with different CNs cause the SST break due to socat 1.7.3 which has extra certificate check introduced:

      WSREP_SST: [INFO] Evaluating mbstream -c ${INFO_FILE} | socat -u stdio openssl-connect:192.168.50.15: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.pem; RC=( ${PIPESTATUS[@]} ) (20180313 21:08:36.885)
      		 
      2018/03/13 21:08:36 socat[25873] E certificate is valid but its commonName does not match hostname

      Is there any treatment that can be done to avoid this issue, adding, e.g. --verify=0?

      After generating the certificates:

      $ openssl verify -CAfile ca-cert.pem server-cert.pem client-cert.pem
      		 
      server-cert.pem: OK
      		 
      client-cert.pem: OK

      Attachments

        Issue Links

          relates to

          New Feature - A new feature of the product, which has yet to be developed. MDEV-16219 mariadb ssl_rsa_setup maintenance tool with galera option would accelerate tls deployment on galera cluster

          • Major - Major loss of function.
          • Open

          Activity

            Ascending order - Click to sort in descending order
            wagnerbianchi Wagner Bianchi (Inactive) added a comment -

            Folks,

            I managed to create certificates in a way it can comply with the new verify option enabled by default within the new socat version. This is a matter of creating the CA and the client certificates ion one of the server/nodes, part of the cluster and rsync them to all other nodes. Go to each of the nodes and create local server cert based on the previously created CA certificate. Doing this way, you can fill up the CN or CommonName field during the process of the certificate creation with the server name. Wildcard certificates are not well supported as I tested that before coming to this solution.

            #: success logs
            		 
            WSREP_SST: [INFO] WARNING: Stale temporary SST directory: /var/lib/mysql//.sst from previous state transfer. Removing (20180504 21:29:55.652)
            		 
            WSREP_SST: [INFO] Proceeding with SST (20180504 21:29:55.657)
            		 
            WSREP_SST: [INFO] Evaluating socat -u openssl-listen:4444,reuseaddr,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.pem stdio | mbstream -x; RC=( ${PIPESTATUS[@]} ) (20180504 21:29:55.659)
            		 
            WSREP_SST: [INFO] Cleaning the existing datadir and innodb-data/log directories (20180504 21:29:55.661)
            		 
            removed ‘/var/lib/mysql/mariadb-bin.index’
            		 
            removed ‘/var/lib/mysql/aria_log_control’
            		 
            removed ‘/var/lib/mysql/aria_log.00000001’
            		 
            removed ‘/var/lib/mysql/ibdata1’
            		 
            removed ‘/var/lib/mysql/ib_logfile1’
            		 
            removed ‘/var/lib/mysql/ib_logfile0’
            		 
            removed ‘/var/lib/mysql/mariadb-bin.000001’
            		 
            removed ‘/var/lib/mysql/mysql.sock’
            		 
            removed ‘/var/lib/mysql/mariadb-bin.state’
            		 
            WSREP_SST: [INFO] Waiting for SST streaming to complete! (20180504 21:29:55.717)

            So, with that said, we can close this JIRA, thanks!

            wagnerbianchi Wagner Bianchi (Inactive) added a comment - Folks, I managed to create certificates in a way it can comply with the new verify option enabled by default within the new socat version. This is a matter of creating the CA and the client certificates ion one of the server/nodes, part of the cluster and rsync them to all other nodes. Go to each of the nodes and create local server cert based on the previously created CA certificate. Doing this way, you can fill up the CN or CommonName field during the process of the certificate creation with the server name. Wildcard certificates are not well supported as I tested that before coming to this solution. #: success logs WSREP_SST: [INFO] WARNING: Stale temporary SST directory: /var/lib/mysql //.sst from previous state transfer. Removing (20180504 21:29:55.652) WSREP_SST: [INFO] Proceeding with SST ( 20180504 21 : 29 : 55.657 ) WSREP_SST: [INFO] Evaluating socat -u openssl-listen: 4444 ,reuseaddr,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.pem stdio | mbstream -x; RC=( ${PIPESTATUS[@]} ) ( 20180504 21 : 29 : 55.659 ) WSREP_SST: [INFO] Cleaning the existing datadir and innodb-data/log directories ( 20180504 21 : 29 : 55.661 ) removed ‘/var/lib/mysql/mariadb-bin.index’ removed ‘/var/lib/mysql/aria_log_control’ removed ‘/var/lib/mysql/aria_log. 00000001 ’ removed ‘/var/lib/mysql/ibdata1’ removed ‘/var/lib/mysql/ib_logfile1’ removed ‘/var/lib/mysql/ib_logfile0’ removed ‘/var/lib/mysql/mariadb-bin. 000001 ’ removed ‘/var/lib/mysql/mysql.sock’ removed ‘/var/lib/mysql/mariadb-bin.state’ WSREP_SST: [INFO] Waiting for SST streaming to complete! ( 20180504 21 : 29 : 55.717 ) So, with that said, we can close this JIRA, thanks!
            minorOffense Mathew Winstone added a comment -

            If you follow the docs and pass 'tca' with encrypt 3 it would appear that triggers socat to validate the certs. If you omit 'tca' it seems to just use the certificates.

            I'm using 10.3 and my state transfers appear to be working so long as I omit tca.

            minorOffense Mathew Winstone added a comment - If you follow the docs and pass 'tca' with encrypt 3 it would appear that triggers socat to validate the certs. If you omit 'tca' it seems to just use the certificates. I'm using 10.3 and my state transfers appear to be working so long as I omit tca.

            People

              jplindst Jan Lindström (Inactive)
              wagnerbianchi Wagner Bianchi (Inactive)
              Votes:
              2 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.