# SSL

Во многих случаях может потребоваться зашифровать трафик между клиентом и сервером. Для этого можно указать, что сервер должен использовать протокол [HTTPS](../Server_settings/Searchd.md#listen) вместо HTTP.

<!-- example CA 1 -->

Чтобы включить HTTPS, в секции [searchd](../Server_settings/Searchd.md) конфигурации должны быть установлены как минимум следующие две директивы, и должен быть настроен хотя бы один [слушатель](../Server_settings/Searchd.md#listen) на `https`:

* [ssl_cert](../Server_settings/Searchd.md#ssl_cert) — файл сертификата
* [ssl_key](../Server_settings/Searchd.md#ssl_key) — файл ключа

Кроме того, можно указать сертификат центра сертификации (также известный как корневой сертификат) в:

* [ssl_ca](../Server_settings/Searchd.md#ssl_ca) — файл сертификата центра сертификации


<!-- intro -->
##### с CA:

<!-- request with CA -->
Пример с CA:

```ini
ssl_ca = ca-cert.pem
ssl_cert = server-cert.pem
ssl_key = server-key.pem
```

<!-- request without CA -->
Пример без CA:

```ini
ssl_cert = server-cert.pem
ssl_key = server-key.pem
```
<!-- end -->

## Генерация SSL-файлов

Эти шаги помогут вам сгенерировать SSL-сертификаты с помощью инструмента 'openssl'.

Сервер может использовать Центр сертификации для проверки подписи сертификатов, но также может работать только с приватным ключом и сертификатом (без сертификата CA).

#### Генерация ключа CA

```bash
openssl genrsa 2048 > ca-key.pem
```

#### Генерация сертификата CA из ключа CA

Чтобы сгенерировать самоподписанный CA (корневой) сертификат из приватного ключа (обязательно заполните хотя бы "Common Name"), используйте следующую команду:

```bash
openssl req -new -x509 -nodes -days 365 -key ca-key.pem -out ca-cert.pem
```

#### Сертификат сервера

Сервер использует сертификат сервера для защиты связи с клиентом. Чтобы сгенерировать запрос на сертификат и приватный ключ сервера (убедитесь, что вы заполнили хотя бы "Common Name" и что он отличается от общего имени корневого сертификата), выполните следующие команды:

```bash
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
```

После завершения вы можете проверить, что файлы ключа и сертификата были сгенерированы правильно, выполнив:

```bash
openssl verify -CAfile ca-cert.pem server-cert.pem
```

## Поведение защищённого соединения

При наличии корректной SSL-конфигурации доступны следующие возможности:

 * Вы можете подключиться к мультипротокольному порту (когда [тип слушателя](../Server_settings/Searchd.md#listen) не указан) по 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-туннелирование) для защиты своих соединений.
<!-- proofread -->

