Переменные системы 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.9, «Таблица 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
...