Во многих случаях может потребоваться зашифровать трафик между клиентом и сервером. Для этого можно указать, что сервер должен использовать протокол HTTPS вместо HTTP.
Чтобы включить HTTPS, в секции searchd конфигурации должны быть установлены как минимум следующие две директивы, и должен быть настроен хотя бы один слушатель на 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-конфигурации доступны следующие возможности:
- Вы можете подключиться к мультипротокольному порту (когда тип слушателя не указан) по HTTPS и выполнять запросы. Как запрос, так и ответ будут зашифрованы по SSL.
- Вы можете подключиться к выделенному HTTPS-порту по HTTP и выполнять запросы. Соединение будет защищено (попытка подключиться к этому порту по обычному HTTP будет отклонена с кодом ошибки 400).
- Вы можете подключиться к MySQL-порту с помощью MySQL-клиента, используя защищённое соединение. Сессия будет защищена. Обратите внимание, что клиент
mysql в Linux по умолчанию пытается использовать SSL, поэтому типичное подключение к Manticore с корректной SSL-конфигурацией, скорее всего, будет защищённым. Вы можете проверить это, выполнив SQL-команду 'status' после подключения.
Если ваша SSL-конфигурация по какой-либо причине недействительна (что демон определяет по факту невозможности установить защищённое соединение), помимо неверной конфигурации могут быть и другие причины, например, невозможность загрузить соответствующую SSL-библиотеку вообще. В этом случае следующие вещи не будут работать или будут работать в незащищённом режиме:
- Вы не можете подключиться к мультипротокольному порту по HTTPS. Соединение будет разорвано.
- Вы не можете подключиться к выделенному порту
https. HTTPS-соединения будут разорваны.
- Подключение к порту
mysql через MySQL-клиент не будет поддерживать защиту SSL. Если клиент требует SSL, соединение завершится ошибкой. Если SSL не требуется, будет использоваться обычное MySQL-соединение или сжатое соединение.
- Соединения по бинарному API (например, соединения от старых клиентов или междемонная связь master-agent) не защищены.
- SSL для репликации необходимо настраивать отдельно. Однако, поскольку этап SST репликации выполняется через соединение бинарного API, он также не защищён.
- Вы по-прежнему можете использовать любые внешние прокси (например, SSH-туннелирование) для защиты своих соединений.