MariaDB comes with a bundled version of wolfSSL that can be used with the MariaDB server. This is limited in a few ways:
- libmariadb, which is used by MariaDB clients, isn't set up to be built with wolfSSL. If the server is built with wolfSSL, libmariadb gets builts with GnuTLS.
- The wolfSSL version is tied to whatever version MariaDB has been bundled with.
- The bundled version isn't FIPS.
This port makes it so a system-installed version of wolfSSL can be used for both the server and libmariadb. This also makes it possible to use wolfSSL FIPS with MariaDB. This has been tested with both wolfSSL FIPS and non-FIPS 4.8.1.
- Configure wolfSSL with
./configure CPPFLAGS="-DRSA_MAX_SIZE=8196 -DFP_MAX_BITS=16384 -DNO_OLD_TIMEVAL_NAME -DWOLFSSL_MYSQL_COMPATIBLE -DWOLFSSL_AES_DIRECT -DKEEP_OUR_CERT -DHAVE_AES_ECB -DWOLFSSL_NO_DEF_TICKET_ENC_CB -DHAVE_EX_DATA" --enable-opensslall --enable-crl --enable-sessioncerts --enable-aesctr --enable-rsapss --enable-keygen --enable-des3
. Add--enable-debug
if you want to enable the debug version of wolfSSL. - Compile with
make
. - Install wolfSSL into /usr/local with
sudo make install
.
- Clone the MariaDB server GitHub repo with
git clone git@github.com:MariaDB/server.git mariadb-server
.cd mariadb-server
. - Check out the 10.5.11 tag with
git checkout mariadb-10.5.11
. - Set up the libmariadb submodule with
git submodule init && git submodule update
. - Patch the source code with
patch -p1 < mariadb-10.5.11.patch
, adjusting the path to the patch file accordingly. - Create a build directory with
mkdir build
andcd build
. - Configure MariaDB with
cmake -DWITH_SSL=system-wolfssl ..
. Add-DCMAKE_BUILD_TYPE=Debug
if debugging. Note that this configuration requires libwolfssl and the wolfSSL headers to be installed in a standard location that can be found by CMake (e.g. /usr/local). - Compile with
make
.
- The tests take a long time to run. We recommend running them in the background with
nohup
to prevent accidentally ending the tests prematurely:nohup mysql-test/mtr --force > test_errors.txt 2>&1 &
. You can then follow the test progress withtail -f test_errors.txt
.
main.ssl_cipher
: Fails due to the client trying to establish a TLS 1.3 connection with a non-TLS-1.3 cipher suite (TLS_RSA_WITH_AES_128_CBC_SHA
). Other TLS implementations may choose to use TLS 1.2 (which is also supported by the client in this case via the supported versions extension) based on the fact that the cipher isn't TLS 1.3. It looks like wolfSSL requires the client to use the highest TLS version in the client's supported versions extension from the client hello.main.openssl_1
: Fails because it's using a 512-bit RSA key that's also expired.main.tls_version
: Fails because the test is expecting TLS 1.1 to be used but TLS 1.2 is used instead.main.ssl_7937
: This test runs$MYSQL --ssl --ssl-verify-server-cert -e "call test.have_ssl()"
. Because no CA is specified, MariaDB sets the verify mode (viaSSL_CTX_set_verify
) toSSL_VERIFY_NONE
. During the handshake, OpenSSL will still check the server certificate and set theSSL
object'sverify_result
member accordingly. In this case, the certificate is self-signed, so it gets set toX509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN
. However, in OpenSSL's functiontls_process_server_certificate
, as long as the verify mode isSSL_VERIFY_NONE
, this error gets ignored and the connection proceeds successfully. Later, MariaDB checks the value ofverify_result
directly inma_tls_connect
because the flagCLIENT_SSL_VERIFY_SERVER_CERT
has been set (via--ssl-verify-server-cert
). Ifverify_result != X509_V_OK
, then MariaDB generates an error. In contrast to OpenSSL, wolfSSL won't check the cert and setverify_result
to an error value if the verify mode isSSL_VERIFY_NONE
. Because of this difference, theverify_result
isX509_V_OK
when the check inma_tls_connect
is performed. So, the OpenSSL case will fail, and the wolfSSL case will succeed.