Руководство по установке ST CA

Пререквизиты

Так как работа сервисов СА во многом завязана на TLS-соединения, в инфраструктуре должна быть корректно настроена DNS-адресация.

Машины с установленными сервисами Keycloak, CA Gateway, AIA/CRL обязательно должны иметь корректные именования для прямого и обратного DNS-резолвинга.

Чтобы корректно открывать страницы http, лучше это делать на странице инкогнито, чтобы http не подменялось на https.

1. Подготовка к установке сервисов CA

1.1 Установка PostgreSQL

  • установить PostgreSQL
sudo apt-get install postgresql-client-15 postgresql-15 -y

  • Правка pg_hba.conf и postgresql.conf.

  • В postgresql.conf редактируем listen_addresses на '*'(60 строка) logging_collector(451 строка), log_directory(457 строка), log_connections(554 строка) и standard_conforming_strings = on(777 строка). Номера строк могут отличаться в зависимости от версии.

sudo nano /etc/postgresql/15/main/pg_hba.conf
sudo nano /etc/postgresql/15/main/postgresql.conf
  • Перезапуск службы
sudo systemctl restart postgresql.service

1.2 Подключение к бд

  • Смена пользователя на postgres и подключение к бд
sudo -i -u postgres
psql postgres
  • Изменение пароля на учетной записи postgres
ALTER USER postgres WITH PASSWORD 'techpass';

1.3 Создание баз keycloak и ca_core

  • Создание пользователей keycloak и ca_core 
CREATE ROLE keycloak WITH LOGIN CREATEDB CREATEROLE;
CREATE ROLE ca_core WITH LOGIN CREATEDB CREATEROLE;
ALTER USER keycloak WITH PASSWORD 'techpass';
ALTER USER ca_core WITH PASSWORD 'techpass';
  • Создание баз и назначение прав
CREATE DATABASE keycloak;
CREATE DATABASE ca_core;
GRANT ALL PRIVILEGES ON DATABASE "keycloak" to keycloak;
GRANT ALL PRIVILEGES ON DATABASE "ca_core" to ca_core;

1.4 Тест подключения

  • Подключаемся pgadmin для проверки подключения

  • Назначаем пользователям права на схему public, keycloak и ca_core соответственно(либо через интерфейс pgadmin, либо следующими командами)

  • Для базы keycloak

sudo -i -u postgres
psql -U postgres -h localhost -d keycloak

GRANT ALL ON SCHEMA public TO keycloak;
  • Для базы ca_core
sudo -i -u postgres
psql -U postgres -h localhost -d ca_core

GRANT ALL ON SCHEMA public TO ca_core;

1.5 Подготовка к установке сервисов CA

  • Создание директории для дистрибутивов
sudo mkdir -p /opt/ca-distrib
  • Распаковка архива
sudo tar xvf st-ca.tar -C /opt/ca-distrib/

Дистрибутив состоит из 3 директорий, а именно: binaries, default_configs, scripts. В binaries содержатся дистрибутивы CA, в default_configs содержатся дефолтные конфигурационные файлы, которые будут использоваться далее в скриптах, в scripts содержатся скрипты, которыми будем оперировать далее в инструкции.

  • Установка java (21 версии)
wget https://download.oracle.com/java/21/latest/jdk-21_linux-x64_bin.deb
sudo dpkg -i jdk-21_linux-x64_bin.deb
  • Для rpm( RedOS)
dnf install https://download.oracle.com/java/21/latest/jdk-21_linux-x64_bin.rpm
  • Проверка версии java
java --version
  • Установка curl
sudo apt install -y curl

2. Запуск Discovery-сервиса

2.1 Установка ca-eureka

Первым из состава СА запускается Discovery-сервис, так как он будет агрегировать информацию о запущенных экземплярах.

  • Запуск скрипта установки ca-eureka, скрипт создает пользователя causer(если не создан), копирует из дистрибутивов скрипт обработчик jar, назначает права на директорию сервиса, создает сервис ca-eureka.service, запускает его и ставит на автозапуск
sudo /bin/bash /opt/ca-distrib/scripts/ca-eureka.sh
  • Проверка статуса ca-eureka
sudo systemctl status ca-eureka.service
  • В случае ошибок, просмотр логов
sudo journalctl -u ca-eureka.service -f -o cat -n 500

ca-eureka http://[имя_сервера]:8761

2.2 Настройка ca-eureka

В конфигурации сервиса установлено дефолтное значение расположения файла лицензии /opt/st-ca/ca-license.json, если путь к лицензии потребуется изменить то необходимо изменить конфигурационный файл и перезапустить сервис

sudo nano /opt/st-ca/ca-eureka/application.yml

sudo systemctl restart ca-eureka.service

3. Установка CA Core

3.1 Установка ca-core без TLS

  • Выполнить скрипт. Скрипт запрашивает подтверджение полного имени сервера, затем создает пользователя causer(если не создан), создает конфигурационный файл custom-oids, создает директорию /opt/keycloak/conf/tls, генерирует конфигурационный файл application.yml в директории сервиса, назначает права пользователю causer, создаёт сервис ca-core.service, запускает его и ставит на автозапуск.
sudo /bin/bash /opt/ca-distrib/scripts/ca-core-first.sh
  • Проверка статуса ca-core
sudo systemctl status ca-core.service
  • В случае ошибок, просмотр логов
sudo journalctl -u ca-core.service -f -o cat -n 500
  • swagger http://[имя_сервера]:9000/api/v1/swagger-ui/index.html

3.2 Конвертация p12 в pem и добавление сертификата в доверенные java

  • После запуска ca-core, сгенерируется p12 файл, пароль от него укзан в конфигурации ca-core /opt/st-ca/ca-core/application.yml в строке key-password

  • Конвертируем файл в pem(пароль берём из прошлого пункта)

openssl pkcs12 -in /opt/st-ca/ca-core/root-keystore.p12 -out cacert.pem -nodes

  • удаляем лишнее из файла cacert.pem и оставляем только сам сертификат

  • Добавление корневого сертификата в доверенные, необходимо указать полное имя сервера вместо $FULLNAME. Пример приведён для версии 21.0.4, перед выполнением команды, нужно проверить установленную версию java.

sudo keytool -importcert -alias $FULLNAME.root -keystore /usr/lib/jvm/jdk-21.0.4-oracle-x64/lib/security/cacerts -storepass changeit -file cacert.pem
  • Ввести yes

3.3 Описание флагов конфига ca-core

Флаги CA core используемые для корневого сертификата:

  • key algorithm: RSA, ECDSA, GOST, EDDSA

    • type: RSA - Используемый алгоритм ключа при генерации ключевой пары(выше указаны доступные)

  • signature algorithm: SHA256withRSA,SHA384withRSA, SHA512withRSA, SHA256withECDSA,SHA384withECDSA, SHA512withECDSA, Ed25519, GOST3411_2012_256withGOST3410_2012_256, GOST3411_2012_512withGOST3410_2012_512

    • sign-algorithm: SHA256withRSA - Используемый алгоритм для формирования подписи выпускаемых сертификатов(выше указаны доступные, должны соответствовать алгоритму шифрования ключа)

  • size of key in case of RSA

    • key-size: 4096 - Длина ключа (используется только для RSA)

  • key spec in case of ECDSA prime256v1, secp384r1, secp521r1

    • key-spec: prime256v1 - название кривой(используется только для ECDSA)

storage:

  • PKCS12, PKCS11, JCSP

    • type: PKCS12 - тип используемого хранилища для ключевой пары центра сертификации(выше указаны доступные)

  • HDIMAGE (хранение ключевой пары в файловой системе при выборе JCSP), HSMDB(хранение ключевой пары на CryptoPro HSM при выборе JCSP)

    • jcspContainerType: HDIMAGE
    • config-path: /opt/st-ca/ca-core/pkcs11.cfg - Путь к конфигу pkcs11(пример конфига представлен ниже)

  • if we want to generate key-pair on load

    • generate-on-load: false - генерация ключевой пары при запуске ca-core(доступные значения: true, false)

  • if generate-on-load is switched on

    • dn: CN=SafeTech - DN в генерируемом сертификате

  • if pkcs12 storage-type has been chosen

    • key-store-file: root-keystore.p12 - имя p12 после генерации(находится по пути /opt/st-ca/ca-core/) либо p12 выпущенный ранее

  • private key alias

    • key-alias: pc-ca-30-RSA - alias закрытого ключа

  • private key pass for pkcs12 or pin for PKCS11 or CP-HSM

    • key-password: 12345678 - пароль закрытого ключа или пин-код при выборе PKCS11 или CP-HSM

Пример конфига pkcs11:

# наименование провайдера в JCA
name = eToken
# путь до библиотеки производителя HSM, реализующей PKCS11 протокол
library = C:\pc-ca\rtPKCS11.dll
# вывод отладочной информации при подключении к HSM
showInfo = true
# номер слота, к которому подключен HSM. Если подключен 1, то номер будет - 0.
slot=0

attributes(*,CKO_PRIVATE_KEY,*) = {
  CKA_SIGN = true
  CKA_TOKEN = true
  CKA_DECRYPT = true
}

attributes(*,CKO_CERTIFICATE, *) = {
  CKA_TOKEN = true
}

4. Выпуск сертификатов для веб-сервисов

  • Запуск скрипта изменения дефолтных запросов и файла экспорта keycloak на корректное имя сервера 
sudo /bin/bash /opt/ca-distrib/scripts/gen-edit.sh
  • Генерация запросов: выполните по очереди команды ниже
sudo /bin/bash /opt/ca-distrib/scripts/keycloak-gen.sh
sudo /bin/bash /opt/ca-distrib/scripts/gateway-gen.sh
sudo /bin/bash /opt/ca-distrib/scripts/web-gen.sh
  • После выполнения каждой команды генерации запросов появляется содержимое запроса, его нужно вставить при выполнении скрипта выпуска сертификата (2 раза - основной и подтверждение)
sudo /bin/bash /opt/ca-distrib/scripts/issue-cert.sh

  • Если выпуск сертификата завершен успешно, на экране появится содержимое выпущенного сертификата. Копируем содержимое и создаем в /home/$USER/ файлы с именами keycloak-cert.pem, gateway-cert.pem, web-cert.pem и содержимым сертификатов соответственно

  • Подготовка gateway.p12 (задаем пароль techpass)

sudo openssl pkcs12 -export -out gateway.p12 -inkey gateway-privkey.pem -in gateway-cert.pem -certfile cacert.pem -name "st-ca-gateway"
  • Добавление корневого сертификата в цепочку. Добавляем содержимое cacert.pem в конец keycloak-cert.pem и web-cert.pem (в любом текстовом редакторе):

screenshot

  • Копируем p12-контейнер для ca-gateway в нужную директорию
sudo mkdir -p /opt/st-ca/ca-gateway/key
sudo cp gateway.p12 /opt/st-ca/ca-gateway/key/gateway.p12
  • Копируем файлы сертификатов и ключа для keycloak в нужную директорию
sudo mkdir -p /opt/keycloak/conf/tls
sudo cp keycloak-cert.pem /opt/keycloak/conf/tls/keycloak-cert.pem
sudo cp keycloak-privkey.pem /opt/keycloak/conf/tls/keycloak-privkey.pem
sudo cp cacert.pem /opt/keycloak/conf/tls/cacert.pem

5. Установка Keycloak

5.1 Скачивание и распаковка

  • Загрузить дистрибутив TAR.GZ по ссылке https://www.keycloak.org/downloads
sudo wget https://github.com/keycloak/keycloak/releases/download/24.0.3/keycloak-24.0.3.tar.gz
  • Распаковка
sudo tar -xvf keycloak-24.0.3.tar.gz
sudo cp -R keycloak-24.0.3/. /opt/keycloak/
  • Создание пользователя keycloak и назначение прав на директорию
sudo groupadd keycloak
sudo useradd -g keycloak -r keycloak
sudo chown -R keycloak:keycloak /opt/keycloak
  • Создание сервиса keycloak
sudo nano /etc/systemd/system/keycloak.service
  • Сервис
[Unit]
Description=Keycloak Server
After=network.target postgresql.service

[Service]
User=keycloak
Group=keycloak
SuccessExitStatus=0 143
ExecStart=/opt/keycloak/bin/kc.sh start --optimized

[Install]
WantedBy=multi-user.target
  • В файле keycloak.conf раскомментируем бд, пользователя, пароль(Созданный в pgsql), url и заполняем hostname, указываем пути к pem файлам.
sudo nano /opt/keycloak/conf/keycloak.conf

https-certificate-file=/opt/keycloak/conf/tls/keycloak-cert.pem
https-certificate-key-file=/opt/keycloak/conf/tls/keycloak-privkey.pem
  • Запуск build для keycloak
sudo -u keycloak /opt/keycloak/bin/kc.sh build --db=postgres

5.2 Импорт конфигурации и запуск сервиса

  • Импорт конфигурации keycloak
sudo /bin/bash /opt/keycloak/bin/kc.sh import --file /opt/ca-distrib/default_configs/realm-export.json
  • Запуск keycloak в режиме консоли для первичной инициализации admin-а
sudo KEYCLOAK_ADMIN=admin KEYCLOAK_ADMIN_PASSWORD=admin /opt/keycloak/bin/kc.sh start --optimized
  • Запуск сервиса и установка автозапуска
sudo systemctl enable keycloak.service
sudo systemctl start keycloak.service
  • Проверка статуса keycloak
sudo systemctl status keycloak.service
  • В случае ошибок, просмотр логов
sudo journalctl -u keycloak.service -f -o cat -n 500

Примечание: если был выполнен импорт конфигурации KeyCloak из файла realm-export.json, то необходимо дополнительно выполнить следующие проверки: - проверить Valid redirect URIs для клиентов ca-gateway и ca-ui - поменять адрес сервера на свой, если указан невалидный; - для клиента ca-gateway проверить наличие "коротких" адресов возврата: например, http://ca.demo.local:9000/* и "короткий" http://ca:9000/* - данная настройка необходима для корректной работы сервисов CEP и CES для MS Enrollment

5.3 Настройка пользователей и ролей

  • открываем страницу Администрирования https://[имя_сервера]:8443/, логин и пароль admin

  • Переходим в импортированный realm для CA (например, st-ca)

  • создаём ПОЛЬЗОВАТЕЛЯ в Keycloak (пользователь, работающий без домена)

    • ca-standalone-admin, обязательно поставить First Name, Last Name, email (любые)
    • задать пароль techpass, убрать Temporary
    • установить роль CaAdministrator

  • переходим в КЛИЕНТА ca-gateway в Keycloak, вкладка Credentials и перевыпускаем Client Secret. Сохраняем его, далее в скриптах будет запрошен (пример 7cIlQnj2NDcorxV7gzsD7Az9Q0OnZ0IK)

  • Во вкладке Service accounts roles добавляем роль CaAdministrator и роль realm-management view-clients. В фильтрах выбираем Filter by client и на последней странице будет нужная роль

6. Обновление конфигурации CA Core

После настройки Keycloak мы можем настроить CA Core для работы с функциями разграничения доступа

  • Для этого запускаем скрипт, который запросит keycloak secret от ca-gateway, уточнит полное имя сервера, затем удалит старый конфигурационный файл сервиса и сформирует новый, назначит права и перезапустит сервис
sudo /bin/bash /opt/ca-distrib/scripts/ca-core.sh
  • Проверка статуса ca-core
sudo systemctl status ca-core.service
  • В случае ошибок, просмотр логов
sudo journalctl -u ca-core.service -f -o cat -n 500

7. Установка CA Gateway

Скрипт установки запрашивает дополнительную информацию в виде полного имени, client secret от ca-gateway в keycloak, так же создаёт пользователя causer(если не создан), формирует конфигурационные файлы и службы, запускает их и ставит на автозапуск.

  • Установка ca-gateway
sudo /bin/bash /opt/ca-distrib/scripts/ca-gateway.sh
  • Проверка статуса сервиса
sudo systemctl status ca-gateway.service
  • В случае ошибок, просмотр логов
sudo journalctl -u ca-gateway.service -f -o cat -n 500

8. Установка веб-сервера, AIA, CDP, Web UI

В качестве веб-сервера может использоваться любой веб-сервер (например, Apache2 или nginx).

Ниже приведена инструкция для Apache2 и HTTPD, которая может быть адаптирована для другого веб-сервера.

8.1 Установка веб-сервера

8.1.1 Установка apache2

sudo apt install apache2 -y

8.1.2 Установка httpd(например для RedOS)

sudo dnf install httpd -y

8.2 Конфигурация веб-сервера

8.2.1 Настройка apache2

  • Создаем директорию для сертификатов
sudo mkdir /etc/apache2/ssl
  • Копируем в неё сертификат и закрытый ключ web
sudo cp web-privkey.pem /etc/apache2/ssl/
sudo cp web-cert.pem /etc/apache2/ssl/
  • Запуск скрипта, который запрашивает имя сервера, производит замену в дефолтном конфигурационном файле и перемещает содаржимое папки html в рабочую директорию /var/www/html
sudo /bin/bash /opt/ca-distrib/scripts/web.sh
  • Изменение конфигурационного файла apache2. нужно заменить в конфиге SSLCertificateFile путь /etc/ssl/certs/ssl-cert-snakeoil.pem на /etc/apache2/ssl/web-cert.pem, так же, путь SSLCertificateKeyFile /etc/ssl/certs/ssl-cert-snakeoil.key на /etc/apache2/ssl/web-privkey.pem
sudo nano /etc/apache2/sites-available/default-ssl.conf
  • Включаем TLS в Apache2

Включаем модуль TLS и конфигурацию

sudo a2enmod ssl
sudo a2ensite default-ssl.conf
sudo systemctl restart apache2

На машине, на который будет производиться подключение к вэбу CA, необходимо установить сертификаты в доверенные, это можно сделать и при первом подключении к вэбу https://[имя_сервера]

В Linux Astra потребуется изменить конфигурационный файл apache2.conf и добавить в нём строку AstraMode off

sudo nano /etc/apache2/apache2.conf

8.2.2 Настройка httpd

  • Создаем директорию для сертификатов
sudo mkdir /etc/httpd/ssl
  • Копируем в неё сертификат и закрытый ключ web
sudo cp web-privkey.pem /etc/httpd/ssl/
sudo cp web-cert.pem /etc/httpd/ssl/
  • Запуск скрипта, который запрашивает имя сервера, производит замену в дефолтном конфигурационном файле и перемещает содаржимое папки html в рабочую директорию /var/www/html
sudo /bin/bash /opt/ca-distrib/scripts/web.sh

Устанавливаем TLS в httpd

sudo dnf install mod_ssl -y

В файле httpd.conf изменяем следующие строки

sudo nano /etc/httpd/conf/httpd.conf

ServerName name_of_this_server.ru  #Раскомментировать строку и указать имя сервера
LoadModule ssl_module modules/mod_ssl.so #Добавить эту строку в конец конфигурационного файла

В файле ssl.conf указать пути до сертификата и ключа

sudo nano /etc/httpd/conf.d/ssl.conf

SSLCertificateFile /etc/httpd/ssl/web-cert.pem   # укажите путь до сертификата (открытая часть)
SSLCertificateKeyFile /etc/httpd/ssl/web-privkey.pem    # укажите путь до сертификата (закрытая часть)

Проверка настройки httpd

apachectl configtest

Перезапуск сервиса

sudo systemctl restart httpd.service

8.3 CRL/AIA

CRL и AIA настраиваются в конфиге сервиса ca-gateway, по умолчанию указаны следующие настройки

  endpoints:
    update-interval: 600 #seconds
    use-system-hostname: true # use system hostname to build crl-dp and aia urls

  crl-dp:
    crl-file-name: st-ca.crl

    # how often to get last-published-crl from Ca-Core
    crl-update-interval: 600 #seconds

    # schedule to re-publish CRL with Ca-Core (cron-format)
    crl-republish-schedule: "0 0 */12 * * *"  # two times per day

  aia:
    cert-file-name: st-ca.crt

    # how often to renew Issuer's cert from Ca-Core
    cert-update-interval: 600 #seconds

Eсли их необходимо изменить, то нужно отредактировать конфигурационный файл и перезапустить сервис ca-gateway

sudo nano /opt/st-ca/ca-gateway/application.yml

sudo systemctl restart ca-gateway.service

CRL и AIA доступны по адресам

http://[имя_сервера]:8080/crl-dp/crl
http://[имя_сервера]:8080/aia/cert

Чтобы ссылки были доступны, необходимо в keycloak у клиента ca-gateway в разделе "Service accounts roles" добавить роль "CaAdministrator"

9. Установка и настройка MS WSTEP (CEP / CES)

9.1 Установка CA CEP, CA CES

  • Установка ca-cep
sudo /bin/bash /opt/ca-distrib/scripts/ca-cep.sh
  • Установка ca-ces
sudo /bin/bash /opt/ca-distrib/scripts/ca-ces.sh
  • Проверка статуса сервисов
sudo systemctl status ca-cep.service
sudo systemctl status ca-ces.service
  • В случае ошибок, просмотр логов
sudo journalctl -u ca-cep.service -f -o cat -n 500
sudo journalctl -u ca-ces.service -f -o cat -n 500

9.2 Настройка интеграции Keycloak с доменом

Если на сервере не настроен корректный DNS резолвинг, то необходимо на сервер с сервисами в файл hosts прописать адрес контроллера домена.

9.2.1 Подготовка сервисной учетной записи в домене

  • создаём в AD пользователя, из-под которого будет работать ca-gateway, например ca-gateway
  • регистрируем Service Principal Name (SPN) для этого пользователя в PowerShell от имени Администратора
setspn -A HTTP/[CA-Gateway-DNS-Address] [user-name]

Например,

setspn -A HTTP/o-ca-stand.loc ca-gateway
  • Формируем для этого пользователя keytab
ktpass -out [user-name].keytab -princ HTTP/[CA-Gateway-DNS-Address]@[FULL-DOMAIN-NAME] -mapUser [user-name]@[FULL-DOMAIN-NAME] -pass [user-pass] -kvno 0 -ptype KRB5_NT_PRINCIPAL -crypto AES256-SHA1

Например(домен третьего уровня),

ktpass -out ca-gateway.keytab -princ HTTP/o-ca-stand.loc@DOMAIN.O-CA-STAND.LOC -mapUser ca-gateway@DOMAIN.O-CA-STAND.LOC -pass techpass -kvno 0 -ptype KRB5_NT_PRINCIPAL -crypto AES256-SHA1

Например(домен второго уровня),

ktpass -out ca-gateway.keytab -princ HTTP/o-ca-stand.loc@DOMAIN.LOC -mapUser ca-gateway@DOMAIN.LOC -pass techpass -kvno 0 -ptype KRB5_NT_PRINCIPAL -crypto AES256-SHA1

Сохраняем полученный файл с keytab - в нашем примере ca-gateway.keytab

  • включаем для пользователя поддержку нормальных схем шифрования ключей
    AD Users & Computers -> [username] -> Properties -> Account -> галочка This account supports Kerberos AES 256 bit encryption

9.2.2 Базовая интеграция для синхронизации пользователей

В панели администрирования Keycloak выполняем следующие действия:

  • в нашем realm переходим в User Federation
  • Add New Provider, Vendor - Active Directory
  • Connection URL - ldap://[domain-controller-dns-name] (например, ldap://o-ca-stand-dc.loc)
  • нажимаем Test Connection, проверяем результат
  • Bind Type - simple
  • Bind DN - DN пользователя с Административными правами (например, CN=Administrator,CN=Users,DC=domain,DC=o-ca-stand,DC=loc)
  • Bind credentials - пароль пользователя
  • нажимаем Test authentication, проверяем результат
  • Edit mode - READ_ONLY для односторонней синхронизации
  • Users DN - в какой группе искать пользователей для синхронизации (например, CN=Users,DC=domain,DC=o-ca-stand,DC=loc)
  • Username LDAP attribute - по какому полю маппить имя пользователя (например, sAMAccountName)
  • RDN LDAP attribute - ставим cn
  • UUID LDAP attribute - проверяем что стоит objectGUID
  • остальное оставляем как есть
  • Synchronization settings настраиваем для своих нужд
  • Allow Kerberos auth - включаем
  • Kerberos realm - [FULL-DOMAIN-NAME] (например, DOMAIN.O-CA-STAND.LOC)
  • Server principal - полное имя SPN, зарегистрированного на шаге 9.1.1 (например, HTTP/o-ca-stand.loc@DOMAIN.O-CA-STAND.LOC)
  • закидываем keytab-файл на сервер Keycloak

  • Key tab - расположение файла keytab в локальной файловой системе (закидываем туда keytab-файл и указываем путь), например /opt/keycloak/conf/keytab/ca-gateway.keytab

  • Остальное оставляем как есть

  • Галочка Debug - при возникновении сложностей, ход взаимодействия по Kerberos будет выводиться в лог

  • После сохранения, снова переходим в реалм и очищаем поле Kerberos principal attribute, оно автоматически заполнится после первого сохранения

9.3 Контроль работы интеграции с AD

  • в браузере открываем URL CEP, например https://o-ca-stand.loc:9001/ca-cep/ (это адрес ca-gateway с указанием сервиса ca-cep)
  • нас должно перебросить на страницу входа в KeyCloak
  • вводим имя пользователя и пароль Администратора домена (или любого другого пользователя)
  • аутентификация должна пройти успешно, мы должны оказаться на странице CEP с ошибкой

9.4 Маппинг ролей

В CA есть три роли - CaAdministrator, CaOperator, CaAuditor. Роль проверяется при выполнении тех или иных действий.
Чтобы пользователь мог, например, прочитать список шаблонов, у него должна быть одна из этих ролей.

Для этого необходимо настроить маппинг ролей из AD в роли CA.

Самый простой способ это сделать - создать Security Groups в AD и добавить туда пользователей.
Для этого

  • открываем Users and Computers на контроллере домена
  • создаём новый OU, например, CaRoles
  • создаём в нём 3 новые группы - CaAdministrator, CaOperator, CaUser
  • добавляем нужных пользователей в нужные группы (например Administrator в CaAdministrator)
  • идём в Keycloak
  • User federation -> наш домен -> Mappers -> Add mapper
  • Mapper type: role-ldap-mapper
  • LDAP Roles DN: полный DN OU с ролями (например, OU=CaRoles,DC=domain,DC=o-ca-stand,DC=loc)
  • Mode: можно выбрать READ_ONLY
  • Client ID: идентификатор клиента, созданного в Keycloak при импорте конфигурации (например, ca-gateway)
  • Сохраняем
  • Users -> ищем всех (*) -> выбираем administrator (доменный) -> Roles mapping -> убеждаемся, что появился CaAdministrator

9.5 Настройка политики выпуска сертификатов для пользователя

  • в учетной записи пользователя домена (например, Администратора), открываем консоль управления сертификатами certmgr.msc
  • в вкладке Personal -> Certificates тыкаем правой кнопкой мыши -> Additional Actions -> Manage Policies
  • добавляем адрес CEP - https://[имя_сервера]/ca-cep/services/policy/GetPolicies например, https://o-ca-stand.loc:9001/ca-cep/services/policy/GetPolicies
  • нажимаем Validate - ошибок быть не должно
  • следующим шагом выпускаем сертификат по только что добавленной политике

Замечания

  1. Чтобы выпускать сертификаты через CEP/CES для пользователей значение msGeneralFlags в шаблоне должно быть 0 или (согласно доке MS) - 0x00000080. Но второй вариант в Win Server 2022 не срабатывает
  2. Для пользователя наиболее приемлемый keyUsage - 496 (Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment)
  3. При возникновении ошибок при добавлении политики можно анализировать логи:
    • Events Viewer -> Application and Services Logs -> Microsoft -> Windows -> CAPI2 | WebServices (Журнал WebServices в последних версиях windows server отсутствует)
    • journalctl -u keycloak.service -f -o cat -n 500
    • journalctl -u ca-eureka.service -u ca-core.service -u ca-gateway.service -u ca-ces.service -u ca-cep.service -f -o cat -n 500
  4. Статья для понимания принципов работы с MS CEP/CES в рамках AD

10. Установка CA SCEP

10.1 Настройка Keycloak

  • Создаем клиент ca-scep
    • Заполняем client id и имя
    • В Valid redirect URLs указываем адрес сервера по http с портом 9004 (http://[имя_сервера]:9004/*)
    • Указываем client autentification, authorization, в authentification flow ставим галочки на Standart flow и Direct access grants
    • Во вкладке Credentials генерируем Client Secret, который нужно будет указать при установке
    • Во вкладке Service accounts roles добавляем роль CaAdministrator

10.2 Установка ca scep

  • Установка ca-scep Скрипт установки запрашивает дополнительную информацию в виде полного имени, client secret от ca-scep в keycloak, пароль контейнера сертификата взаимодействия, так же создаёт пользователя causer(если не создан), формирует конфигурационные файлы и службы, запускает их и ставит на автозапуск.
sudo /bin/bash /opt/ca-distrib/scripts/ca-scep.sh
  • Проверка статуса сервиса
sudo systemctl status ca-scep.service
  • В случае ошибок, просмотр логов
sudo journalctl -u ca-scep.service -f -o cat -n 500

11. Установка CA OCSP

11.1 Настройка Keycloak

  • Создаем клиент ca-ocsp
    • Заполняем client id и имя
    • В Valid redirect URLs указываем адрес сервера по http с портом 9005 (http://[имя_сервера]:9005/*)
    • Указываем client autentification, authorization, в authentification flow ставим галочки на Standart flow и Direct access grants
    • Во вкладке Credentials генерируем Client Secret, который нужно будет указать при установке
    • Во вкладке Service accounts roles добавляем роль CaAuditor

11.2 Подготовка p12

  • Запрашиваем aia по адресу http://[имя_сервера]:8080/aia/cert . Либо используем cacert из пункта 3.2(если корневой не менялся), тогда при генерации p12 вместо st-ca.pem используем cacert.pem
  • Сохраняем его, далее преобразуем в pem
openssl x509 -in st-ca.crt -out st-ca.pem -outform PEM
  • Далее содаём запрос на сертификат для ocsp
sudo /bin/bash /opt/ca-distrib/scripts/ocsp-gen.sh
  • Выпускаем сертификат либо через вэб интерфейс CA, либо через скрипт выпуска(из пункта 4.2, однако он не будет работать, если включена аутентификация keycloak, то есть пройдена инструкция до пункта 6 включительно)
  • Сертификат сохраняем в файл ocsp-cert.pem
  • Генерируем p12, пароль задаём стандартный techpass:
openssl pkcs12 -export -out ocsp.p12 -inkey ocsp-privkey.pem -in ocsp-cert.pem -certfile st-ca.pem -name "OCSP"
  • Создаем директорию для p12 и кладём его туда, затем добавляем права
sudo mkdir -p /opt/st-ca/ca-ocsp/key
sudo cp ocsp.p12 /opt/st-ca/ca-ocsp/key/
sudo chown -R causer:causer /opt/st-ca/ca-ocsp/

11.3 Установка ca ocsp

  • Установка ca-ocsp Скрипт установки запрашивает дополнительную информацию в виде полного имени, client secret от ca-ocsp в keycloak, пароль контейнера сертификата взаимодействия, так же создаёт пользователя causer(если не создан), формирует конфигурационные файлы и службы, запускает их и ставит на автозапуск.
sudo /bin/bash /opt/ca-distrib/scripts/ca-ocsp.sh
  • Проверка статуса сервиса
sudo systemctl status ca-ocsp.service
  • В случае ошибок, просмотр логов
sudo journalctl -u ca-ocsp.service -f -o cat -n 500

12. Установка Notification Sender

12.1 Установка Notification Sender

  • Установка notification-sender Скрипт установки создаёт пользователя causer(если не создан), формирует конфигурационные файлы и службы, запускает их и ставит на автозапуск.
sudo /bin/bash /opt/ca-distrib/scripts/notification-sender.sh
  • Проверка статуса сервиса
sudo systemctl status ca-scep.service
  • В случае ошибок, просмотр логов
sudo journalctl -u ca-scep.service -f -o cat -n 500

12.2 Настройка Notification Sender

Настройка сервиса происходит в конфигурационном файле по пути /opt/st-ca/notification-sender/application.yml

Конфигурационный файл выглядит следующим образом:

spring:
  application:
    name: notification-sender

  banner:
    location: classpath:/banner.txt

  mail:
    host: mail_server
    port: 587
    username: user@user.ru
    sender: user@user.ru
    password: pass
    properties:
      mail:
        smtp:
          auth: true
          starttls:
            enable: true

server:
  port: 8081


logging:
  level:
    root: info
  • Где в host необходимо прописать адрес почтового сервера
  • В mail.port - порт соединения
  • В username и sender указать отправителя
  • В password - пароль учетной записи
  • в server.port - порт на котором будет поднят сервис

12.3 Рассылки

Рассылки разделены на 2 категории, первая состоит из: - Уведомление при выпуске сертификата по шаблону - Уведомление при отзыве сертификата по шаблону - Уведомление при истечении сертификата по шаблону - Предварительно уведомление при скором истечении сертификата по шаблону

Настройка данных рассылок находится в UI в разделе "Настройки" -> "Email рассылки" и здесь можно указать кому отправлять сообщение(на определенный адрес или по почте из сертификата)

Вторая категория рассылок это: - Уведомление об истечении выпускающего сертификата за определенный промежуток времени - Уведомление об истечении лицензии за определенный промежуток времени

Данная настройка находится в конфигурационном файле /opt/st-ca/ca-core/application.yml

email-service:
  cron:
    expression: "0 13 15 * * *" # everyday at 15:13
  notification-period:
    root-cert: 30, 15, 10, 5, 1
    license: 30, 15, 1
  email:
    subject:
      root-cert: 'Скоро истечет корневой сертификат'
      license: 'Скоро истечет лицензия'
    text:
      root-cert: 'Уважаемый администратор, в ближайшее время заканчивается срок действия корневого подписывающего сертификата.'
      license: 'Уважаемый администратор, в ближайшее время заканчивается срок действия лицензии.'
  • expression это cron выражение, которое определяет периодичность проверки и отправки уведомлений
  • notification-period содержит количество дней, за которое будет срабатывать триггер
  • subject - заголовок письма
  • text - текст письма При срабатывании этих условий, сообщение будет отправлено на почты указанные в профилях keycloak с ролью CaAdministrator

Маппинг атрибутов из Active Directory в Keycloak

  • В созданном User federation переходим во вкладку "Mappers"

  • Делаем "Add mapper" для необходимых атрибутов (cn, dn, dns, email, guid, spn, upn)

  • При создании каждого маппера, необходимо указать название(можно просто указать атрибут) и выбрать "Mapper type" "user-attribute-ldap-mapper".

  • Далее в "User Model Attribute" указываем "guid", а в "LDAP Attribute" название атрибута из AD "objectGUID", проставляем галочку на "Always Read Value From LDAP"

screenshot

Так необходимо сделать для каждого атрибута:

  • cn:

    • "User Model Attribute" - "cn"
    • "LDAP Attribute" - "cn"

  • dn:

    • "User Model Attribute" - "dn"
    • "LDAP Attribute" - "distinguishedName"

  • dns:

    • "User Model Attribute" - "dns"
    • "LDAP Attribute" - "dNSHostName"

  • email:

    • "User Model Attribute" - "email"(необходимо выбрать из предложенных значений)
    • "LDAP Attribute" - "mail"

  • spn:

    • "User Model Attribute" - "spn"
    • "LDAP Attribute" - "servicePrincipalName"

  • upn:

    • "User Model Attribute" - "upn"
    • "LDAP Attribute" - "userPrincipalName"

  • Далее нужно перейти в "Clients", выбрать "ca-gateway" и перейти во вкладку "Client scopes", там выбрать "ca-gateway-dedicated"

screenshot

  • Нажимаем "Add mapper" и выбираем "By configuration", в предлагаемом списке нас интересует "User Attribute"

screenshot

  • Теперь заполняем карточку. В "Name" указываем "msad_guid", в "User Attribute" "guid", в "Token Claim Name" "msad_guid"

screenshot

Для остальных атрибутов:

  • cn:

    • "Name" - "msad_cn"
    • "User Attribute" - "cn"
    • "Token Claim Name" - "msad_cn"

  • dn:

    • "Name" - "msad_dn"
    • "User Attribute" - "dn"
    • "Token Claim Name" - "msad_dn"

  • dns:

    • "Name" - "msad_dns"
    • "User Attribute" - "dns"
    • "Token Claim Name" - "msad_dns"

  • email:

    • "Name" - "msad_email"
    • "User Attribute" - "email"(необходимо выбрать из предложенных значений)
    • "Token Claim Name" - "msad_mail"

  • spn:

    • "Name" - "msad_spn"
    • "User Attribute" - "spn"
    • "Token Claim Name" - "msad_spn"

  • upn:

    • "Name" - "msad_upn"
    • "User Attribute" - "upn"
    • "Token Claim Name" - "msad_upn"

  • После синхронизации, все данные в карточках заполнятся.

Создание user federation для компьютеров

Рассмотрим пример добавления компьютеров в домене

Создание дополнительного user federation

В панели администрирования Keycloak выполняем следующие действия:

  • в нашем realm переходим в User Federation
  • Add New Provider, Vendor - Active Directory Computers
  • Connection URL - ldap://[domain-controller-dns-name] (например, ldap://o-ca-stand-dc.loc)
  • нажимаем Test Connection, проверяем результат
  • Bind Type - simple
  • Bind DN - DN пользователя с Административными правами (например, CN=Administrator,CN=Users,DC=domain,DC=o-ca-stand,DC=loc)
  • Bind credentials - пароль пользователя
  • нажимаем Test authentication, проверяем результат
  • Edit mode - UNSYNCED для разовой синхронизации
  • Users DN - в какой группе искать компьютеры для синхронизации (например, CN=Computers,DC=domain,DC=o-ca-stand,DC=loc)
  • Username LDAP attribute - по какому полю маппить имя пользователя (например, sAMAccountName)
  • RDN LDAP attribute - ставим cn
  • UUID LDAP attribute - проверяем что стоит objectGUID
  • User object classes - указываем person
  • Cache policy - выставляем NO_CACHE
  • остальное оставляем как есть
  • Synchronization settings настраиваем для своих нужд
  • например вот так: screenshot
  • Allow Kerberos auth - включаем
  • Kerberos realm - [FULL-DOMAIN-NAME] (например, DOMAIN.O-CA-STAND.LOC)
  • Server principal - полное имя SPN, зарегистрированного на шаге 9.1.1 (например, HTTP/o-ca-stand.loc@DOMAIN.O-CA-STAND.LOC)
  • закидываем keytab-файл на сервер Keycloak
  • Key tab - расположение файла keytab в локальной файловой системе (закидываем туда keytab-файл и указываем путь), например /opt/keycloak/conf/keytab/ca-gateway.keytab
  • Остальное оставляем как есть
  • Галочка Debug - при возникновении сложностей, ход взаимодействия по Kerberos будет выводиться в лог
  • После сохранения, снова переходим в реалм и очищаем поле Kerberos principal attribute, оно автоматически заполнится после первого сохранения

Маппинг атрибутов с AD

  • После добавления user federation, добавляем в него мапперы, такие как cn, dn, dns, email, guid, roles_mapper(пункт 9.4), sam, upn(пример добавления есть в инструкции в главе "Маппинг атрибутов из Active Directory в Keycloak")
  • В клиент ca-gateway маппить sam не нужно, он будет использоваться только для получения керберос токена screenshot

Обновление модулей / Установка патчей

В данном разделе приведен алгоритм действий для обновления модулей ST CA . Он применим в ситуациях, когда необходимо установить патч на какой-то из модулей или обновить только часть комплекса ST CA, без необходимости полной переустановки

Обновление модуля

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

sudo rm /opt/st-ca/ca-eureka/ca-eureka-1.0.0.jar
sudo cp /opt/ca-distrib/binaries/ca-eureka-2.0.0.jar /opt/st-ca/ca-eureka/
  • после замены файла, необходимо свериться с дефолтным конфигом обновленной версии и если чего то не хватает, добавить в конфигурационный файл application.yml. Файлы дефолтных конфигураций сервисов находятся по пути /opt/ca-distrib/default_configs/

Обновление скриптами:

Обновление модуля состоит из следующих типовых действий: - сохранение старого jar-файла и конфигурационного файла в директорию /opt/temp-ca/* - замена исполняемого jar-файла на обновленный из поставки дистрибутива (исполняемый файл ca-gateway располагается в директории /opt/st-ca/ca-gateway, для остальных сервисов - аналогично); - обновление содержимого конфигурационного файла application.yml (в поставке дистрибутива содержатся актуальные примеры рабочих конфигурационных файлов); - перезапуск сервиса/демона

Перед обновлением, удалите содержимое /opt/ca-distrib/*

sudo rm -rf /opt/ca-distrib/*

Затем распакуйте архив с новыми дистрибутивами в директорию ca-distrib

sudo tar xvf st-ca.tar -C /opt/ca-distrib/

После этих действий можно приступать к обновлению

Обновление ca-eureka

Для обновление ca-eureka необходимо выполнить команду

sudo /bin/bash /opt/ca-distrib/scripts/ca-eureka.sh

Обновление ca-core

Для обновление ca-core необходимо выполнить команду

sudo /bin/bash /opt/ca-distrib/scripts/ca-core.sh

Обновление ca-gateway

Для обновление ca-gateway необходимо выполнить команду

sudo /bin/bash /opt/ca-distrib/scripts/ca-gateway.sh

Обновление ca-cep

Для обновление ca-cep необходимо выполнить команду

sudo /bin/bash /opt/ca-distrib/scripts/ca-cep.sh

Обновление ca-ces

Для обновление ca-ces необходимо выполнить команду

sudo /bin/bash /opt/ca-distrib/scripts/ca-ces.sh

Обновление ca-scep

Для обновление ca-scep необходимо выполнить команду

sudo /bin/bash /opt/ca-distrib/scripts/ca-scep.sh

Обновление ca-ocsp

Для обновление ca-ocsp необходимо выполнить команду

sudo /bin/bash /opt/ca-distrib/scripts/ca-ocsp.sh

Обновление notification-sender

Для обновление notification-sender необходимо выполнить команду

sudo /bin/bash /opt/ca-distrib/scripts/notification-sender.sh

Проверка работы сервисов

sudo systemctl status ca-eureka.service
sudo systemctl status ca-core.service
sudo systemctl status ca-gateway.service
sudo systemctl status ca-cep.service
sudo systemctl status ca-ces.service
sudo systemctl status ca-scep.service
sudo systemctl status ca-ocsp.service
sudo systemctl status notification-sender.service

Проверьте журнал логов после перезапуска сервиса, убедитесь, что сервис запущен без ошибок: journalctl -u ca-gateway.service -f -o cat -n 500

Обновление веб-части

Обновление веб-части выполняется путем замены содержимого /var/www/html. Перезапустите веб-сервер после обновления: sudo systemctl restart apache2

sudo /bin/bash /opt/ca-distrib/scripts/web.sh
sudo systemctl restart apache2.service

Обновление лицензии

Обновление лицензии выполняется путем замены файла лицензии в рабочем каталоге CA (по умолчанию - /opt/st-ca/ca-license.json). После обновления файла лицензии перезапустите сервисы в следующем порядке:

  • sudo systemctl restart ca-eureka.service

  • sudo systemctl restart ca-core.service

  • sudo systemctl restart ca-gateway.service

  • sudo systemctl restart ca-cep.service

  • sudo systemctl restart ca-ces.service

  • ...