Переменные системы tls_xxx и ssl_xxx динамические и могут быть установлены во время выполнения, а не только при запуске. Если они изменены с помощью SET GLOBAL, новые значения применяются только до перезапуска сервера. Если они изменены с помощью SET PERSIST, новые значения также сохраняются при последующих перезапусках сервера. См. Раздел 15.7.6.1, «Синтаксис SET для присваивания переменных». Однако изменения этих переменных во время выполнения немедленно не влияют на контекст TLS для новых подключений, как описано позже в этом разделе.

Вместе с возможностью изменения контекста TLS связанных переменных системы во время выполнения, сервер позволяет выполнять обновления фактического контекста TLS, используемого для новых подключений во время выполнения. Эта возможность может быть полезной, например, чтобы избежать перезапуска сервера MySQL, который работал так долго, что его сертификат SSL истек.

Для создания начального контекста TLS сервер использует значения, которые имеют связанные с контекстом переменные системы при запуске. Для отображения значений контекста сервер также инициализирует набор соответствующих переменных состояния. В следующей таблице показаны переменные системы, которые определяют контекст TLS сервера, и соответствующие переменные состояния, которые отображают текущие значения активного контекста.

Эти активные значения контекста TLS также отображаются как свойства в таблице Performance Schema tls_channel_status, наряду с свойствами для любых других активных контекстов TLS.

Для переконфигурации контекста TLS во время выполнения используйте эту процедуру:

Элементы каждой пары переменных системы и состояния могут иметь временные значения, отличные от значений, из-за того, как работает процедура переконфигурации:

В некоторых случаях ALTER INSTANCE RELOAD TLS сам по себе может быть достаточным для переконфигурации контекста TLS без изменения каких-либо переменных системы. Предположим, что сертификат в файле, имя которого указано в ssl_cert, истек. Достаточно заменить содержимое существующего файла неистекшим сертификатом и выполнить ALTER INSTANCE RELOAD TLS, чтобы содержимое нового файла было прочитано и использовано для новых подключений.

Сервер реализует независимую настройку шифрования подключений для административного интерфейса подключения. См. Поддержка шифрованных подключений административного интерфейса. Кроме того, ALTER INSTANCE RELOAD TLS дополнено клаузой FOR CHANNEL, которая позволяет указать канал (интерфейс), для которого следует перезагрузить контекст TLS. См. Раздел 15.1.5, «Команда ALTER INSTANCE». Нет переменных состояния для отображения контекста TLS административного интерфейса, но таблица Performance Schema tls_channel_status отображает свойства TLS для основных и административных интерфейсов. См. Раздел 29.12.22.10, «Таблица tls_channel_status».

Обновление контекста TLS основного интерфейса имеет следующие последствия:

По умолчанию действие RELOAD TLS отменяется с ошибкой и не имеет эффекта, если значения конфигурации не позволяют создать новый контекст TLS. Предыдущие значения контекста по-прежнему используются для новых подключений. Если указана необязательная клауза NO ROLLBACK ON ERROR и новый контекст не может быть создан, откат не происходит. Вместо этого генерируется предупреждение, и шифрование отключается для новых подключений к интерфейсу, к которому применяется команда.

Параметры, которые включают или отключают шифрованные подключения на интерфейсе соединения, действуют только при запуске. Например, параметры --tls-version и --admin-tls-version влияют только при запуске на то, поддерживают ли основной и административный интерфейсы эти версии TLS. Такие параметры игнорируются и не влияют на работу ALTER INSTANCE RELOAD TLS во время выполнения. Например, вы можете установить tls_version='', чтобы запустить сервер с отключенными шифрованными подключениями на основном интерфейсе, а затем переконфигурировать TLS и выполнить ALTER INSTANCE RELOAD TLS, чтобы включить шифрованные подключения во время выполнения.

Полный список параметров клиента, связанных с установкой шифрованных подключений, см. в Параметрах командной строки для шифрованных подключений.

По умолчанию программы-клиенты MySQL пытаются установить шифрованное подключение, если сервер поддерживает шифрованные подключения, с дополнительным управлением через параметр --ssl-mode:

Попытки установить нешифрованное подключение завершаются ошибкой, если системная переменная require_secure_transport включена на стороне сервера, чтобы сервер требовал шифрованных подключений. См. Настройку обязательного шифрованного подключения.

Следующие параметры на стороне клиента идентифицируют сертификаты и ключи, которые клиенты используют при установлении шифрованных подключений к серверу. Они похожи на системные переменные ssl_ca, ssl_cert и ssl_key, используемые на стороне сервера, но --ssl-cert и --ssl-key идентифицируют открытый и закрытый ключи клиента:

Для дополнительной безопасности относительно стандартного шифрования клиенты могут предоставить сертификат CA, соответствующий сертификату сервера, и включить проверку имени хоста. Таким образом, сервер и клиент доверяют одному и тому же сертификату CA, а клиент проверяет, что хост, к которому он подключился, является тем, который ожидался:

MySQL также предоставляет эти параметры для управления шифрованным подключением на стороне клиента:

В зависимости от требований шифрования учётной записи MySQL, используемой клиентом, может потребоваться указать определённые параметры для подключения с шифрованием к серверу MySQL.

Предположим, что вы хотите подключиться с учётной записью, у которой нет особых требований к шифрованию или которая была создана с помощью инструкции CREATE USER с включённой частью REQUIRE SSL. Предполагая, что сервер поддерживает шифрованные подключения, клиент может подключиться с шифрованием без параметра --ssl-mode или с явным параметром --ssl-mode=PREFERRED:

mysql

Или:

mysql --ssl-mode=PREFERRED

Для учётной записи, созданной с частью REQUIRE SSL, попытка подключения завершается ошибкой, если шифрованное подключение не может быть установлено. Для учётной записи без особых требований к шифрованию попытка возвращается к нешифрованному подключению, если шифрованное подключение не может быть установлено. Чтобы предотвратить возврат и завершиться ошибкой, если шифрованное подключение не может быть получено, подключитесь так:

mysql --ssl-mode=REQUIRED

Если учётная запись имеет более строгие требования к безопасности, для установления шифрованного подключения необходимо указать другие параметры:

Дополнительную информацию о части REQUIRE см. в Разделе 15.7.1.3, «CREATE USER Statement».

Серверы MySQL могут генерировать файлы сертификатов и ключей клиента, которые клиенты могут использовать для подключения к экземплярам сервера MySQL. См. Раздел 8.3.3, «Создание сертификатов SSL и RSA».

Чтобы предотвратить использование шифрования и переопределить другие --ssl-xxx параметры, вызовите клиентскую программу с --ssl-mode=DISABLED:

mysql --ssl-mode=DISABLED

Чтобы определить, использует ли текущее подключение к серверу шифрование, проверьте значение сессии переменной состояния Ssl_cipher. Если значение пустое, подключение не зашифровано. В противном случае подключение зашифровано, а значение указывает на используемый шифр шифрования. Например:

mysql> SHOW SESSION STATUS LIKE 'Ssl_cipher';
+---------------+---------------------------+
| Variable_name | Value                     |
+---------------+---------------------------+
| Ssl_cipher    | DHE-RSA-AES128-GCM-SHA256 |
+---------------+---------------------------+

Для клиента mysql альтернативой является использование команды STATUS или \s и проверка строки SSL:

mysql> \s
...
SSL: Not in use
...

Или:

mysql> \s
...
SSL: Cipher in use is DHE-RSA-AES128-GCM-SHA256
...