Table of Contents
With an unencrypted connection between the MySQL client and the server, someone with access to the network could watch all your traffic and inspect the data being sent or received between client and server.
When you must move information over a network in a secure fashion, an unencrypted connection is unacceptable. To make any kind of data unreadable, use encryption. Encryption algorithms must include security elements to resist many kinds of known attacks such as changing the order of encrypted messages or replaying data twice.
MySQL supports secure (encrypted) connections between clients and the server using the TLS (Transport Layer Security) protocol. TLS is sometimes referred to as SSL (Secure Sockets Layer) but MySQL does not actually use the SSL protocol for secure connections because it provides weak encryption (see Section 6.3, “Secure Connection Protocols and Ciphers”).
TLS uses encryption algorithms to ensure that data received over a public network can be trusted. It has mechanisms to detect data change, loss, or replay. TLS also incorporates algorithms that provide identity verification using the X509 standard.
X509 makes it possible to identify someone on the Internet. In basic terms, there should be some entity called a “Certificate Authority” (or CA) that assigns electronic certificates to anyone who needs them. Certificates rely on asymmetric encryption algorithms that have two encryption keys (a public key and a secret key). A certificate owner can present the certificate to another party as proof of identity. A certificate consists of its owner's public key. Any data encrypted using this public key can be decrypted only using the corresponding secret key, which is held by the owner of the certificate.
MySQL can be compiled for secure-connection support using OpenSSL or yaSSL. For a comparison of the two packages, see Section 6.1, “OpenSSL Versus yaSSL” For information about the encryption protocols and ciphers each package supports, see Section 6.3, “Secure Connection Protocols and Ciphers”.
MySQL performs encryption on a per-connection basis, and use of
encryption for a given user can be optional or mandatory. This
enables you to choose an encrypted or unencrypted connection
according to the requirements of individual applications. For
information on how to require users to use encrypted connections,
see the discussion of the REQUIRE clause of the
CREATE USER statement in
CREATE USER Syntax. See also the description of the
require_secure_transport system
variable at Server System Variables
Several improvements were made to secure-connection support in MySQL 5.7. The following timeline summarizes the changes:
5.7.3: On the client side, an explicit
--ssl option is no longer
advisory but prescriptive. Given a server enabled to support
secure connections, a client program can require a secure
conection by specifying only the
--ssl option. The connection
attempt fails if a secure connection cannot be established.
Other --ssl-
options on the client side mean that a secure connection is
advisory (the connection attempt falls back to an unencrypted
connection if a secure connection cannot be established).
xxx
5.7.5: The server-side --ssl
option value is enabled by default.
For servers compiled using OpenSSL, the
auto_generate_certs and
sha256_password_auto_generate_rsa_keys
system variables are available to enable autogeneration and
autodiscovery of SSL/RSA certificate and key files at startup.
For certificate and key autodiscovery, if
--ssl is enabled and other
--ssl- options
are not given to configure secure connections explicitly, the
server attempts to enable support for secure connections
automatically at startup if it discovers the requisite
certificate and key files in the data directory.
xxx
5.7.6: The mysql_ssl_rsa_setup utility is
available to make it easier to manually generate SSL/RSA
certificate and key files. Autodiscovery of SSL/RSA files at
startup is expanded to apply to all servers, whether compiled
using OpenSSL or yaSSL. (This means that
auto_generate_certs need not be
enabled for autodiscovery to occur.)
If the server discovers at startup that the CA certificate is self-signed, it writes a warning to its error log. (The certificate will be self-signed if created automatically by the server or manually using mysql_ssl_rsa_setup.)
5.7.7: The C client library attempts to establish a secure connection by default whenever the server supports secure connections. This affects client programs as follows:
In the absence of an --ssl
option, the client falls back to an unencrypted connection
if a secure connection cannot be established.
To require a secure connection and fail if one cannot be
established, invoke the client with an explicit
--ssl option or a synonym
(--ssl=1,
--enable-ssl).
To use an unencrypted connection, invoke the client with an
--ssl=0 option or a synonym
(--skip-ssl,
--disable-ssl).
This change also affects subsequent releases of MySQL Connectors that are based on the C client library: Connector/C, Connector/C++, and Connector/ODBC.
5.7.8: The
require_secure_transport system
variable is available to control whether client connections to
the server must use some form of secure transport.
5.7.10: TLS protocol support is extended from TLSv1 to also
include TLSv1.1 and TLSv1.2. The
tls_version system variable on
the server side and
--tls-version option on the
client side enable the level of support to be selected. See
Section 6.3, “Secure Connection Protocols and Ciphers”.
5.7.11: MySQL client programs support an
--ssl-mode option that enables
you to specify the security state of the connection to the
server. The --ssl-mode option
comprises the capabilities of the client-side
--ssl and
--ssl-verify-server-cert
options. Consequently, both of those options are deprecated, to
be removed in MySQL 8.0.
Secure connections are available through the MySQL C API using the
mysql_ssl_set() and
mysql_options() functions. See
mysql_ssl_set(), and
mysql_options().
Replication uses the C API, so secure connections can be used between master and slave servers. See Setting Up Replication to Use Secure Connections.
It is also possible to connect securely from within an SSH connection to the MySQL server host. For an example, see Section 6.7, “Connecting to MySQL Remotely from Windows with SSH”.
MySQL can be compiled using OpenSSL or yaSSL, both of which enable secure conections based on the OpenSSL API:
MySQL Enterprise Edition binary distributions are compiled using OpenSSL. It is not possible to use yaSSL with MySQL Enterprise Edition.
MySQL Community Edition binary distributions are compiled using yaSSL.
MySQL Community Edition source distributions can be compiled using either OpenSSL or yaSSL (see Section 6.2, “Building MySQL with Support for Secure Connections”).
OpenSSL and yaSSL offer the same basic functionality, but MySQL distributions compiled using OpenSSL have additional features:
OpenSSL supports a wider range of encryption ciphers from
which to choose for the
--ssl-cipher option. OpenSSL
supports the --ssl-capath,
--ssl-crl, and
--ssl-crlpath options. See
Section 6.5, “Command Options for Secure Connections”.
Accounts that authenticate using the
sha256_password plugin can use RSA key
files for secure password exchange over unencrypted
connections. See
Section 7.1.4, “The SHA-256 Authentication Plugin”.
The server can automatically generate missing SSL and RSA certificate and key files at startup. See Section 6.6.1, “Creating SSL and RSA Certificates and Keys using MySQL”.
OpenSSL supports more encryption modes for the
AES_ENCRYPT() and
AES_DECRYPT() functions. See
Encryption and Compression Functions
Certain OpenSSL-related system and status variables are present only if MySQL was compiled using OpenSSL:
auto_generate_certs (added in
MySQL 5.7.5)
sha256_password_auto_generate_rsa_keys
(added in MySQL 5.7.5)
To determine whether your server was compiled using OpenSSL, test the existence of any of those variables. For example, this statement returns a row if OpenSSL was used and an empty result if yaSSL was used:
SHOW STATUS LIKE 'Rsa_public_key';
Such tests assume that your server version is not older than the
first appearance of the variable tested. For example, you cannot
test for auto_generate_certs
before MySQL 5.7.6.
To use SSL connections between the MySQL server and client programs, your system must support either OpenSSL or yaSSL:
MySQL Enterprise Edition binary distributions are compiled using OpenSSL. It is not possible to use yaSSL with MySQL Enterprise Edition.
MySQL Community Edition binary distributions are compiled using yaSSL.
MySQL Community Edition source distributions can be compiled using either OpenSSL or yaSSL.
If you compile MySQL from a source distribution, CMake configures the distribution to use yaSSL by default. To compile using OpenSSL instead, use this procedure:
Ensure OpenSSL 1.0.1 or higher is installed on your system. To obtain OpenSSL, visit http://www.openssl.org.
If the installed OpenSSL version is lower than 1.0.1, CMake produces an error at MySQL configuration time.
To use OpenSSL, add the
-DWITH_SSL=system option to the
CMake command you normally use to configure
the MySQL source distribution. For example:
shell> cmake . -DWITH_SSL=system
That command configures the distribution to use the installed OpenSSL library. Alternatively, to explicitly specify the path name to the OpenSSL installation, use the following syntax. This can be useful if you have multiple versions of OpenSSL installed, to prevent CMake from choosing the wrong one:
shell> cmake . -DWITH_SSL=path_name
Compile and install the distribution.
To check whether a mysqld server supports
secure connections, examine the value of the
have_ssl system variable:
mysql> SHOW VARIABLES LIKE 'have_ssl';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| have_ssl | YES |
+---------------+-------+
If the value is YES, the server supports secure
connections. If the value is DISABLED, the
server is capable of supporting secure connections but was not
started with the appropriate
--ssl- options to
enable secure connections to be used; see
Section 6.4, “Configuring MySQL to Use Secure Connections”.
xxx
To determine whether a server was compiled using OpenSSL or yaSSL, check the existence of any of the system or status variables that are present only for OpenSSL. See Section 6.1, “OpenSSL Versus yaSSL”
To determine which encryption protocol and cipher are in use for
an encrypted connection, use the following statements to check the
values of the Ssl_version and
Ssl_cipher status variables:
mysql>SHOW SESSION STATUS LIKE 'Ssl_version';+---------------+-------+ | Variable_name | Value | +---------------+-------+ | Ssl_version | TLSv1 | +---------------+-------+ mysql>SHOW SESSION STATUS LIKE 'Ssl_cipher';+---------------+---------------------------+ | Variable_name | Value | +---------------+---------------------------+ | Ssl_cipher | DHE-RSA-AES128-GCM-SHA256 | +---------------+---------------------------+
If the connection is not encrypted, both variables have an empty value.
MySQL supports encrypted connections using TLS protocols:
When compiled using OpenSSL 1.0.1 or higher, MySQL supports the TLSv1, TLSv1.1, and TLSv1.2 protocols.
When compiled using the bundled version of yaSSL, MySQL supports the TLSv1 and TLSv1.1 protocols.
The value of the tls_version
system variable determines which protocols the server is permitted
to use from those that are available. The
tls_version value is a
comma-separated list containing one or more of these protocols
(not case sensitive): TLSv1, TLSv1.1, TLSv1.2. By default, this
variable lists all protocols supported by the SSL library used to
compile MySQL (TLSv1,TLSv1.1,TLSv1.2 for
OpenSSL, TLSv1,TLSv1.1 for yaSSL). To determine
the value of tls_version at
runtime, use this statement:
mysql> SHOW GLOBAL VARIABLES LIKE 'tls_version';
+---------------+-----------------------+
| Variable_name | Value |
+---------------+-----------------------+
| tls_version | TLSv1,TLSv1.1,TLSv1.2 |
+---------------+-----------------------+
To change the value of
tls_version, set it at server
startup. For example, to prohibit connections that use the
less-secure TLSv1 protocol, use these lines in the server
my.cnf file:
[mysqld] tls_version=TLSv1.1,TLSv1.2
To be even more restrict and permit only TLSv1.2 connections, set
tls_version like this (assuming
that your server is compiled using OpenSSL because yaSSL does not
support TLSv1.2):
[mysqld] tls_version=TLSv1.2
For client programs, the
--tls-version option enables
specifying the TLS protocols permitted per client invocation. The
value format is the same as for
tls_version.
By default, MySQL attempts to use the highest TLS protocol version
available, depending on which SSL library was used to compile the
server and client, which key size is used, and whether the server
or client are restricted from using some protocols; for example,
by means of
tls_version/--tls-version:
If the server and client are compiled using OpenSSL, TLSv1.2 is used if possible.
If either or both the server and client are compiled using yaSSL, TLSv1.1 is used if possible.
TLSv1.2 does not work with all ciphers that have a key size of
512 bits or less. To use this protocol with such a key, use
--ssl-cipher to specify the
cipher name explicitly:
AES128-SHA AES128-SHA256 AES256-SHA AES256-SHA256 CAMELLIA128-SHA CAMELLIA256-SHA DES-CBC3-SHA DHE-RSA-AES256-SHA RC4-MD5 RC4-SHA SEED-SHA
For better security, use a certificate with an RSA key size of of 2048 bits or more.
Prior to MySQL 5.7.10, MySQL supports only TLSv1, for both OpenSSL and yaSSL, and no system variable or client option exist for specifying which TLS protocols to permit.
If the server and client protocol capabilities have no protocol in
common, the server terminates the connection request. For example,
if the server is configured with
tls_version=TLSv1.1,TLSv1.2,
connection attempts will fail for clients invoked with
--tls-version=TLSv1, and for older
clients that do not support the
--tls-version option and
implicitly support only TLSv1.
To determine which ciphers a given server supports, use the
following statement to check the value of the
Ssl_cipher_list status variable:
SHOW SESSION STATUS LIKE 'Ssl_cipher_list';
The set of available ciphers depends on your MySQL version and whether MySQL was compiled using OpenSSL or yaSSL, and (for OpenSSL) the library version used to compile MySQL.
As of MySQL 5.7.10, order of ciphers passed by MySQL to the SSL library is significant. More secure ciphers are mentioned first in the list, and the first cipher supported by the provided certificate is selected.
MySQL passes this cipher list to OpenSSL:
ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-ECDSA-AES256-SHA384 ECDHE-RSA-AES256-SHA384 DHE-RSA-AES128-GCM-SHA256 DHE-DSS-AES128-GCM-SHA256 DHE-RSA-AES128-SHA256 DHE-DSS-AES128-SHA256 DHE-DSS-AES256-GCM-SHA384 DHE-RSA-AES256-SHA256 DHE-DSS-AES256-SHA256 ECDHE-RSA-AES128-SHA ECDHE-ECDSA-AES128-SHA ECDHE-RSA-AES256-SHA ECDHE-ECDSA-AES256-SHA DHE-DSS-AES128-SHA DHE-RSA-AES128-SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE-RSA-AES256-SHA AES128-GCM-SHA256 DH-DSS-AES128-GCM-SHA256 ECDH-ECDSA-AES128-GCM-SHA256 AES256-GCM-SHA384 DH-DSS-AES256-GCM-SHA384 ECDH-ECDSA-AES256-GCM-SHA384 AES128-SHA256 DH-DSS-AES128-SHA256 ECDH-ECDSA-AES128-SHA256 AES256-SHA256 DH-DSS-AES256-SHA256 ECDH-ECDSA-AES256-SHA384 AES128-SHA DH-DSS-AES128-SHA ECDH-ECDSA-AES128-SHA AES256-SHA DH-DSS-AES256-SHA ECDH-ECDSA-AES256-SHA DHE-RSA-AES256-GCM-SHA384 DH-RSA-AES128-GCM-SHA256 ECDH-RSA-AES128-GCM-SHA256 DH-RSA-AES256-GCM-SHA384 ECDH-RSA-AES256-GCM-SHA384 DH-RSA-AES128-SHA256 ECDH-RSA-AES128-SHA256 DH-RSA-AES256-SHA256 ECDH-RSA-AES256-SHA384 ECDHE-RSA-AES128-SHA ECDHE-ECDSA-AES128-SHA ECDHE-RSA-AES256-SHA ECDHE-ECDSA-AES256-SHA DHE-DSS-AES128-SHA DHE-RSA-AES128-SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE-RSA-AES256-SHA AES128-SHA DH-DSS-AES128-SHA ECDH-ECDSA-AES128-SHA AES256-SHA DH-DSS-AES256-SHA ECDH-ECDSA-AES256-SHA DH-RSA-AES128-SHA ECDH-RSA-AES128-SHA DH-RSA-AES256-SHA ECDH-RSA-AES256-SHA DES-CBC3-SHA
MySQL passes this cipher list to yaSSL:
DHE-RSA-AES256-SHA DHE-RSA-AES128-SHA AES128-RMD DES-CBC3-RMD DHE-RSA-AES256-RMD DHE-RSA-AES128-RMD DHE-RSA-DES-CBC3-RMD AES256-SHA RC4-SHA RC4-MD5 DES-CBC3-SHA DES-CBC-SHA EDH-RSA-DES-CBC3-SHA EDH-RSA-DES-CBC-SHA AES128-SHA:AES256-RMD
As of MySQL 5.7.10, these cipher restrictions are in place:
The following ciphers are permanently restricted:
!DHE-DSS-DES-CBC3-SHA !DHE-RSA-DES-CBC3-SHA !ECDH-RSA-DES-CBC3-SHA !ECDH-ECDSA-DES-CBC3-SHA !ECDHE-RSA-DES-CBC3-SHA !ECDHE-ECDSA-DES-CBC3-SHA
The following categories of ciphers are permanently restricted:
!aNULL !eNULL !EXPORT !LOW !MD5 !DES !RC2 !RC4 !PSK !SSLv3
If the server is started using a compatible certificate that uses any of the preceding restricted ciphers or cipher categories, the server starts with support for secure connections disabled.
To enable secure connections, the proper options must be used to specify the appropriate certificate and key files. For a complete list of options related to establishment of secure connections, see Section 6.5, “Command Options for Secure Connections”.
If you need to create the required certificate and key files, see Section 6.6, “Creating SSL and RSA Certificates and Keys”.
To start the MySQL server so that it permits clients to connect securely, use options that identify the certificate and key files the server uses when establishing a secure connection:
--ssl-ca identifies the
Certificate Authority (CA) certificate.
--ssl-cert identifies the
server public key certificate. This can be sent to the client
and authenticated against the CA certificate that it has.
--ssl-key identifies the
server private key.
For example, start the server with these lines in the
my.cnf file, changing the file names as
necessary:
[mysqld] ssl-ca=ca.pem ssl-cert=server-cert.pem ssl-key=server-key.pem
Each option names a file in PEM format. If you have a MySQL source
distribution, you can test your setup using the demonstration
certificate and key files in its
mysql-test/std_data directory.
As of MySQL 5.7.5, the server-side
--ssl option value is enabled by
default. Also as of MySQL 5.7.5, MySQL servers compiled using
OpenSSL can generate missing certificate and key files
automatically at startup. See
Section 6.6.1, “Creating SSL and RSA Certificates and Keys using MySQL”.
The server performs certificate and key file autodiscovery as of
MySQL 5.7.5 (for servers compiled using OpenSSL) or 5.7.6 (for
servers compiled using yaSSL). If
--ssl is enabled (possibly along
with --ssl-cipher) and other
--ssl- options are
not given to configure secure connections explicitly, the server
attempts to enable support for secure connections automatically at
startup:
xxx
If the server discovers valid certificate and key files named
ca.pem,
server-cert.pem, and
server-key.pem in the data directory, it
enables support for secure connections by clients. (The files
need not have been autogenerated; what matters is that they
have the indicated names and are valid.)
If the server does not find valid certificate and key files in the data directory, it continues executing but does not enable secure connections.
If the server automatically enables support for secure connections, it writes a message to the error log. As of MySQL 5.7.6, if the server discovers that the CA certificate is self-signed, it writes a warning to the error log. (The certificate will be self-signed if created automatically by the server or manually using mysql_ssl_rsa_setup.)
For any certificate and key files that the server discovers and
uses automatically, it uses the file names to set the
corresponding system variables
(ssl_ca,
ssl_cert,
ssl_key).
For further control over whether clients must connect securely,
use the require_secure_transport
system variable; see Server System Variables.
For information about permitted encryption protocols and ciphers,
see Section 6.3, “Secure Connection Protocols and Ciphers”.
For client programs, options for secure connections are similar to
those used on the server side, but
--ssl-cert and
--ssl-key identify the client
public and private key:
--ssl-ca identifies the
Certificate Authority (CA) certificate. This option, if used,
must specify the same certificate used by the server.
--ssl-cert identifies the
client public key certificate.
--ssl-key identifies the
client private key.
To connect securely to a MySQL server that supports secure
connections, the options that a client must specify depend on the
encryption requirements of the MySQL account used by the client.
(See the discussion of the REQUIRE clause in
CREATE USER Syntax.)
Suppose that you want to connect using an account that has no
special encryption requirements or was created using a
CREATE USER statement that includes
the REQUIRE SSL option. As a recommended set of
secure-connection options, start the server with at least
--ssl-cert and
--ssl-key, and invoke the client
with --ssl-ca. A client can
connect securely like this:
shell> mysql --ssl-ca=ca.pem
To require that a client certificate also be specified, create the
account using the REQUIRE X509 option. Then the
client must also specify the proper client key and certificate
files or the server will reject the connection:
shell>mysql --ssl-ca=ca.pem \--ssl-cert=client-cert.pem \--ssl-key=client-key.pem
To prevent use of encryption and override other
--ssl- options,
invoke the client program with
xxx--ssl-mode=DISABLED,
--ssl=0, or a synonym
(--skip-ssl,
--disable-ssl):
shell> mysql --ssl-mode=DISABLED
As of MySQL 5.7.7, client programs attempt to establish a secure connection by default whenever the server supports secure connections:
In the absence of an
--ssl-mode or
--ssl option, the client falls
back to an unencrypted connection if a secure connection
cannot be established.
To require a secure connection and fail if one cannot be
established, invoke the client with
--ssl-mode=REQUIRED,
--ssl, or a synonym
(--ssl=1,
--enable-ssl).
To use an unencrypted connection, invoke the client with
--ssl-mode=DISABLED,
--ssl=0, or a synonym
(--skip-ssl,
--disable-ssl).
From MySQL 5.7.3 to 5.7.6, --ssl
on the client side is prescriptive (not advisory as before MySQL
5.7.3): With --ssl, connection
attempts fail if a secure connection cannot be established.
Before MySQL 5.7.3, --ssl on the
client side is advisory: --ssl
permits but does not require the client to connect to the server
using encryption. Therefore, this option is not sufficient in
itself to cause a secure connection to be used. For example, if
you specify this option for a client program but the server has
not been configured to support secure connections, the client
falls back to an unencrypted connection.
For information about permitted encryption protocols and ciphers, see Section 6.3, “Secure Connection Protocols and Ciphers”.
A client can determine whether the current connection with the
server uses encryption by checking the value of the
Ssl_cipher status variable. If
the value is empty, the connection is not encrypted. Otherwise,
the connection is encrypted and the value indicates the encryption
cipher. For example:
mysql> SHOW STATUS LIKE 'Ssl_cipher';
+---------------+--------------------+
| Variable_name | Value |
+---------------+--------------------+
| Ssl_cipher | DHE-RSA-AES256-SHA |
+---------------+--------------------+
For the mysql client, an alternative is to use
the STATUS or \s command and
check the SSL line:
mysql> \s
...
SSL: Cipher in use is DHE-RSA-AES256-SHA
...
Or:
mysql> \s
...
SSL: Not in use
...
The C API enables application programs to use secure connections:
To establish a secure connection, use the
mysql_ssl_set() C API function
to set the appropriate certificate options before calling
mysql_real_connect(). See
mysql_ssl_set(). To require the use of a
secure connection, call
mysql_options() with the
MYSQL_OPT_SSL_MODE option (use the
MYSQL_OPT_SSL_ENFORCE option before MySQL
5.7.11). To establish permitted encryption protocols, call
mysql_options() with the
MYSQL_OPT_TLS_VERSION option.
To determine whether encryption is in use after the connection
is established, use
mysql_get_ssl_cipher(). A
non-NULL return value indicates an
encrypted connection and names the cipher used for encryption.
A NULL return value indicates that
encryption is not being used. See
mysql_get_ssl_cipher().
Replication uses the C API, so secure connections can be used between master and slave servers. See Setting Up Replication to Use Secure Connections.
This section describes options that specify whether to use secure connections and the names of certificate and key files. These options can be given on the command line or in an option file. For examples of suggested use and how to check whether a connection is secure, see Section 6.4, “Configuring MySQL to Use Secure Connections”.
Table 6.1 Secure-Connection Option Summary
| Format | Description | Introduced |
|---|---|---|
| --skip-ssl | Do not use secure connection | |
| --ssl | Enable secure connection | |
| --ssl-ca | Path of file that contains list of trusted SSL CAs | |
| --ssl-capath | Path of directory that contains trusted SSL CA certificates in PEM format | |
| --ssl-cert | Path of file that contains X509 certificate in PEM format | |
| --ssl-cipher | List of permitted ciphers to use for connection encryption | |
| --ssl-crl | Path of file that contains certificate revocation lists | |
| --ssl-crlpath | Path of directory that contains certificate revocation list files | |
| --ssl-key | Path of file that contains X509 key in PEM format | |
| --ssl-mode | Security state of connection to server | 5.7.11 |
| --ssl-verify-server-cert | Verify server certificate Common Name value against host name used when connecting to server | |
| --tls-version | Protocols permitted for secure connections | 5.7.10 |
This option has different effects on the server and client sides.
The client-side --ssl option
is deprecated as of MySQL 5.7.11 and is removed in MySQL
8.0. For client programs, it is preferable to use
--ssl-mode instead:
Use --ssl-mode=REQUIRED
instead of --ssl=1 or
--enable-ssl.
Use --ssl-mode=DISABLED
instead of --ssl=0,
--skip-ssl,
or
--disable-ssl.
No explicit --ssl-mode
option is equivalent to no explicit
--ssl option.
The server-side --ssl option
is not deprecated.
For the MySQL server, this option specifies that the server permits but does not require secure connections. The option is enabled on the server side by default as of MySQL 5.7.5, and disabled before 5.7.5. Also as of MySQL 5.7.5, MySQL servers compiled using OpenSSL can generate missing certificate and key files automatically at startup. See Section 6.6.1, “Creating SSL and RSA Certificates and Keys using MySQL”.
The server performs certificate and key file autodiscovery as
of MySQL 5.7.5 (for servers compiled using OpenSSL) or 5.7.6
(for servers compiled using yaSSL). If
--ssl is enabled (possibly
along with --ssl-cipher) and
other --ssl-
options are not given to configure secure connections
explicitly, the server attempts to enable support for secure
connections automatically at startup:
xxx
If the server discovers valid certificate and key files
named ca.pem,
server-cert.pem, and
server-key.pem in the data directory,
it enables support for secure connections by clients. (The
files need not have been autogenerated; what matters is
that they have the indicated names and are valid.)
If the server does not find valid certificate and key files in the data directory, it continues executing but does not enable secure connections.
For MySQL client programs, the
--ssl option is used as
follows:
As of MySQL 5.7.7, client programs attempt to establish a secure connection by default whenever the server supports secure connections:
In the absence of an
--ssl option, the
client falls back to an unencrypted connection if a
secure connection cannot be established.
To require a secure connection and fail if one cannot
be established, invoke the client with
--ssl or a synonym
(--ssl=1,
--enable-ssl).
To use an unencrypted connection, invoke the client
with --ssl=0 or a
synonym
(--skip-ssl,
--disable-ssl).
From MySQL 5.7.3 to 5.7.6,
--ssl is prescriptive (not
advisory as before MySQL 5.7.3): With
--ssl, connection attempts
fail if a secure connection cannot be established.
Before MySQL 5.7.3, --ssl
is advisory: --ssl permits
but does not require the client to connect to the server
using encryption. Therefore, this option is not sufficient
in itself to cause a secure connection to be used. For
example, if you specify this option for a client program
but the server has not been configured to support secure
connections, the client falls back to an unencrypted
connection.
If other --ssl-
options are given in the absence of xxx--ssl,
the client attempts to connect securely. If the server is
configured to support secure connections, the connection
attempt fails if a secure connection cannot be established. If
the server is not configured for secure connections, the
client falls back to an unencrypted connection.
As a recommended set of options to enable secure connections,
use at least --ssl-cert and
--ssl-key on the server side
and --ssl-ca on the client
side. See Section 6.4, “Configuring MySQL to Use Secure Connections”.
--ssl is implied by other
--ssl- options,
as indicated in the descriptions for those options.
xxx
The --ssl option in negated
form overrides other
--ssl- options
and indicates that encryption should not
be used. To do this, specify the option as
xxx--ssl=0 or a synonym
(--skip-ssl,
--disable-ssl).
For example, you might have options specified in the
[client] group of your option file to use
secure connections by default when you invoke MySQL client
programs. To use an unencrypted connection instead, invoke the
client program with
--ssl=0 on the
command line to override the options in the option file.
To require use of secure connections by a MySQL account, use
CREATE USER to create the
account with at least a REQUIRE SSL clause,
or use ALTER USER for an
existing account to add a REQUIRE clause.
Connections for the account will be rejected unless MySQL
supports secure connections and the server and client have
been started with the proper secure-connection options.
The REQUIRE clause permits other
encryption-related options, which can be used to enforce
stricter requirements than REQUIRE SSL. For
additional details about which command options may or must be
specified by clients that connect using accounts configured
using the various REQUIRE options, see the
description of REQUIRE in
CREATE USER Syntax.
The path to a file in PEM format that contains a list of
trusted SSL certificate authorities. This option implies
--ssl when used on the server
side, and on the client side before MySQL 5.7.3.
If you use encryption when establishing a client connection,
to tell the client not to authenticate the server certificate,
specify neither --ssl-ca nor
--ssl-capath. The server still
verifies the client according to any applicable requirements
established for the client account, and it still uses any
--ssl-ca or
--ssl-capath option values
specified at server startup.
The path to a directory that contains trusted SSL certificate
authority certificates in PEM format. This option implies
--ssl when used on the server
side, and on the client side before MySQL 5.7.3.
If you use encryption when establishing a client connection,
to tell the client not to authenticate the server certificate,
specify neither --ssl-ca nor
--ssl-capath. The server still
verifies the client according to any applicable requirements
established for the client account, and it still uses any
--ssl-ca or
--ssl-capath option values
specified at server startup.
MySQL distributions compiled using OpenSSL support the
--ssl-capath option (see
Section 6.1, “OpenSSL Versus yaSSL”). Distributions
compiled using yaSSL do not because yaSSL does not look in any
directory and does not follow a chained certificate tree.
yaSSL requires that all components of the CA certificate tree
be contained within a single CA certificate tree and that each
certificate in the file has a unique SubjectName value. To
work around this yaSSL limitation, concatenate the individual
certificate files comprising the certificate tree into a new
file and specify that file as the value of the
--ssl-ca option.
The name of the SSL certificate file in PEM format to use for
establishing a secure connection. This option implies
--ssl when used on the server
side, and on the client side before MySQL 5.7.3.
A list of permissible ciphers to use for connection
encryption. If no cipher in the list is supported, encrypted
connections will not work. This option implies
--ssl when used on the server
side, and on the client side before MySQL 5.7.3.
For greatest portability,
cipher_list should be a list of one
or more cipher names, separated by colons. This format is
understood both by OpenSSL and yaSSL. Examples:
--ssl-cipher=AES128-SHA --ssl-cipher=DHE-RSA-AES256-SHA:AES128-SHA
OpenSSL supports a more flexible syntax for specifying ciphers, as described in the OpenSSL documentation at http://www.openssl.org/docs/apps/ciphers.html. yaSSL does not, so attempts to use that extended syntax fail for a MySQL distribution compiled using yaSSL.
For information about which encryption ciphers MySQL supports, see Section 6.3, “Secure Connection Protocols and Ciphers”.
The path to a file containing certificate revocation lists in
PEM format. This option implies
--ssl when used on the server
side, and on the client side before MySQL 5.7.3.
If neither --ssl-crl nor
--ssl-crlpath is given, no CRL
checks are performed, even if the CA path contains certificate
revocation lists.
MySQL distributions compiled using OpenSSL support the
--ssl-crl option (see
Section 6.1, “OpenSSL Versus yaSSL”). Distributions
compiled using yaSSL do not because revocation lists do not
work with yaSSL.
The path to a directory that contains files containing
certificate revocation lists in PEM format. This option
implies --ssl when used on the
server side, and on the client side before MySQL 5.7.3.
If neither --ssl-crl nor
--ssl-crlpath is given, no CRL
checks are performed, even if the CA path contains certificate
revocation lists.
MySQL distributions compiled using OpenSSL support the
--ssl-crlpath option (see
Section 6.1, “OpenSSL Versus yaSSL”). Distributions
compiled using yaSSL do not because revocation lists do not
work with yaSSL.
The name of the SSL key file in PEM format to use for
establishing a secure connection. This option implies
--ssl when used on the server
side, and on the client side before MySQL 5.7.3.
If the key file is protected by a passphrase, the program prompts the user for the passphrase. The password must be given interactively; it cannot be stored in a file. If the passphrase is incorrect, the program continues as if it could not read the key.
For better security, use a certificate with an RSA key size of of 2048 bits or more.
This option is available only for client programs, not the server. It specifies the security state of the connection to the server. The following option values are permitted:
PREFERRED: Establish a secure
(encrypted) connection if the server supports secure
connections. Fall back to an unencrypted connection
otherwise. This is the default if
--ssl-mode is not
specified.
DISABLED: Establish an unencrypted
connection. This is like the legacy
--ssl=0 option or its
synonyms
(--skip-ssl,
--disable-ssl).
REQUIRED: Establish a secure connection
if the server supports secure connections. The connection
attempt fails if a secure connection cannot be
established.
VERIFY_CA: Like
REQUIRED, but additionally verify the
server TLS certificate against the configured Certificate
Authority (CA) certificates. The connection attempt fails
if no valid matching CA certificates are found.
VERIFY_IDENTITY: Like
VERIFY_CA, but additionally verify that
the server certificate matches the host to which the
connection is attempted. This is like the legacy
--ssl-verify-server-cert
option.
Use of the --ssl-ca or
--ssl-capath option implies
--ssl-mode=VERIFY_CA, if
--ssl-mode is not explicitly
set otherwise.
If --ssl-mode is explicit, use
of a value other than VERIFY_CA or
VERIFY_IDENTITY with an explicit
--ssl-ca or
--ssl-capath option produces a
warning that no verification of the server certificate will be
done, despite CA certificate options being specified.
The --ssl-mode option was
added in MySQL 5.7.11.
To require use of secure connections by a MySQL account, use
CREATE USER to create the
account with at least a REQUIRE SSL clause,
or use ALTER USER for an
existing account to add a REQUIRE clause.
Connections for the account will be rejected unless MySQL
supports secure connections and the server and client have
been started with the proper secure-connection options.
The REQUIRE clause permits other
encryption-related options, which can be used to enforce
stricter requirements than REQUIRE SSL. For
additional details about which command options may or must be
specified by clients that connect using accounts configured
using the various REQUIRE options, see the
description of REQUIRE in
CREATE USER Syntax.
This option is deprecated as of MySQL 5.7.11 and is removed
in MySQL 8.0. It is preferable to use
--ssl-mode=VERIFY_IDENTITY
instead.
This option is available only for client programs, not the server. It causes the client to check the server's Common Name value in the certificate that the server sends to the client. The client verifies that name against the host name the client uses for connecting to the server, and the connection fails if there is a mismatch. For encrypted connections, this option helps prevent man-in-the-middle attacks. Verification is disabled by default.
For client programs, the protocols permitted by the client for encrypted connections. The value is a comma-separated list containing one or more protocol names. The protocols that can be named for this option depend on the SSL library used to compile MySQL. For details, see Section 6.3, “Secure Connection Protocols and Ciphers”.
This option was added in MySQL 5.7.10.
On the server side, the
tls_version system variable
can be used instead.
The following discussion describes how to create the files required for SSL and RSA support in MySQL. File creation can be performed using facilities provided by MySQL itself, or by invoking the openssl command directly.
SSL certificate and key files enable MySQL to support secure connections using SSL. See Section 6.4, “Configuring MySQL to Use Secure Connections”.
RSA key files enable MySQL to support secure password exchange
over unencrypted connections for accounts authenticated by the
sha256_password plugin. See
Section 7.1.4, “The SHA-256 Authentication Plugin”.
MySQL provides two ways to create the SSL certificate and key files and RSA key-pair files required to support secure connections using SSL and secure password exchange using RSA over unencrypted connections, if those files are missing:
The server can autogenerate these files at startup.
Users can invoke the mysql_ssl_rsa_setup utility manually.
Server autogeneration and mysql_ssl_rsa_setup help lower the barrier to using SSL by making it easier to generate the required files. However, certificates generated by these methods are self-signed, which is not very secure. After you gain experience using such files, consider obtaining a CA certificate from a registered certificate authority.
As of MySQL 5.7.5, MySQL servers have the capability of
automatically generating missing SSL and RSA files at startup,
for MySQL distributions compiled using OpenSSL. The
auto_generate_certs and
sha256_password_auto_generate_rsa_keys
system variables control automatic generation of these files.
Both variables are enabled by default. They can be enabled at
startup and inspected but not set at runtime.
At startup, the server automatically generates server-side and
client-side SSL certificate and key files in the data directory
if the auto_generate_certs
system variable is enabled, no SSL options other than
--ssl are specified, and the
server-side SSL files are missing from the data directory. These
files enable secure client connections using SSL; see
Section 6.4, “Configuring MySQL to Use Secure Connections”.
The server checks the data directory for SSL files with the following names:
ca.pem server-cert.pem server-key.pem
If any of those files are present, the server creates no SSL files. Otherwise, it creates them, plus some additional files:
ca.pem Self-signed CA certificate ca-key.pem CA private key server-cert.pem Server certificate server-key.pem Server private key client-cert.pem Client certificate client-key.pem Client private key
If the server autogenerates SSL files, it uses the names of
the ca.pem,
server-cert.pem, and
server-key.pem files to set the
corresponding system variables
(ssl_ca,
ssl_cert,
ssl_key).
At startup, the server automatically generates RSA
private/public key-pair files in the data directory if the
sha256_password_auto_generate_rsa_keys
system variable is enabled, no RSA options are specified, and
the RSA files are missing from the data directory. These files
enable secure password exchange using RSA over unencrypted
connections for accounts authenticated by the
sha256_password plugin; see
Section 7.1.4, “The SHA-256 Authentication Plugin”.
The server checks the data directory for RSA files with the following names:
private_key.pem Private member of private/public key pair public_key.pem Public member of private/public key pair
If any of these files are present, the server creates no RSA files. Otherwise, it creates them.
If the server autogenerates the RSA files, it uses their
names to set the corresponding system variables
(sha256_password_private_key_path,
sha256_password_public_key_path).
As of MySQL 5.7.6, MySQL distributions include a mysql_ssl_rsa_setup utility that can be invoked manually to generate SSL and RSA files. This utility is included with all MySQL distributions (whether compiled using OpenSSL or yaSSL), but it does require that the openssl command be available. For usage instructions, see mysql_ssl_rsa_setup — Create SSL/RSA Files.
SSL and RSA files created automatically by the server or by invoking mysql_ssl_rsa_setup have these characteristics:
SSL and RSA keys are 2048 bit.
The SSL CA certificate is self signed.
The SSL server and client certificates are signed with the
CA certificate and key, using the
sha256WithRSAEncryption signature
algorithm.
SSL certificates use these Common Name (CN) values, with the appropriate certificate type (CA, Server, Client):
ca.pem: MySQL_Server_suffix_Auto_Generated_CA_Certificate server-cert.pm: MySQL_Server_suffix_Auto_Generated_Server_Certificate client-cert.pm: MySQL_Server_suffix_Auto_Generated_Client_Certificate
The suffix value is based on the
MySQL version number. For files generated by
mysql_ssl_rsa_setup, the suffix can be
specified explicitly using the
--suffix option.
For files generated by the server, if the resulting CN
values exceed 64 characters, the
_
portion of the name is omitted.
suffix
SSL files have blank values for Country (C), State or Province (ST), Organization (O), Organization Unit Name (OU) and email address.
SSL files created by the server or by mysql_ssl_rsa_setup are valid for ten years from the time of generation. (Before MySQL 5.7.6, files created by the server are valid for one year.)
RSA files do not expire.
SSL files have different serial numbers for each certificate/key pair (1 for CA, 2 for Server, 3 for Client).
Files created automatically by the server are owned by the
account that runs the server. Files created using
mysql_ssl_rsa_setup are owned by the user
who invoked that program. This can be changed on systems
that support the chown() system call if
the program is invoked by root and the
--uid option is
given to specify the user who should own the files.
On Unix and Unix-like systems, the file access mode is 644 for certificate files (that is, world readable) and 600 for key files (that is, accessible only by the account that runs the server).
To see the contents of an SSL certificate (for example, to check the range of dates over which it is valid), invoke openssl directly:
shell>openssl x509 -text -in ca.pemshell>openssl x509 -text -in server-cert.pemshell>openssl x509 -text -in client-cert.pem
It is also possible to check SSL certificate expiration information using this SQL statement:
mysql> SHOW STATUS LIKE 'Ssl_server_not%';
+-----------------------+--------------------------+
| Variable_name | Value |
+-----------------------+--------------------------+
| Ssl_server_not_after | Apr 28 14:16:39 2025 GMT |
| Ssl_server_not_before | May 1 14:16:39 2015 GMT |
+-----------------------+--------------------------+
This section describes how to use the openssl command to set up SSL certificate and key files for use by MySQL servers and clients. The first example shows a simplified procedure such as you might use from the command line. The second shows a script that contains more detail. The first two examples are intended for use on Unix and both use the openssl command that is part of OpenSSL. The third example describes how to set up SSL files on Windows.
There are easier alternatives to generating the files required for SSL than the procedure described here: Let the server autogenerate them or use the mysql_ssl_rsa_setup program. See Section 6.6.1, “Creating SSL and RSA Certificates and Keys using MySQL”.
Whatever method you use to generate the certificate and key files, the Common Name value used for the server and client certificates/keys must each differ from the Common Name value used for the CA certificate. Otherwise, the certificate and key files will not work for servers compiled using OpenSSL. A typical error in this case is:
ERROR 2026 (HY000): SSL connection error: error:00000001:lib(0):func(0):reason(1)
The following example shows a set of commands to create MySQL server and client certificate and key files. You will need to respond to several prompts by the openssl commands. To generate test files, you can press Enter to all prompts. To generate files for production use, you should provide nonempty responses.
# Create clean environment shell>rm -rf newcertsshell>mkdir newcerts && cd newcerts# Create CA certificate shell>openssl genrsa 2048 > ca-key.pemshell>openssl req -new -x509 -nodes -days 3600 \-key ca-key.pem -out ca.pem# Create server certificate, remove passphrase, and sign it # server-cert.pem = public key, server-key.pem = private key shell>openssl req -newkey rsa:2048 -days 3600 \-nodes -keyout server-key.pem -out server-req.pemshell>openssl rsa -in server-key.pem -out server-key.pemshell>openssl x509 -req -in server-req.pem -days 3600 \-CA ca.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem# Create client certificate, remove passphrase, and sign it # client-cert.pem = public key, client-key.pem = private key shell>openssl req -newkey rsa:2048 -days 3600 \-nodes -keyout client-key.pem -out client-req.pemshell>openssl rsa -in client-key.pem -out client-key.pemshell>openssl x509 -req -in client-req.pem -days 3600 \-CA ca.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.pem
After generating the certificates, verify them:
shell> openssl verify -CAfile ca.pem server-cert.pem client-cert.pem
server-cert.pem: OK
client-cert.pem: OK
To see the contents of a certificate (for example, to check the range of dates over which a certificate is valid), invoke openssl like this:
shell>openssl x509 -text -in ca.pemshell>openssl x509 -text -in server-cert.pemshell>openssl x509 -text -in client-cert.pem
Now you have a set of files that can be used as follows:
ca.pem: Use this as the argument to
--ssl-ca on the server and
client sides. (The CA certificate, if used, must be the
same on both sides.)
server-cert.pem,
server-key.pem: Use these as the
arguments to --ssl-cert
and --ssl-key on the
server side.
client-cert.pem,
client-key.pem: Use these as the
arguments to --ssl-cert
and --ssl-key on the
client side.
To use the files for SSL connections, see Section 6.4, “Configuring MySQL to Use Secure Connections”.
Here is an example script that shows how to set up SSL certificate and key files for MySQL. After executing the script, use the files for SSL connections as described in Section 6.4, “Configuring MySQL to Use Secure Connections”.
DIR=`pwd`/openssl
PRIV=$DIR/private
mkdir $DIR $PRIV $DIR/newcerts
cp /usr/share/ssl/openssl.cnf $DIR
replace ./demoCA $DIR -- $DIR/openssl.cnf
# Create necessary files: $database, $serial and $new_certs_dir
# directory (optional)
touch $DIR/index.txt
echo "01" > $DIR/serial
#
# Generation of Certificate Authority(CA)
#
openssl req -new -x509 -keyout $PRIV/cakey.pem -out $DIR/ca.pem \
-days 3600 -config $DIR/openssl.cnf
# Sample output:
# Using configuration from /home/finley/openssl/openssl.cnf
# Generating a 1024 bit RSA private key
# ................++++++
# .........++++++
# writing new private key to '/home/finley/openssl/private/cakey.pem'
# Enter PEM pass phrase:
# Verifying password - Enter PEM pass phrase:
# -----
# You are about to be asked to enter information that will be
# incorporated into your certificate request.
# What you are about to enter is what is called a Distinguished Name
# or a DN.
# There are quite a few fields but you can leave some blank
# For some fields there will be a default value,
# If you enter '.', the field will be left blank.
# -----
# Country Name (2 letter code) [AU]:FI
# State or Province Name (full name) [Some-State]:.
# Locality Name (eg, city) []:
# Organization Name (eg, company) [Internet Widgits Pty Ltd]:MySQL AB
# Organizational Unit Name (eg, section) []:
# Common Name (eg, YOUR name) []:MySQL admin
# Email Address []:
#
# Create server request and key
#
openssl req -new -keyout $DIR/server-key.pem -out \
$DIR/server-req.pem -days 3600 -config $DIR/openssl.cnf
# Sample output:
# Using configuration from /home/finley/openssl/openssl.cnf
# Generating a 1024 bit RSA private key
# ..++++++
# ..........++++++
# writing new private key to '/home/finley/openssl/server-key.pem'
# Enter PEM pass phrase:
# Verifying password - Enter PEM pass phrase:
# -----
# You are about to be asked to enter information that will be
# incorporated into your certificate request.
# What you are about to enter is what is called a Distinguished Name
# or a DN.
# There are quite a few fields but you can leave some blank
# For some fields there will be a default value,
# If you enter '.', the field will be left blank.
# -----
# Country Name (2 letter code) [AU]:FI
# State or Province Name (full name) [Some-State]:.
# Locality Name (eg, city) []:
# Organization Name (eg, company) [Internet Widgits Pty Ltd]:MySQL AB
# Organizational Unit Name (eg, section) []:
# Common Name (eg, YOUR name) []:MySQL server
# Email Address []:
#
# Please enter the following 'extra' attributes
# to be sent with your certificate request
# A challenge password []:
# An optional company name []:
#
# Remove the passphrase from the key
#
openssl rsa -in $DIR/server-key.pem -out $DIR/server-key.pem
#
# Sign server cert
#
openssl ca -cert $DIR/ca.pem -policy policy_anything \
-out $DIR/server-cert.pem -config $DIR/openssl.cnf \
-infiles $DIR/server-req.pem
# Sample output:
# Using configuration from /home/finley/openssl/openssl.cnf
# Enter PEM pass phrase:
# Check that the request matches the signature
# Signature ok
# The Subjects Distinguished Name is as follows
# countryName :PRINTABLE:'FI'
# organizationName :PRINTABLE:'MySQL AB'
# commonName :PRINTABLE:'MySQL admin'
# Certificate is to be certified until Sep 13 14:22:46 2003 GMT
# (365 days)
# Sign the certificate? [y/n]:y
#
#
# 1 out of 1 certificate requests certified, commit? [y/n]y
# Write out database with 1 new entries
# Data Base Updated
#
# Create client request and key
#
openssl req -new -keyout $DIR/client-key.pem -out \
$DIR/client-req.pem -days 3600 -config $DIR/openssl.cnf
# Sample output:
# Using configuration from /home/finley/openssl/openssl.cnf
# Generating a 1024 bit RSA private key
# .....................................++++++
# .............................................++++++
# writing new private key to '/home/finley/openssl/client-key.pem'
# Enter PEM pass phrase:
# Verifying password - Enter PEM pass phrase:
# -----
# You are about to be asked to enter information that will be
# incorporated into your certificate request.
# What you are about to enter is what is called a Distinguished Name
# or a DN.
# There are quite a few fields but you can leave some blank
# For some fields there will be a default value,
# If you enter '.', the field will be left blank.
# -----
# Country Name (2 letter code) [AU]:FI
# State or Province Name (full name) [Some-State]:.
# Locality Name (eg, city) []:
# Organization Name (eg, company) [Internet Widgits Pty Ltd]:MySQL AB
# Organizational Unit Name (eg, section) []:
# Common Name (eg, YOUR name) []:MySQL user
# Email Address []:
#
# Please enter the following 'extra' attributes
# to be sent with your certificate request
# A challenge password []:
# An optional company name []:
#
# Remove the passphrase from the key
#
openssl rsa -in $DIR/client-key.pem -out $DIR/client-key.pem
#
# Sign client cert
#
openssl ca -cert $DIR/ca.pem -policy policy_anything \
-out $DIR/client-cert.pem -config $DIR/openssl.cnf \
-infiles $DIR/client-req.pem
# Sample output:
# Using configuration from /home/finley/openssl/openssl.cnf
# Enter PEM pass phrase:
# Check that the request matches the signature
# Signature ok
# The Subjects Distinguished Name is as follows
# countryName :PRINTABLE:'FI'
# organizationName :PRINTABLE:'MySQL AB'
# commonName :PRINTABLE:'MySQL user'
# Certificate is to be certified until Sep 13 16:45:17 2003 GMT
# (365 days)
# Sign the certificate? [y/n]:y
#
#
# 1 out of 1 certificate requests certified, commit? [y/n]y
# Write out database with 1 new entries
# Data Base Updated
#
# Create a my.cnf file that you can use to test the certificates
#
cat <<EOF > $DIR/my.cnf
[client]
ssl-ca=$DIR/ca.pem
ssl-cert=$DIR/client-cert.pem
ssl-key=$DIR/client-key.pem
[mysqld]
ssl-ca=$DIR/ca.pem
ssl-cert=$DIR/server-cert.pem
ssl-key=$DIR/server-key.pem
EOF
Download OpenSSL for Windows if it is not installed on your system. An overview of available packages can be seen here:
http://www.slproweb.com/products/Win32OpenSSL.html
Choose the Win32 OpenSSL Light or Win64 OpenSSL Light package,
depending on your architecture (32-bit or 64-bit). The default
installation location will be
C:\OpenSSL-Win32 or
C:\OpenSSL-Win64, depending on which
package you downloaded. The following instructions assume a
default location of C:\OpenSSL-Win32.
Modify this as necessary if you are using the 64-bit package.
If a message occurs during setup indicating
'...critical component is missing: Microsoft Visual
C++ 2008 Redistributables', cancel the setup and
download one of the following packages as well, again
depending on your architecture (32-bit or 64-bit):
Visual C++ 2008 Redistributables (x86), available at:
http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF
Visual C++ 2008 Redistributables (x64), available at:
http://www.microsoft.com/downloads/details.aspx?familyid=bd2a6171-e2d6-4230-b809-9a8d7548c1b6
After installing the additional package, restart the OpenSSL setup procedure.
During installation, leave the default
C:\OpenSSL-Win32 as the install path, and
also leave the default option 'Copy OpenSSL DLL files
to the Windows system directory' selected.
When the installation has finished, add
C:\OpenSSL-Win32\bin to the Windows
System Path variable of your server:
On the Windows desktop, right-click the My Computer icon, and select .
Select the tab from the menu that appears, and click the button.
Under System Variables, select , then click the button. The dialogue should appear.
Add ';C:\OpenSSL-Win32\bin' to the end
(notice the semicolon).
Press OK 3 times.
Check that OpenSSL was correctly integrated into the Path variable by opening a new command console (Start>Run>cmd.exe) and verifying that OpenSSL is available:
Microsoft Windows [Version ...] Copyright (c) 2006 Microsoft Corporation. All rights reserved. C:\Windows\system32>cd \C:\>opensslOpenSSL>exit<<< If you see the OpenSSL prompt, installation was successful. C:\>
Depending on your version of Windows, the preceding path-setting instructions might differ slightly.
After OpenSSL has been installed, use instructions similar to those from Example 1 (shown earlier in this section), with the following changes:
Change the following Unix commands:
# Create clean environment shell>rm -rf newcertsshell>mkdir newcerts && cd newcerts
On Windows, use these commands instead:
# Create clean environment C:\>md c:\newcertsC:\>cd c:\newcerts
When a '\' character is shown at the
end of a command line, this '\'
character must be removed and the command lines entered
all on a single line.
After generating the certificate and key files, to use them for SSL connections, see Section 6.4, “Configuring MySQL to Use Secure Connections”.
This section describes how to use the openssl
command to set up the RSA key files that enable MySQL to support
secure password exchange over unencrypted connections for
accounts authenticated by the sha256_password
plugin.
There are easier alternatives to generating the files required for RSA than the procedure described here: Let the server autogenerate them or use the mysql_ssl_rsa_setup program. See Section 6.6.1, “Creating SSL and RSA Certificates and Keys using MySQL”.
To create the RSA private and public key-pair files, run these commands while logged into the system account used to run the MySQL server so the files will be owned by that account:
openssl genrsa -out private_key.pem 2048 openssl rsa -in private_key.pem -pubout -out public_key.pem
Those commands create 2,048-bit keys. To create stronger keys, use a larger value.
Then set the access modes for the key files. The private key should be readable only by the server, whereas the public key can be freely distributed to client users:
chmod 400 private_key.pem chmod 444 public_key.pem
This section describes how to get a secure connection to a remote
MySQL server with SSH. The information was provided by David
Carlson <dcarlson@mplcomm.com>.
Install an SSH client on your Windows machine. For a comparison of SSH clients, see http://en.wikipedia.org/wiki/Comparison_of_SSH_clients.
Start your Windows SSH client. Set Host_Name =
.
Set
yourmysqlserver_URL_or_IPuserid=
to log in to your server. This your_useriduserid value
might not be the same as the user name of your MySQL account.
Set up port forwarding. Either do a remote forward (Set
local_port: 3306, remote_host:
,
yourmysqlservername_or_ipremote_port: 3306 ) or a local forward (Set
port: 3306, host:
localhost, remote port: 3306).
Save everything, otherwise you will have to redo it the next time.
Log in to your server with the SSH session you just created.
On your Windows machine, start some ODBC application (such as Access).
Create a new file in Windows and link to MySQL using the ODBC
driver the same way you normally do, except type in
localhost for the MySQL host server, not
yourmysqlservername.
At this point, you should have an ODBC connection to MySQL, encrypted using SSH.