Skip to content

01-getting-started.md

Latest commit

 

History

History
103 lines (74 loc) · 5.5 KB

01-getting-started.md

File metadata and controls

103 lines (74 loc) · 5.5 KB
Raw

01. Первый запуск и инициализация

Порядок действий от распакованного бинарника до готового к работе центра сертификации.

Что произойдёт при первом запуске

При старте приложение задаст в консоли три вопроса:

Вопрос Назначение
login Имя учётной записи для входа в веб-интерфейс
password Пароль. Из него выводится ключ, которым шифруется мастер-ключ базы
salt Соль для PBKDF2

Эти значения нельзя восстановить. Мастер-ключ, которым зашифрованы все приватные ключи в базе, шифруется паролем - резервной копии нет. Потеря пароля означает потерю всех ключей.

Если задать login.authConfig: true в конфигурации, вопросы не задаются и значения берутся из файла - удобно для разработки, но в продовой среде так делать не стоит, см. 02-production-setup.md.

Дальше приложение само:

  1. Создаёт каталоги db, root_ca_tlss, https, crlFile, logs
  2. Генерирует конфигурацию config.yaml рядом с исполняемым файлом
  3. Создаёт таблицы в базе db/database.db
  4. Генерирует мастер-ключ и сохраняет его в зашифрованном виде
  5. Генерирует SSH-ключ Default для подключения к серверам
  6. Поднимает три слушателя: веб-интерфейс, CRL/OCSP и EST

Порты после установки

Слушатель Порт Протокол
Веб-интерфейс и API 43000 по app.protocol
CRL и OCSP 8080 HTTP
EST 43001 всегда TLS

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

Создание центра сертификации

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

Порядок:

  1. Раздел CA → Core CA
  2. Заполните поля Root CA: Common Name, организация, срок действия, длину ключа
  3. Создайте Sub CA - именно им подписываются все конечные сертификаты

Ключи Root и Sub CA хранится в базе в зашифрованном виде и не выгружается. Остальные сертификаты выгрузить можно.

Проверка, что всё поднялось

# Веб-интерфейс
curl -k https://tlss.lv.local:43000/overview

# CRL - появится после создания CA
curl http://tlss.lv.local:8080/api/v1/crl/subca/pem | head -3

# OCSP - ответит только на корректный запрос, см. документацию по проверке
curl -i http://tlss.lv.local:8080/ocsp

В логах при успешном старте будут строки о запуске трёх серверов и о том, что промежуточный CA извлечён:

Starting TLSS UI server with HTTPS
Starting HTTP CRL server
Starting EST mTLS server
ExtractCA: Intermediate CA certificate and key successfully extracted

Что делать дальше

Задача Раздел интерфейса
Выпустить серверный сертификат Servers certs → Add servers certs
Выпустить клиентский сертификат Clients certs → Add clients certs
Настроить автоматическую выдачу устройствам EST → Add EST users
Создать ключ для автоматизации API → API keys
Загрузить сторонний CA CA → External CA

Перед выпуском сертификатов заведите объект, к которому они привязываются: сервер (Servers certs → Add servers) или сущность (Clients certs → Add entities).

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

Всё состояние - это два файла: база db/database.db и config.yaml. Скопируйте их на другую машину вместе с бинарником, и установка продолжит работать. Пароль администратора при этом обязателен - без него база не расшифруется.

Дальше: 02-production-setup.md - что изменить перед вводом в эксплуатацию.