Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
3.1.9
-
None
-
None
Description
We were not able to configure ssl while attempting to configure MariaDB to use intermediate ssl certificates.
During troubleshooting, we found the following ltrace:
[pid 23468] SSL_CTX_load_verify_locations(0x562c35a6bb70, 0, 0, 0) = 0
|
[pid 23468] SSL_CTX_set_default_verify_paths(0x562c35a6bb70, 0, 0, 0) = 1
|
[pid 23468] SSL_CTX_use_certificate_chain_file(0x562c35a6bb70, 0x562c35a57780, 0x562c35a28010, 2) = 1
|
[pid 23468] SSL_use_certificate_file(0x562c35a6d720, 0x562c35a57780, 1, 3) = 1
|
[pid 23468] fopen64("/etc/mysql/certs/client_tls_bund"..., "rb") = 0x562c35a6f3a0
|
What appears to be happening is that the MySQL client isn't using the vio implementation, it is using the libmariadb implementation in libmariadb/libmariadb/secure/openssl.c
The code for libmariadb/libmariadb/secure/openssl.c has the following sequence, which seem to prevent intermediate certs to work:
if (certfile && certfile[0] != 0)
|
{
|
if (SSL_CTX_use_certificate_chain_file(ctx, certfile) != 1 ||
|
SSL_use_certificate_file(ssl, certfile, SSL_FILETYPE_PEM) != 1)
|
goto error;
|
}
|
The viosslfactories.c implemetation has the following code instead:

if (cert_file && SSL_CTX_use_certificate_chain_file(ctx, cert_file) <= 0)
|
{
|
*error= SSL_INITERR_CERT;
|
DBUG_PRINT("error",("%s from file '%s'", sslGetErrString(*error), cert_file));
|
DBUG_EXECUTE("error", ERR_print_errors_fp(DBUG_FILE););
|
fprintf(stderr, "SSL error: %s from '%s'\n", sslGetErrString(*error),
|
cert_file);
|
fflush(stderr);
|
DBUG_RETURN(1);
|
}
|
The call to SSL_use_certificate_file appears to be incorrect, as it appears to blow away any work of SSL_CTX_use_certificate_chain_file.
There is a SSL_use_certificate_chain_file, but I suspect (but would need testing of course) that the right move would be to just remove the call to SSL_use_certificate_file entirely?
In the interim, we were able to make it work by bundling them on the server, just not by bundling them on the client. This however defeats the purpose of this solution and it is 100% the opposite of best practices for TLS certificate deployments. This isn't what you're supposed to do.