Установка и настройка цепочки сертификатов WiKID

Краткий обзор

Эта статья подробно описывает процесс первоначальной установки сервера аутентификации WiKID и генерации цепочки сертификатов, которая необходима для защищённой работы всех протоколов и модулей сервера. Описаны все этапы: от создания промежуточного CA до установки локального сертификата и перезапуска служб. Также приведены практические чеклисты, сценарии тестирования, руковoдство при инцидентах и рекомендации по безопасности.

Важно: приватный ключ, сгенерированный на шаге 1, обязателен для корректной работы сертификата. Если ключ потерян, придётся повторить весь процесс.

Первичная страница установки

Установка сервера аутентификации WiKID проходит в несколько простых шагов. Сначала вы создаёте промежуточный центр сертификации, затем устанавливаете его, создаёте сертификат для «localhost» и активируете нужные протокольные модули. После этого можно добавлять домены, сетевые клиенты и пользователей.

Подпись: Главная страница первичной администрации сервера WiKID

Настройка цепочки сертификатов

WiKID использует сертификаты для нескольких внутренних функций:

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

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

Шаг 1: Генерация промежуточного CA

Первый шаг — сгенерировать пару открытого/закрытого ключей. Эти ключи будут идентифицировать сервер и использоваться для асимметричного шифрования SSL. Сервер поставляется с копией корпоративного CA WiKID, но вам нужно создать собственный промежуточный CA.

Выберите Generate и заполните форму. Все поля обязательны.

Подпись: Экран создания промежуточного центра сертификации

Поля и их значение:

Intermediate CA Administrator Email: рабочий адрес электронной почты для получения подписанного сертификата.
Servers Fully Qualified Domain Name: полное имя сервера в DNS. Клиенты SSL ожидают, что это имя совпадает с именем хоста, к которому они подключаются.
Organization Unit: подразделение или отдел.
Organization Name: юридическое имя организации, управляющей сервером.
Locality: город.
State: штат или провинция, без сокращений.
Country Code: двухбуквенный код страны, например US.
Passphrase: фраза-пароль для защиты закрытого ключа в PKCS#12. Она потребуется при каждом запуске сервера. Фраза не сохраняется и не восстанавливается — выберите надёжную и запоминающуюся фразу.

После заполнения выберите Generate. Система сгенерирует ключи и CSR (Certificate Signing Request). Вы увидите экран с CSR в кодировке base64 DER.

Подпись: Запрошенный CSR в кодировке base64

Скопируйте всё содержимое текстового поля в буфер обмена.

Шаг 2: Отправка CSR на подпись

Перейдите по ссылке, расположенной над текстовым полем CSR, чтобы открыть страницу отправки запроса на подпись сертификата WiKID CA. Вставьте текст CSR, включая строки с дефисами, и отправьте форму.

Подпись: Экран отправки CSR на подпись

После отправки вы получите номер запроса для отслеживания. Администраторы CA обработают запрос и отправят подписанный сертификат на указанный электронный адрес. Обычно это занимает не более одного рабочего дня.

Подпись: Пример присланного блока сертификата в письме

Примечание: сертификат бесполезен без соответствующего закрытого ключа, сгенерированного на шаге 1. Всегда копируйте текст сертификата как plain text; почтовые клиенты иногда меняют кодировку.

Шаг 3: Установка подписанного сертификата

После получения подписанного сертификата вернитесь на вкладку Установка промежуточного CA и выберите Install. Вставьте текст сертификата из письма в предоставленное поле и введите фразу-пароль, использованную при генерации закрытого ключа на шаге 1. Затем выполните установку промежуточного сертификата.

Подпись: Экран установки подписанного промежуточного сертификата

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

Шаг 4: Создание сертификата для localhost

Все локальные протоколы и модули, взаимодействующие с сервером, должны иметь сертификат, подписанный вашим промежуточным CA. Это предотвращает неавторизованный доступ.

Некоторые протоколы (RADIUS, LDAP, wAuth и т. п.) сами по себе не поддерживают аутентификацию по сертификатам или защищённый транспорт. WiKID предоставляет протокольные модули, которые преобразуют эти протоколы в защищённый канал. Поэтому даже при отсутствии поддержки сертификатов на стороне клиента LDAP-интерфейс WiKID требует действительного сертификата для проверки учётных данных.

Для локальных служб сгенерируйте сертификат, указав в поле «Полное имя клиента» значение «localhost». Имя должно быть именно «localhost». Заполните остальные поля и задайте PKCS#12-пароль для клиентского сертификата.

Подпись: Экран генерации локального (localhost) сертификата

Поля и значение:

Client’s Fully Qualified Domain Name: для локальных сервисов — «localhost».
Organization Name, Locality, State, Country Code: как и ранее.
Client PKCS12 Passphrase: пароль для упаковки клиентского сертификата в PKCS#12.
Passphrase again: повтор пароля для проверки.
Server Keystore Passphrase: фраза-пароль промежуточного CA, созданного на шаге 1.

После нажатия Generate вы получите сообщение с указанием местоположения сгенерированного сертификата. Для localhost он уже будет установлен в нужной директории.

Подпись: Экран с указанием местоположения PKCS#12-файла

Шаг 5: Перезапуск служб wAuth

Выполните перезапуск сервисов от root-пользователя:

wikidctl restart

При перезапуске система запросит фразу-пароль wAuth — это фраза, созданная вами на шаге 1. При корректном вводе сервер начнёт использовать новый сертификат для аутентификации клиентов.

Если вы хотите автоматизировать запуск без ручного ввода фразы-пароля, создайте файл /etc/WiKID/security и добавьте одну строку:

WAUTH_PASSPHRASE=ваш_надёжный_пароль

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

Критерии приёмки

Перед тем как считать установку завершённой, проверьте следующее:

Промежуточный CA установлен и доступен в интерфейсе администратора.
Подписанный сертификат успешно импортирован и сопоставлен с соответствующим закрытым ключом.
Сертификат для localhost сгенерирован и установлен.
Все критические службы (LDAP, RADIUS, wAuth) успешно стартуют и принимают подключения.
В логах отсутствуют ошибки TLS/SSL при старте.
Сервис отвечает на тестовые запросы от доверенных клиентов.

Тестовые сценарии и критерии приёмки

Подключение тестового LDAP-клиента через локальный интерфейс. Ожидаемый результат: успешная TLS-сессия и возможность проверки учётных данных.
Подключение тестового RADIUS-клиента через протокольный модуль. Ожидаемый результат: защищённый обмен и корректная авторизация.
Проверка валидности цепочки сертификатов снаружи: получить сертификат сервера и убедиться, что цепочка успешно верифицируется до корпоративного CA.
Проверка восстановления после перезапуска: перезапустить сервер и подтвердить автоматический старт всех сервисов и успех TLS-подключений.

Каждый тест сопровождайте шагами воспроизведения и логом успешного выполнения.

Чек-листы по ролям

Администратор (перед установкой):

Подготовить рабочую почту для администратора CA.
Убедиться, что DNS-имя сервера зарегистрировано и резолвится.
Подготовить юридическое название организации и данные для CSR.
Выбрать надёжную фразу-пароль и безопасное место для её хранения.

Оператор (во время установки):

Выполнить шаги генерации ключей и CSR.
Отправить CSR и отслеживать номер запроса.
Установить подписанный сертификат после получения.
Сгенерировать локальный сертификат для localhost.
Перезапустить сервисы и выполнить тесты.

Команда реагирования на инциденты:

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

План на случай инцидента и процедура отката

Сценарий: утеря / компрометация фразы-пароля промежуточного CA

Немедленно уведомить команду безопасности.
Пометить текущие сертификаты как ненадёжные (в внутренних документах и CMDB).
Генерировать новый промежуточный CA и новые ключи по процедуре из раздела Шаг 1.
Выдать новые сертификаты всем клиентам и службам.
Перезапустить все связанные сервисы и проверить работоспособность.
Восстановить или отозвать старые сертификаты через корпоративный процесс управления ключами.

Сценарий: потеря приватного ключа

Повторить процесс генерации промежуточного CA и всех подписанных сертификатов. Старые сертификаты считаются недействительными.

Критически важно: каждый случай компрометации требует срочной замены ключей и уведомления заинтересованных сторон.

Модель принятия решений и чек-лист миграции

Модель: Безопасность превыше удобства. Принятие решения о хранении фразы-пароля в файле /etc/WiKID/security требует оценки риска и согласования с политикой безопасности организации.

Чек-лист миграции на новый промежуточный CA:

Создать новый CA и CSR.
Получить подписанный сертификат от корпоративного CA.
Установить новый промежуточный сертификат.
Сгенерировать новые локальные сертификаты и обновить ключи на клиентах.
Перезапустить сервисы и выполнить проверочные тесты.
Деактивировать старые сертификаты.

Матрица рисков и меры смягчения

Риск: Утечка фразы-пароля. Мера: использовать vault, ограничение доступа и ротация.
Риск: Потеря приватного ключа. Мера: резервное копирование в зашифрованном виде и план восстановления.
Риск: Неправильная привязка FQDN. Мера: заранее проверить DNS-запись и использовать тестовое подключение.
Риск: Ошибки при копировании сертификата из почты (кодировка). Мера: проверять кодировку, использовать plain text и проверять подпись цепочки.

Мини-методология внедрения (шаги высокого уровня)

Планирование: собрать данные для CSR, определить владельцев и контакты.
Генерация: сгенерировать ключи и CSR на сервере.
Запрос: отправить CSR в корпоративный CA и получить номер запроса.
Установка: импортировать подписанный сертификат и проверить соответствие с приватным ключом.
Локальные сертификаты: сгенерировать сертификаты для служб, например для «localhost».
Перезапуск и валидация: перезапустить сервисы и выполнить набор тестов.
Документирование: записать номера сертификатов, даты выдачи и владельцев.

Контрольные команды и примеры конфигурации

Перезапуск сервера WiKID:

wikidctl restart

Пример файла автоматического старта фразы-пароля:

# /etc/WiKID/security
WAUTH_PASSPHRASE=ваш_надёжный_пароль

Важно: права доступа к файлу должны быть ограничены:

chown root:root /etc/WiKID/security
chmod 600 /etc/WiKID/security

Тесты приёмки — подробный список

Тест 1: Проверка целостности цепочки сертификатов через openssl:

openssl s_client -connect yourserver.example.com:443 -showcerts

Ожидаемый результат: вывод цепочки сертификатов, отсутствие ошибок проверки.

Тест 2: LDAP bind через TLS:
- Выполните подключение с ldapsearch или аналогичным инструментом.
- Убедитесь, что TLS установлен и аутентификация проходит.
Тест 3: Проверка доступа RADIUS через протокольный модуль:
- Отправьте тестовый аутентификационный запрос и наблюдайте ответы.
Тест 4: Поверка корректности локального сертификата:
- Убедитесь, что процессы, использующие «localhost», используют созданный сертификат.

Сценарии, когда метод может не сработать

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

Глоссарий (одной строкой)

CSR: запрос на подпись сертификата, содержащий публичный ключ и идентификационные данные.
CA: центр сертификации, подписывающий сертификаты и создающий доверие.
PKCS#12: формат контейнера для хранения сертификата и закрытого ключа вместе, обычно с паролем.
FQDN: полное доменное имя хоста в DNS.

Заключение и рекомендации

Следуя этой инструкции, вы получите корректно настроенный промежуточный CA и локальные сертификаты для WiKID. Обязательно документируйте все сгенерированные сертификаты и пароли, реализуйте план ротации секретов и предусмотрите процедуру быстрого отката на случай инцидента.

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

Полезные напоминания:

Никогда не пересылайте приватный ключ по электронной почте.
Всегда используйте plain text при копировании сертификатов.
Тестируйте доступы после каждого важного изменения.

Итог: корректная генерация и установка промежуточного CA и локальных сертификатов обеспечивает безопасную работу WiKID и интеграцию с различными протоколами, даже если они изначально не поддерживают TLS.

Первичная установка и настройка цепочки сертификатов WiKID