We detected you are likely not from a Russian-speaking region. Would you like to switch to the international version of the site?

  Назад к списку статей
Termux

Настройка и эксплуатация собственного PKI в Termux: генерация сертификатов, CRL, OCSP‑сервер и автоматическое обновление

01 июл 2026 в 17:30 Усачёв Денис Евгеньевич

Пошаговое руководство по созданию собственного PKI в Termux: выпуск сертификатов, управление доверенной цепочкой, генерация CRL, развертывание OCSP‑сервера и автоматическое обновление в локальной инфраструктуре.

Собственный PKI (Public Key Infrastructure) позволяет управлять доверенной инфраструктурой: выпускать сертификаты, отзывать их при компрометации ключей, проверять статус сертификатов и обеспечивать контролируемую криптографическую политику. В среде Termux это особенно удобно для тестовых стендов, корпоративных лабораторий и локальной эксплуатации, когда требуется автономность от внешних удостоверяющих центров.

В этой статье мы настроим полный контур: корневой CA (Root), промежуточный CA (Intermediate), выпуск серверных/клиентских сертификатов, CRL (Certificate Revocation List), OCSP‑сервер (Online Certificate Status Protocol) и автоматизацию обновлений. Все действия выполняются в рамках собственной инфраструктуры и ориентированы на локальное использование.

Требования и подготовка Termux

Для корректной работы потребуются: Termux, доступ к пакету OpenSSL (или его эквивалентам), базовые утилиты окружения, а также понимание, что PKI требует дисциплины хранения ключей и журналирования.

Начнем с обновления пакетов и установки OpenSSL и сопутствующих инструментов.

pkg update
pkg upgrade -y
pkg install -y openssl openssl-tool proot tar coreutils

Примечание: состав пакетов в Termux может отличаться в зависимости от версии репозиториев. Если какой-то пакет отсутствует, используйте ближайшие аналоги.

Структура рабочей директории PKI

Рекомендуется заранее зафиксировать структуру каталогов. Это упрощает автоматизацию и снижает риск ошибок при генерации и подписании.

mkdir -p ~/pki/{root,intermediate,certs,crl,ocsp,private,db,csr,config,scripts}
chmod 700 ~/pki/private
chmod 700 ~/pki/root ~/pki/intermediate
cd ~/pki

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

mkdir -p db/root db/intermediate
touch db/root/index.txt db/intermediate/index.txt
: > db/root/serial
: > db/intermediate/serial
echo 1000 > db/root/serial
echo 2000 > db/intermediate/serial

Файл индекса в дальнейшем используется для формирования CRL и ответа OCSP.

Генерация корневого CA (Root CA)

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

1) Генерируем ключ Root CA.

openssl genrsa -aes256 -out private/root.key.pem 4096

2) Создаем конфигурационный файл для Root CA.

cat > config/root.cnf <<'EOF'
[ ca ]
default_ca = CA_default
[ CA_default ]
dir               = ~/pki/root
certs            = $dir/certs
new_certs_dir    = $dir/certs
database         = ~/pki/db/root/index.txt
serial           = ~/pki/db/root/serial
private_key      = ~/pki/private/root.key.pem
certificate      = ~/pki/root/certs/root.cert.pem
default_md       = sha256
policy           = policy_strict
x509_extensions = v3_ca

[ policy_strict ]
countryName             = match
stateOrProvinceName     = optional
localityName            = optional
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[ v3_ca ]
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer
basicConstraints = critical,CA:TRUE
keyUsage = critical, keyCertSign, cRLSign
EOF

3) Создаем директорию сертификатов для Root и выпускаем самоподписанный сертификат.

mkdir -p ~/pki/root/certs
openssl req -config config/root.cnf \
  -key private/root.key.pem \
  -new -x509 -days 3650 -sha256 \
  -extensions v3_ca \
  -subj "/C=RU/ST=Yaroslavl/L=Rybinsk/O=RybinskLAB/OU=PKI/CN=Root-CA" \
  -out root/certs/root.cert.pem
chmod 444 root/certs/root.cert.pem

Генерация Intermediate CA и цепочка доверия

Intermediate CA подписывается Root CA. Его можно хранить в защищенном, но более доступном окружении (например, на сервере в лаборатории).

1) Ключ Intermediate.

openssl genrsa -aes256 -out private/intermediate.key.pem 4096

2) CSR для Intermediate.

cat > config/intermediate.cnf <<'EOF'
[ ca ]
default_ca = CA_default
[ CA_default ]
dir               = ~/pki/intermediate
certs            = $dir/certs
new_certs_dir    = $dir/certs
database         = ~/pki/db/intermediate/index.txt
serial           = ~/pki/db/intermediate/serial
private_key      = ~/pki/private/intermediate.key.pem
certificate      = ~/pki/intermediate/certs/intermediate.cert.pem
default_md       = sha256
policy           = policy_strict
x509_extensions = v3_intermediate_ca

[ policy_strict ]
countryName             = match
stateOrProvinceName     = optional
localityName            = optional
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[ v3_intermediate_ca ]
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer
basicConstraints = critical,CA:TRUE,pathlen:0
keyUsage = critical, keyCertSign, cRLSign
EOF

mkdir -p intermediate/certs
openssl req -config config/intermediate.cnf \
  -new -sha256 \
  -key private/intermediate.key.pem \
  -subj "/C=RU/ST=Yaroslavl/L=Rybinsk/O=RybinskLAB/OU=PKI/CN=Intermediate-CA" \
  -out csr/intermediate.csr.pem

3) Подпись CSR Root CA с промежуточной конфигурацией.

openssl ca -config config/root.cnf \
  -extensions v3_intermediate_ca \
  -days 1825 \
  -notext -batch \
  -in csr/intermediate.csr.pem \
  -out intermediate/certs/intermediate.cert.pem
chmod 444 intermediate/certs/intermediate.cert.pem

4) Проверка цепочки (опционально, но полезно).

openssl verify -CAfile root/certs/root.cert.pem intermediate/certs/intermediate.cert.pem

Выпуск сертификатов: серверные и клиентские

Для выпущенных сертификатов важно корректно задать расширения: keyUsage, extendedKeyUsage, subjectAltName и т.д. Ниже приведен практичный шаблон для серверного сертификата.

Сертификат сервера (example: TLS)

1) Ключ сервера и CSR.

HOSTNAME="server1.local"
mkdir -p certs/server1
openssl genrsa -out private/server1.key.pem 2048
openssl req -new -key private/server1.key.pem \
  -sha256 -subj "/C=RU/ST=Yaroslavl/L=Rybinsk/O=RybinskLAB/OU=TLS/CN=${HOSTNAME}" \
  -out csr/server1.csr.pem

2) Конфигурация расширений для серверного сертификата.

cat > config/server.ext.cnf <<'EOF'
authorityKeyIdentifier=keyid,issuer
subjectKeyIdentifier=hash
basicConstraints = critical,CA:FALSE
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt

[alt]
DNS.1 = server1.local
EOF

3) Подпись сертификата Intermediate CA.

openssl ca -config config/intermediate.cnf \
  -extensions server_ext -days 825 -notext -batch \
  -in csr/server1.csr.pem \
  -out certs/server1/server1.cert.pem

Чтобы выше команда работала, нужно, чтобы конфигурация Intermediate CA ссылалась на нужное имя секции. В OpenSSL это часто требует дополнительных параметров. Поэтому на практике проще сделать единый файл расширений и указывать его явно через -extfile и -extensions.

Используйте такой вариант (рекомендуется):

openssl ca -config config/intermediate.cnf \
  -extfile config/server.ext.cnf -extensions alt \
  -days 825 -notext -batch \
  -in csr/server1.csr.pem \
  -out certs/server1/server1.cert.pem

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

cat intermediate/certs/intermediate.cert.pem root/certs/root.cert.pem > certs/chain.pem
openssl verify -CAfile certs/chain.pem certs/server1/server1.cert.pem

Сертификат клиента (mTLS)

Для клиента ключ и CSR аналогичны, но расширения будут extendedKeyUsage = clientAuth. Пример:

openssl genrsa -out private/client1.key.pem 2048
openssl req -new -key private/client1.key.pem \
  -sha256 -subj "/C=RU/ST=Yaroslavl/L=Rybinsk/O=RybinskLAB/OU=mTLS/CN=client1" \
  -out csr/client1.csr.pem

cat > config/client.ext.cnf <<'EOF'
authorityKeyIdentifier=keyid,issuer
subjectKeyIdentifier=hash
basicConstraints = critical,CA:FALSE
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth
subjectAltName = @alt
[alt]
DNS.1 = client1
EOF

openssl ca -config config/intermediate.cnf \
  -extfile config/client.ext.cnf -days 825 -notext -batch \
  -in csr/client1.csr.pem \
  -out certs/client1/client1.cert.pem

CRL: отзыв сертификатов и выпуск списка

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

1) Подготовим директории для CRL и включим в профиль наличие CRL Distribution Point (CDP) при необходимости. В простом варианте будем публиковать CRL локально.

mkdir -p crl/intermediate
chmod 755 crl/intermediate

2) Отзыв сертификата.

Для отзыва в OpenSSL используется команда openssl ca -revoke. Предварительно нужен сертификат и его запись в index. Обычно запись появляется при выпуске через openssl ca.

# Предположим, что certs/client1/client1.cert.pem уже выпущен через openssl ca
openssl ca -config config/intermediate.cnf \
  -revoke certs/client1/client1.cert.pem \
  -keyfile private/intermediate.key.pem -cert intermediate/certs/intermediate.cert.pem \
  -crl_reason superseded -batch

3) Генерация CRL для Intermediate.

openssl ca -config config/intermediate.cnf \
  -gencrl -out crl/intermediate/intermediate.crl.pem

4) Проверка CRL.

openssl crl -in crl/intermediate/intermediate.crl.pem -text -noout

OCSP: развертывание OCSP‑сервера

OCSP позволяет быстро отвечать о статусе сертификата (good/revoked/unknown) без скачивания полного CRL. Для OCSP сервера нужно выпустить специальный сертификат/ключ (OCSP signing) и настроить базу индексов так, чтобы она соответствовала выпускам, сделанным через openssl ca.

Ниже приведен практичный подход: используем OpenSSL для генерации OCSP signing сертификата и запускаем OCSP responder в локальной среде.

Генерация ключа и сертификата для OCSP signing

openssl genrsa -out private/ocsp.key.pem 2048
openssl req -new -key private/ocsp.key.pem \
  -sha256 -subj "/C=RU/ST=Yaroslavl/L=Rybinsk/O=RybinskLAB/OU=OCSP/CN=ocsp-responder" \
  -out csr/ocsp.csr.pem

cat > config/ocsp.ext.cnf <<'EOF'
authorityKeyIdentifier=keyid,issuer
basicConstraints = critical,CA:FALSE
keyUsage = critical, digitalSignature
extendedKeyUsage = OCSPSigning
subjectKeyIdentifier=hash
EOF

# Подписываем CSR сертификатом Intermediate
openssl ca -config config/intermediate.cnf \
  -extfile config/ocsp.ext.cnf \
  -days 825 -notext -batch \
  -in csr/ocsp.csr.pem \
  -out ocsp/ocsp.cert.pem

chmod 444 ocsp/ocsp.cert.pem

Подготовка ответа OCSP и запуск локального OCSP‑responder

Создадим конфигурацию, укажем местоположение сертификатов CA и базы индекса. Для OpenSSL responder ключевое — index и путь к CA и issuer.

mkdir -p ocsp/resp
touch ocsp/resp/index.txt

Запуск responder (в локальной сети). Важно: OCSP сервер должен быть доступен клиентам, которые будут проверять сертификаты.

# Запускаем OCSP responder на локальном порту
# (В Termux используйте слушание только на необходимом адресе в вашей локальной сети.)
openssl ocsp -index db/intermediate/index.txt \
  -port 2560 \
  -rsigner ocsp/ocsp.cert.pem \
  -rkey private/ocsp.key.pem \
  -CA intermediate/certs/intermediate.cert.pem \
  -issuer intermediate/certs/intermediate.cert.pem \
  -nmin 1 \
  -ndays 7 \
  -text \
  &

Если у вас появляется ошибка связанная с параметрами индекса/сертификатами, перепроверьте: вы выпускали сертификаты через ту же базу db/intermediate/index.txt и используете корректного подписанта.

Проверка OCSP ответа

Проверим статус сертификата через OCSP клиент (команда OpenSSL). Укажем URL виртуально локальный — в данном примере OCSP сервер доступен на устройстве/хосте.

# Вариант запросов зависит от сетевой доступности вашего OCSP сервера в локальной инфраструктуре.
openssl ocsp -issuer intermediate/certs/intermediate.cert.pem \
  -cert certs/client1/client1.cert.pem \
  -url http://127.0.0.1:2560 \
  -CAfile intermediate/certs/intermediate.cert.pem \
  -resp_text

Если client1 был отозван и CRL/индекс обновлен, OCSP должен вернуть статус revoked.

Автоматическое обновление: CRL и OCSP

OCSP responder использует индекс и выдает ответы на основе состояния. Для CRL необходимо регулярно генерировать новый список, а для OCSP — обеспечивать актуальность индекса (что обеспечивается выпуском/отзывом сертификатов через CA).

Сделаем скрипт обновления CRL и (опционально) прогоняем sanity‑проверки.

cat > scripts/update-crl.sh <<'EOF'
#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail
cd ~/pki

echo "[INFO] Generating CRL..."
openssl ca -config config/intermediate.cnf \
  -gencrl -out crl/intermediate/intermediate.crl.pem

echo "[INFO] Validating CRL text..."
openssl crl -in crl/intermediate/intermediate.crl.pem -text -noout >/dev/null

echo "[OK] CRL updated: $(date)"
EOF

chmod +x scripts/update-crl.sh

Запуск обновления вручную:

scripts/update-crl.sh

Для автоматизации по расписанию в Termux обычно используют termux-job-scheduler. Уточните доступность пакета в вашем окружении и настройте расписание под вашу лабораторию.

Пример (если планировщик установлен):

# pkg install -y termux-job-scheduler
# termux-job-scheduler --help
# Пример: ежедневное обновление CRL в 03:30
# (команда может отличаться в зависимости от версии пакета)

Если планировщик недоступен, можно использовать постоянный запуск через cron или системные механизмы, доступные в вашей среде Termux.

Автоматизация выпуска сертификатов и безопасное хранение

Автоматизируйте выпуск CSR, подписание и упаковку файлов сертификатов в один формат (например, PEM-цепочка). При этом не храните пароли ключей в открытом виде и не выводите их в логи.

Практика:

  • Храните приватные ключи в ~/pki/private с правами доступа 700.
  • В Root CA используйте максимально строгую защиту; желательно формировать Root офлайн.
  • Включайте в план работ регулярный аудит индекса, проверку статуса CRL и тестовый OCSP запрос.
  • В документации фиксируйте политики: срок действия, причина отзыва, период публикации CRL.

Локальная сеть и публикация статуса (важное замечание про VPN)

Если вы хотите проверять сертификаты с разных устройств в рамках одной локальной инфраструктуры, используйте сетевую связность в пределах вашей локальной сети. При необходимости можно поднять локальную сеть через VPN, но строго для обеспечения доступа к ресурсам (OCSP/CRL), а не для обхода блокировок. Сертификаты и статусы должны проверяться безопасно и предсказуемо.

Типовые проблемы и диагностика

  • OCSP возвращает unknown: сертификат не находится в index или используется не тот issuer/CA. Проверьте, что запрос идет с корректным issuer и что сертификат выпускался через ту же CA базу.
  • CRL не обновляется: проверьте права на crl/intermediate и корректность команды -gencrl.
  • Ошибки при подписании: сверяйте поля subj с политикой policy_strict и убедитесь, что расширения указаны правильно.

Заключение

Собственный PKI в Termux можно собрать “с нуля” и получить управляемую схему доверия: Root и Intermediate CA, выпуск сертификатов, отзыв через CRL и оперативную проверку статуса через OCSP‑сервер, плюс регулярное обновление CRL и контроль актуальности данных. Такой подход подходит для лабораторных стендов, внутренних сервисов и локальных систем, где важны автономность и прозрачная политика доверия.

Если вам нужна помощь с внедрением, аудитом конфигураций, настройкой инфраструктуры для конкретных сценариев (mTLS, внутренние домены, публикация CRL/OCSP, автоматизация и безопасное хранение ключей), обратитесь в РыбинскЛАБ. Мы поможем спроектировать и развернуть PKI под ваши задачи.

* Текст статьи подготовлен и структурирован с использованием технологий искусственного интеллекта. Проверен и доработан перед публикацией.

Нужна помощь с настройкой Termux, Linux и серверов?

Я оказываю ИТ-услуги: настройка серверов, автоматизация, безопасность, помощь с Linux и инфраструктурой. Материалы сайта — только в ознакомительных и образовательных целях.

Связаться со мной
Поддержать проект