Во многих случаях вы можете захотеть зашифровать трафик между вашим клиентом и сервером. Для этого вы можете указать, что сервер должен использовать протокол HTTPS вместо HTTP.
Чтобы включить HTTPS, как минимум должны быть установлены следующие две директивы в секции searchd конфигурационного файла, и должен быть хотя бы один listener, настроенный на https
Кроме того, вы можете указать сертификат центра сертификации (также известный как корневой сертификат) в:
- ssl_ca файл сертификата центра сертификации
Пример с CA:
ssl_ca = ca-cert.pem
ssl_cert = server-cert.pem
ssl_key = server-key.pem
Пример без CA:
ssl_cert = server-cert.pem
ssl_key = server-key.pem
Эти шаги помогут вам сгенерировать SSL сертификаты с помощью инструмента 'openssl'.
Сервер может использовать Центр Сертификации для проверки подписи сертификатов, но он также может работать только с приватным ключом и сертификатом (без сертификата CA).
openssl genrsa 2048 > ca-key.pem
Чтобы сгенерировать самоподписанный сертификат CA (корневой) из приватного ключа (обязательно заполните хотя бы поле "Common Name"), используйте следующую команду:
openssl req -new -x509 -nodes -days 365 -key ca-key.pem -out ca-cert.pem
Сервер использует сертификат сервера для защиты связи с клиентом. Чтобы сгенерировать запрос на сертификат и приватный ключ сервера (убедитесь, что вы заполнили хотя бы "Common Name" и что он отличается от общего имени корневого сертификата), выполните следующие команды:
openssl req -newkey rsa:2048 -days 365 -nodes -keyout server-key.pem -out server-req.pem
openssl rsa -in server-key.pem -out server-key.pem
openssl x509 -req -in server-req.pem -days 365 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem
После завершения вы можете проверить, что файлы ключа и сертификата были сгенерированы корректно, выполнив:
openssl verify -CAfile ca-cert.pem server-cert.pem
Когда ваша SSL конфигурация действительна, доступны следующие возможности:
- Вы можете подключаться к мультипротокольному порту (когда не указан тип listener) по HTTPS и выполнять запросы. И запрос, и ответ будут зашифрованы SSL.
- Вы можете подключаться к выделенному https порту с помощью HTTP и выполнять запросы. Соединение будет защищено (попытка подключения к этому порту через обычный HTTP будет отклонена с кодом ошибки 400).
- Вы можете подключаться к порту MySQL с помощью MySQL клиента, используя защищённое соединение. Сессия будет защищена. Обратите внимание, что Linux клиент
mysql по умолчанию пытается использовать SSL, поэтому типичное подключение к Manticore с действительной SSL конфигурацией, скорее всего, будет защищённым. Вы можете проверить это, выполнив SQL команду 'status' после подключения.
Если ваша SSL конфигурация по какой-либо причине недействительна (что демон обнаруживает по тому, что защищённое соединение не может быть установлено), помимо неверной конфигурации могут быть и другие причины, например, невозможность загрузить соответствующую SSL библиотеку вообще. В этом случае следующие функции не будут работать или будут работать в незашищённом режиме:
- Вы не сможете подключиться к мультипротокольному порту по HTTPS. Соединение будет разорвано.
- Вы не сможете подключиться к выделенному порту
https. HTTPS соединения будут разорваны.
- Подключение к порту
mysql через MySQL клиент не будет поддерживать SSL защиту. Если клиент требует SSL, соединение не удастся. Если SSL не требуется, будет использоваться обычное MySQL или сжатое соединение.
- Соединения Binary API (например, соединения от старых клиентов или междемонное master-agent общение) не защищены.
- SSL для репликации нужно настраивать отдельно. Однако, поскольку этап SST репликации выполняется через соединение Binary API, он также не защищён.
- Вы всё ещё можете использовать любые внешние прокси (например, SSH туннелирование) для защиты ваших соединений.