Шифрование связи в zVirt

1. Мониторинг и управление сертификатами

1.1. Общие сведения о сертификатах

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

Своевременное обновление сертификатов является важным требованием для обеспечения работоспособности платформы zVirt.

Автоматическое обновление сертификатов не производится, поэтому очень важно обновлять сертификаты вручную до истечения сроков их действия.

Если вы допустите истечение срока действия сертификатов, то это приведет к следующим проблемам:

Менеджер управления и хосты перестанут взаимодействовать.
Станет невозможным вход в веб-порталы (портал администрирования и пользовательский портал).
Виртуальные машины продолжат работать, но управление ими будет недоступно.
Миграция виртуальных машин станет невозможной.
Выключение виртуальных машин приведет к невозможности их запуска.

Ниже представлена таблица с описанием основных сертификатов, используемых в zVirt.

Таблица 1. Основные сертификаты
Наименование	Назначение	Расположение
Сертификаты Менеджера управления Эти сертификаты можно найти в указанном каталоге на Менеджере управления.
Apache-ca	Доверенный корневой сертификат Apache. По умолчанию такой же как CA.	/etc/pki/ovirt-engine/apache-ca.pem
Apache	Используется для HTTPS соединений с веб-интерфейсом	/etc/pki/ovirt-engine/certs/apache.cer
websocket-proxy	Сертификат для обеспечения безопасного соединения через WebSocket, используемого для реализации двустороннего соединения между клиентом и сервером. Используется при NoVNC доступе к консоли ВМ.	/etc/pki/ovirt-engine/certs/websocket-proxy.cer
CA	Корневой сертификат Менеджера управления. Используется для подписи других сертификатов в системе.	/etc/pki/ovirt-engine/ca.pem
Engine	Используется менеджером управления для ssh и ssl аутентификации на хостах и vdsm, также используется для шифрования полей базы данных.	/etc/pki/ovirt-engine/certs/engine.cer
Qemu-ca	Корневой сертификат для QEMU/KVM.	/etc/pki/ovirt-engine/qemu-ca.pem
jboss	Сертификат сервера приложений JBoss/WildFly	/etc/pki/ovirt-engine/certs/jboss.cer
ovn-sdb	Сертификаты для баз данных OVN	/etc/pki/ovirt-engine/certs/ovn-sdb.cer
ovn-ndb	Сертификаты для баз данных OVN	/etc/pki/ovirt-engine/certs/ovn-ndb.cer
vmconsole-proxy-helper	Сертификаты для создания защищённого канала связи при доступе к консоли виртуальных машин (VNC или SPICE).	/etc/pki/ovirt-engine/certs/vmconsole-proxy-helper.cer
vmconsole-proxy-host		/etc/pki/ovirt-engine/certs/vmconsole-proxy-host.cer
vmconsole-proxy-user		/etc/pki/ovirt-engine/certs/vmconsole-proxy-user.cer
ovirt-provider-ovn	Сертификат для OVN (Open Virtual Network), инструмента для программного определения сетей виртуальных машин	/etc/pki/ovirt-engine/certs/ovirt-provider-ovn.cer
Сертификаты хостов
cacert	Доверенный корневой сертификат Менеджера управления.	/etc/pki/vdsm/certs/cacert.pem
vdsmcert	Сертификат VDSM	/etc/pki/vdsm/certs/vdsmcert.pem
ca-cert (libvirt-spice)	Корневой сертификат для SPICE. Такой же как корневой сертификат VDSM (cacert).	/etc/pki/vdsm/libvirt-spice/ca-cert.pem
ca-cert (libvirt-vnc)	Корневой сертификат для VNC. Такой же как корневой сертификат VDSM (cacert).	/etc/pki/vdsm/libvirt-vnc/ca-cert.pem
ca-cert (libvirt-migrate)	Корневой сертификат, необходимый для миграции. Такой же как корневой сертификат VDSM (cacert).	/etc/pki/vdsm/libvirt-migrate/ca-cert.pem
server-cert (libvirt-spice)	Сертификат SPICE-сервера. Такой же как сертификат VDSM (vdsmcert).	/etc/pki/vdsm/libvirt-spice/server-cert.pem
server-cert (libvirt-vnc)	Сертификат VNC-сервера. Такой же как сертификат VDSM (vdsmcert).	/etc/pki/vdsm/libvirt-vnc/server-cert.pem
server-cert (libvirt-migrate)	Используется при миграции ВМ для взаимной аутентификации между хостами. Такой же как сертификат VDSM (vdsmcert).	/etc/pki/vdsm/libvirt-migrate/server-cert.pem
clientcert	Сертификат libvirt. Такой же как сертификат VDSM (vdsmcert).	/etc/pki/libvirt/clientcert.pem

1.2. Основные каналы взаимодействия

Инфраструктура открытых ключей (PKI) используется для безопасного взаимодействия между различными компонентами платформы. Основные направления взаимодействия и способы их защиты:

Менеджер управления → SSL → vdsm

Во время развертывания хоста в качестве гипервизора сертификат регистрируется с помощью внутреннего ЦС Менеджера. Связь между Менеджером и хостом осуществляется с помощью взаимно аутентифицированной SSL-сессии на основе сертификата Менеджера (Engine) и сертификата vdsm (vdsmcert).

Vdsm не выполняет проверку отзыва сертификата.
На текущий момент не поддерживаются промежуточные сертификаты.

Менеджер управления → SSH → хосты

Менеджер управления способен аутентифицироваться с помощью открытого ключа своего сертификата на хостах с использованием протокола SSH.

Менеджер не выполняет проверку отзыва сертификата.
На текущий момент не поддерживаются промежуточные сертификаты.

Менеджер управления → SSL → база данных

В зависимости от настроек подключения, соединение с базой данных может использовать SSL. При этом доверенными являются центры сертификации jre по адресу $JAVA_HOME/lib/security/cacerts.

Пользователь → SSL → Apache → AJP → Менеджер управления

Пользователь получает доступ к Менеджеру через веб-сервер apache с помощью веб-браузера, используя TLS/SSL. По умолчанию сертификат выдается внутренним центром сертификации Менеджера, но этот сертификат может быть заменен на любой сторонний сертификат без ограничения функциональности.

Замена сертификата может быть произведена с помощью ручной настройки mod_ssl или путем замены следующих файлов в /etc/pki/ovirt-engine:

apache-ca.pem
keys/apache.p12
keys/apache.key.nopass
certs/apache.cer

Пользователь → SSL → SPICE

Qemu настроен на использование того же сертификата, что и vdsm. Во время инициации сессии внутренний сертификат Менеджера управления отправляется клиенту spice в качестве доверенного корневого, чтобы сессия могла быть установлена.

На текущий момент не поддерживаются промежуточные сертификаты.

libvirt → SSL → libvirt или qemu → SSL → qemu

Используется при миграции для взаимной аутентификации с помощью сертификата vdsm.

На текущий момент не поддерживаются промежуточные сертификаты.

Хост → SSL → Менеджер управления

Используется для протокола регистрации, веб-сертификат извлекается при SSL-рукопожатии, на основании отпечатка устанавливается доверие. Затем извлекается открытый ключ SSH (открытый ключ сертификата Менеджера) и устанавливается для пользователя root.

Хост не выполняет проверку отзыва сертификата.

log-collector → SSH → Хосты

Использует тот же метод и ключи, что и Менеджер управления, для доступа к хостам.

1.3. Срок жизни сертификатов

В zVirt 3.3 и старше срок жизни всех самоподписанных сертификатов составляет 389 дней.

В zVirt 4.0 и новее:

Корневые сертификаты центра сертификации Менеджера управления - 10 лет.
Самоподписанные сертификаты, используемые для взаимодействия между Менеджером управления и хостами имеют срок жизни по умолчанию 5 лет.
Самоподписанные сертификаты, видимые для браузеров, имеют срок жизни по умолчанию 389 дней и их необходимо обновлять раз в год. К таким сертификатам относятся сертификаты веб-портала:
- Apache
- Websocket-proxy

1.4. Управление сертификатами через портал администрирования

Начиная с zVirt 4.3 в портал администрирования добавлена утилита для мониторинга и управления сертификатами.

Утилита позволяет:

Отслеживать статус сертификатов менеджера управления, веб-портала и хостов.
Продлевать срок действия сертификатов веб-портала (Apache и Websocket-proxy).
Выполнять замену сертификатов веб-портала (Apache и Websocket-proxy).

1.4.1. Мониторинг сертификатов

Для проверки текущего статуса сертификатов выполните следующие действия:

Авторизуйтесь на портале администрирования с правами, достаточными для управления сертификатами.
Перейдите в Управление Сертификаты.
На странице сертификатов будет представлен общий статус сертификатов, а также список категорий сертификатов.

В каждой категории представлена таблица со следующими данными о сертификатах:

Название.
Расположение.
Дата окончания.
Текущий статус.

Каждый сертификат может принимать различные статусы, указывающие на возможные проблемы с сертификатом:

В штатном состоянии в поле Статус указывается количество дней до окончания срока действия сертификата.
В случае, если путь к файлу сертификата не может быть найден, то в поле Расположение выводится Неизвестное расположение сертификата.
В случае, если не удается проверить срок действия сертификата, статус меняется на Неизвестно.
Если срок действия сертификата становится 30 дней и менее, он выделяется желтым.
Если срок действия сертификата истек, он выделяется красным.

1.4.2. Обновление самоподписанных сертификатов веб-портала

Процедура обновления сертификатов применяется к сертификатам веб-портала (кроме корневого) и позволяет продлить срок их действия.

При обновлении сертификатов будут перезапущены веб-службы Менеджера управления, поэтому в течение некоторого времени будет отсутствовать доступ к веб-порталу. Это никак не влияет на работу виртуальных машин и сервисов в гостевых операционных системах.

Порядок действий:

Авторизуйтесь на портале администрирования с правами, достаточными для управления сертификатами.
Перейдите в Управление Сертификаты.
Разверните категорию Сертификаты веб-портала.
Нажмите Обновить.
В окне перевыпуска сертификатов в поле Срок продления сертификатов укажите количество дней на сколько необходимо продлить сертификаты.

Нажмите Продлить.

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

После повторной авторизации убедитесь, что в Управление Сертификаты отображаются обновленные статусы сертификатов веб-портала.

1.4.3. Загрузка и обновление сторонних сертификатов веб-портала

Процедура загрузки и обновления сторонних сертификатов применяется к сертификатам веб-портала (кроме корневого) и позволяет продлить срок их действия.

Предварительные требования:

Наличие сертификата веб-портала полученного от центра сертификации в формате PKCS#12.

Сертификат веб-портала обязательно должен иметь заполненное поле SAN со значением, дублирующим значение CN.

Наличие корневого сертификата центра сертификации в кодировке BASE-64.

Если сертификат веб-портала подписан промежуточным сертификатом предприятия, то нужно скомпоновать единый PEM-файл, где сначала указывается промежуточный сертификат, а после него корневой сертификат.

-----BEGIN CERTIFICATE-----
Промежуточный сертификат
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Корневой сертификат
-----END CERTIFICATE-----

У промежуточного сертификата необходимо наличие секции CA: TRUE в x509 расширении.

Файл с расширением pfx должен содержать внутри себя закрытый ключ для дальнейшей успешной конвертации.
Файл с расширением pfx , содержащий внутри себя закрытый ключ, может быть переименован в файл с расширением p12 без дополнительной конвертации.
Файл с расширением pem должен быть в кодировке BASE-64 . Проверить корректность кодировки BASE-64 можно открыв данный сертификат блокнотом. Если кодировка корректна, то сертификат будет расположен между строками -----BEGIN CERTIFICATE----- и -----END CERTIFICATE----- . Если в файле с расширением pem используется кодировка DER, то произвести конвертацию в BASE-64 можно командной:
```
openssl x509 -in input.cer -inform DER -out output.pem
```

Порядок действий:

Авторизуйтесь на портале администрирования с правами, достаточными для управления сертификатами.
Перейдите в Управление Сертификаты.
Разверните категорию Сертификаты веб-портала.
Нажмите Обновить.
В окне перевыпуска сертификатов нажмите Загрузить.
В окне загрузки:
- В поле Сертификат веб-портала загрузите сертификат веб-портала.
- Если сертификат защищен паролем, введите необходимый Пароль.
- В поле Файл промежуточных сертификатов загрузите корневой или объединенный сертификат центра сертификации.
Нажмите Заменить.

В окне предупреждения при необходимости активируйте опцию вывода кластера из обслуживания. Нажмите Продолжить.

После повторной авторизации убедитесь, что в Управление Сертификаты отображаются обновленные статусы сертификатов веб-портала.

1.4.4. Настройка роли для управления сертификатами

Для настройки и управления сертификатами через портал администрирования, необходима авторизация на портале с учетной записью, имеющей системное разрешение Управление сертификатами.

По умолчанию этим разрешением обладает любой пользователь с ролью SuperUser, но при необходимости можно создать новую роль с правами на управление этими сервисами.

Для этого:

Авторизуйтесь на портале администрирования с правами, достаточными для управления пользователями и ролями.
Создайте новую административную роль с разрешениями на вход и Управление сертификатами:
1. Перейдите в Управление Настройки.
2. На вкладке Роли нажмите Новая.
3. В окне создания роли:
  Введите уникальное имя роли.
  
  Выберите тип учетной записи Администратор.
  
  В разделе опций для разрешенных действий разверните Система → Настроить систему.
  
  Отметьте разрешения Разрешения входа и Управление сертификатами.
  
  Нажмите OK.
Назначьте роль нужному пользователю или группе:
1. В Управление Настройки.
2. На вкладке Системные разрешения нажмите Добавить.
3. В окне добавления роли найдите нужного пользователя или группу и отметьте его
4. В раскрывающемся списке Назначаемая роль выберите созданную ранее роль.
5. Нажмите OK.
Проверьте доступность управления сертификатами, авторизовавшись на портале администрирования пользователем с назначенной ролью.

1.5. Управление сертификатами через командную оболочку

1.5.1. Замена сертификата Менеджера управления, выданного Центром сертификации

Не изменяйте разрешения и параметры владения для каталога /etc/pki и его подкаталогов. Разрешение для каталога /etc/pki и /etc/pki/ovirt-engine должно оставаться в значении по умолчанию: 755.

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

Сертификат стороннего ЦС (Certificate Authority) предоставляется в виде PEM-файла. Цепочка сертификатов должна быть полной вплоть до корневого сертификата. Порядок цепочки сертификатов является критически важным, цепочка должна строится от последнего промежуточного ЦС до корневого ЦС. В противном случае при проверке подлинности сервера может произойти сбой.

Использование сертификата, выданного альтернативным Центром сертификации, для HTTPS-подключений не влияет на сертификат, используемый для аутентификации между Менеджером управления и хостами. Они будут продолжать использовать самоподписанный сертификат, созданный Менеджером управления.

1.5.1.1. Соглашения

/root - расположение файлов полученных от ЦС или в процессе выполнения процедуры замены.
/root/apache.p12 - сертификат полученный от ЦС в формате PKCS#12.

Для версии zVirt 4.1 файл должен быть защищен паролем mypass.
/root/ca.pem - сертификат ЦС.
/root/apache.key - новый закрытый ключ веб-сервера.
/root/apache.cer - новый сертификат веб-сервера.

Файл с расширением pfx должен содержать внутри себя закрытый ключ для дальнейшей успешной конвертации.
Файл с расширением pfx , содержащий внутри себя закрытый ключ, может быть переименован в файл с расширением p12 без дополнительной конвертации.
Файл с расширением pem должен быть в кодировке BASE-64 . Проверить корректность кодировки BASE-64 можно открыв данный сертификат блокнотом. Если кодировка корректна, то сертификат будет расположен между строками -----BEGIN CERTIFICATE----- и -----END CERTIFICATE----- . Если в файле с расширением pem используется кодировка DER, то произвести конвертацию в BASE-64 можно командной:
```
openssl x509 -in input.cer -inform DER -out output.pem
```

1.5.1.2. Описание процедуры замены SSL-сертификата

Извлечение сертификата и закрытого ключа из пакета P12

Внутренний ЦС хранит ключ и сертификат в формате .p12 в каталоге /etc/pki/ovirt-engine/keys/. Сохраните новый файл в том же месте.

Создайте резервную копию текущего файла apache.p12, например:
```
cp -p /etc/pki/ovirt-engine/keys/apache.p12 /etc/pki/ovirt-engine/keys/apache.p12.bck
```
Замените текущий файл новым, например:
```
cp /root/apache.p12 /etc/pki/ovirt-engine/keys/apache.p12
```
Извлеките закрытый ключ и сертификат.
Если файл защищен паролем, необходимо добавить -passin pass:<your_password>, заменив <your_password> на действительный пароль.
openssl pkcs12 -in /etc/pki/ovirt-engine/keys/apache.p12 -nocerts -nodes > /root/apache.key openssl pkcs12 -in /etc/pki/ovirt-engine/keys/apache.p12 -nokeys > /root/apache.cer

Замена сертификата Менеджера управления, выданного Центром Сертификации Apache

Если zVirt развернут в режиме Hosted Engine, необходимо перейти в консоль хоста и включить режим глобального обслуживания:
```
hosted-engine --set-maintenance --mode=global
```
Если сертификат apache.p12 подписан промежуточным сертификатом предприятия, то нужно подготовить файл для добавления в хранилище сертификатов: нужно скомпоновать единый файл ca.pem, где сначала указывается промежуточный сертификат, а после него корневой сертификат.
```
-----BEGIN CERTIFICATE-----
Промежуточный сертификат
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Корневой сертификат
-----END CERTIFICATE-----
```

Добавьте сертификат ЦС в список доверенных сертификатов (пароль mypass), например:

keytool -import \
    -file /root/ca.pem  \
    -alias companyca \
    -keystore /etc/pki/ovirt-engine/.truststore

cp /root/ca.pem /etc/pki/ca-trust/source/anchors

update-ca-trust

Менеджер управления использует файл /etc/pki/ovirt-engine/apache-ca.pem, который является символической ссылкой на файл /etc/pki/ovirt-engine/ca.pem. Удалите символическую ссылку:
```
rm /etc/pki/ovirt-engine/apache-ca.pem
```
Сохраните сертификат ЦС, как файл /etc/pki/ovirt-engine/apache-ca.pem:
```
cp /root/ca.pem /etc/pki/ovirt-engine/apache-ca.pem
```

Создайте резервную копию существующего закрытого ключа и сертификата:

cp /etc/pki/ovirt-engine/keys/apache.key.nopass /etc/pki/ovirt-engine/keys/apache.key.nopass.bck
cp /etc/pki/ovirt-engine/certs/apache.cer /etc/pki/ovirt-engine/certs/apache.cer.bck

Скопируйте закрытый ключ:

cp /root/apache.key /etc/pki/ovirt-engine/keys/apache.key.nopass

Установите владельцем закрытого ключа пользователя root и задайте права доступа 0640:
```
chown root:ovirt /etc/pki/ovirt-engine/keys/apache.key.nopass
chmod 640 /etc/pki/ovirt-engine/keys/apache.key.nopass
```

Скопируйте сертификат:

cp /root/apache.cer /etc/pki/ovirt-engine/certs/apache.cer

Установите владельцем сертификата пользователя root и задайте права доступа 0644:
```
chown root:ovirt /etc/pki/ovirt-engine/certs/apache.cer
chmod 644 /etc/pki/ovirt-engine/certs/apache.cer
```
Перезапустите веб-сервер:
```
systemctl restart httpd.service
```
В конфигурационном файле /usr/share/zvirt-engine/services/zvirt-engine-backend/zvirt-engine-backend.conf сервиса измените параметр SERVER_SSL_KEY_STORE_PASSWORD (если строка отсутствует - добавьте), для которого укажите пароль от вашего сертификата /root/apache.p12. Если пароль не используется, то оставьте поле пустым (без кавычек: SERVER_SSL_KEY_STORE_PASSWORD=)
Пример 1. Пример содержимого файла /usr/share/zvirt-engine/services/zvirt-engine-backend/zvirt-engine-backend.conf
ENGINE_DEBUG_ADDRESS=*:8686 JBACKEND_HOME=/usr/share/java/zvirt/ SERVER_SSL_KEY_STORE_PASSWORD=apachep12pass
Перезапустите сервис backend.
```
systemctl restart zvirt-engine-backend.service
```
Скопируйте файл /etc/ovirt-engine/ovirt-websocket-proxy.conf.d/10-setup.conf и измените индекс в файле на значение, которое больше 10 (например, 99-setup.conf). Добавьте следующие параметры в новый файл (если строки уже присутствуют их необходимо заменить):
```
SSL_CERTIFICATE=/etc/pki/ovirt-engine/certs/apache.cer
SSL_KEY=/etc/pki/ovirt-engine/keys/apache.key.nopass
```
Перезапустите службу websocket-proxy:
```
systemctl restart ovirt-websocket-proxy.service
```
Если вручную производились изменения файла /etc/ovirt-provider-ovn/conf.d/10-setup-ovirt-provider-ovn.conf или используется файл конфигурации более ранней версии zVirt, необходимо убедиться, что менеджер управления по-прежнему настроен на использование /etc/pki/ovirt-engine/apache-ca.pem в качестве сертификата.
Перезапустите сервис ovirt-provider-ovn:
```
systemctl restart ovirt-provider-ovn.service
```
Перезапустите сервис ovirt-imageio:
```
systemctl restart ovirt-imageio.service
```
Перезапустите сервис ovirt-engine:
```
systemctl restart ovirt-engine.service
```
Если zVirt развернут в режиме Hosted Engine, необходимо перейти в консоль хоста и выключить режим глобального обслуживания:
```
hosted-engine --set-maintenance --mode=none
```

Теперь пользователи могут подключаться к Порталу администрирования и Пользовательскому порталу, не видя предупреждения о подлинности сертификата, используемого для шифрования HTTPS-трафика.

2. Настройка шифрованной связи между Менеджером управления и LDAP-сервером

Данная статья применима только к установке с AAA-JDBC. Пример настройки безопасного соединения с LDAP для установки с Keycloak используйте процедуру, описанную в статье Настройка федерации пользователей c Active Directory через LDAPs.

Чтобы настроить шифрованную связь между Менеджером управления и LDAP-сервером, получите корневой сертификат LDAP-сервера, выданный Центром сертификации, скопируйте этот корневой сертификат в Менеджер управления и создайте сертификат, выданный Центром сертификации, в PEM-кодировке. Тип хранилища ключей может быть любым типом, поддерживаемым Java. В следующей процедуре используется формат Java KeyStore (JKS).

Дополнительные сведения о создании сертификата Центра сертификации в кодировке PEM и импорте сертификатов см. в разделе X.509 CERTIFICATE TRUST STORE файла README, размещенного в /usr/share/doc/ovirt-engine-extension-aaa-ldap-version.

Порядок действий:

В Менеджере управления скопируйте корневой сертификат LDAP-сервера, выданный Центром сертификации, в каталог /tmp и импортируйте корневой сертификат Центра сертификации с помощью keytool, чтобы создать сертификат Центра сертификации в кодировке PEM. Следующая команда импортирует корневой сертификат Центра сертификации в /tmp/myrootca.pem и создает корневой сертификат Центра сертификации в кодировке PEM myrootca.jks в /etc/ovirt-engine/aaa/. Выпишите местонахождение сертификата и пароль. Если вы используете интерактивный инструмент настройки, то это – вся информация, которая вам понадобится. Если вы настраиваете LDAP-сервер вручную, выполните оставшуюся часть процедуры, чтобы обновить файлы конфигурации.
```
$ keytool \
    -importcert \
    -noprompt \
    -trustcacerts \
    -alias _myrootca_ \
    -file _/tmp/myrootca.pem_ \
    -keystore _/etc/ovirt-engine/aaa/myrootca.jks_ \
    -storepass _password_
```

Обновите файл /etc/ovirt-engine/aaa/profile1.properties, внеся в него сведения о сертификате:

${local:_basedir} – это каталог, где находится файл конфигурации свойств LDAP, указывающий на каталог /etc/ovirt-engine/aaa. Если вы создали сертификат Центра сертификации в кодировке PEM в другом каталоге, замените ${local:_basedir} полным путем к сертификату.

Чтобы использовать startTLS (рекомендуется):

# Create keystore, import certificate chain and uncomment
pool.default.ssl.startTLS = true
pool.default.ssl.truststore.file = ${local:_basedir}/_myrootca.jks_
pool.default.ssl.truststore.password = _password_

Чтобы использовать SSL:

# Create keystore, import certificate chain and uncomment
pool.default.serverset.single.port = 636
pool.default.ssl.enable = true
pool.default.ssl.truststore.file = ${local:_basedir}/_myrootca.jks_
pool.default.ssl.truststore.password = _password_

Чтобы продолжить настройку внешнего провайдера LDAP, см. раздел Настройка внешнего провайдера LDAP. Чтобы продолжить настройку LDAP и Kerberos для единого входа, см. раздел Настройка LDAP и Kerberos для единого входа.