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: генерация, управление и автоматическое обновление сертификатов

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

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

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

Термины и архитектура: что именно строим

Обычно выделяют:

  • Root CA (корневой центр): самоподписанный сертификат, источник доверия.
  • Intermediate CA (промежуточный): подписывает конечные сертификаты, позволяя безопаснее управлять Root.
  • End-entity certificates (сертификаты сервиса/клиента): выдаются под ключи конкретных узлов и доменов.
  • CRL/OCSP: механизм отзыва (в простых сценариях можно ограничиться CRL, а для внутренних — управляемыми процедурами).

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

Подготовка окружения в Termux

Установим необходимые пакеты. В зависимости от политики вашей сети это может занять время:

pkg update && pkg upgrade -y
pkg install -y openssl ca-certificates openssh

Для рутинных задач (генерация, подписания, хранение) удобно организовать рабочую директорию и структуру:

mkdir -p ~/pki/{root,intermediate,certs,private,crl,ca-db,csr,logs}
chmod 700 ~/pki/private

Приватная PKI для локальных сервисов: Root CA + Intermediate CA

Приватная PKI — оптимальный выбор для внутренних сервисов: доступ к управляемым хостам, mTLS между компонентами, сервисы в локальной сети, стенды разработки.

1) Генерация Root CA

Root обычно создают офлайн или с минимальным доступом. В Termux можно сгенерировать локально, но ключ следует хранить максимально защищённо (например, на зашифрованном носителе или при строгом контроле устройства).

cd ~/pki/root
openssl genrsa -out private/root.key.pem 4096
chmod 600 private/root.key.pem

# Самоподписанный сертификат Root
openssl req -x509 -new -nodes \
  -key private/root.key.pem \
  -sha256 -days 3650 \
  -out root.cert.pem \
  -subj "/C=RU/O=RybinskLAB Private Root CA/CN=RybinskLAB Root CA" \
  -addext "basicConstraints=critical,CA:TRUE" \
  -addext "keyUsage=critical,keyCertSign,cRLSign" \
  -addext "subjectKeyIdentifier=hash" \
  -addext "authorityKeyIdentifier=keyid:always"

Рекомендуется: сохранить отпечатки (fingerprints) root.cert.pem, чтобы затем фиксировать доверие в клиентах.

openssl x509 -in root.cert.pem -noout -fingerprint -sha256

2) Создание Intermediate CA

Intermediate CA подписывается Root. Он используется для выпуска конечных сертификатов. Это снижает риск: Root ключ не участвует в ежедневной выдаче.

cd ~/pki/intermediate

# Ключ Intermediate
mkdir -p private
openssl genrsa -out private/intermediate.key.pem 4096
chmod 600 private/intermediate.key.pem

# CSR Intermediate
openssl req -new -key private/intermediate.key.pem \
  -out csr/intermediate.csr.pem \
  -subj "/C=RU/O=RybinskLAB/CN=RybinskLAB Intermediate CA"

# Подписываем CSR Root CA
cd ~/pki/root
openssl x509 -req -in ../intermediate/csr/intermediate.csr.pem \
  -CA root.cert.pem -CAkey private/root.key.pem \
  -CAcreateserial -out ../intermediate/intermediate.cert.pem \
  -days 1825 -sha256 \
  -extfile <(printf "basicConstraints=critical,CA:TRUE,pathlen:0
keyUsage=critical,keyCertSign,cRLSign
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always")

Если ваш Termux/openssl не поддерживает <(process substitution), используйте временный файл конфигурации расширений. Например:

cat > ~/pki/intermediate/ext.cnf <<'EOF'
basicConstraints=critical,CA:TRUE,pathlen:0
keyUsage=critical,keyCertSign,cRLSign
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always
EOF

cd ~/pki/root
openssl x509 -req -in ../intermediate/csr/intermediate.csr.pem \
  -CA root.cert.pem -CAkey private/root.key.pem \
  -CAcreateserial -out ../intermediate/intermediate.cert.pem \
  -days 1825 -sha256 -extfile ~/pki/intermediate/ext.cnf

Выпуск сертификата сервиса: подготовка CSR и SAN

Для современных TLS сертификатов критичны Subject Alternative Names (SAN). Указывайте DNS-имена и/или IP, по которым клиенты обращаются к сервису.

1) Сертификат сервера (DNS + IP)

mkdir -p ~/pki/certs/myservice
cd ~/pki/certs/myservice

# Секретный ключ сервиса
openssl genrsa -out private/myservice.key.pem 2048
chmod 600 private/myservice.key.pem

# CSR с SAN через конфиг
cat > csr.conf <<'EOF'
[req]
distinguished_name=req_distinguished_name
req_extensions=req_ext
prompt=no

[req_distinguished_name]
C=RU
O=RybinskLAB
CN=myservice.local

[req_ext]
subjectAltName=@alt_names

[alt_names]
DNS.1=myservice.local
DNS.2=myservice
IP.1=192.168.1.10
EOF

openssl req -new -key private/myservice.key.pem \
  -out csr/myservice.csr.pem \
  -config csr.conf

Подпишем CSR через Intermediate CA:

cd ~/pki/intermediate

# Простая подпись без полноценной CA-базы
openssl x509 -req -in ../certs/myservice/csr/myservice.csr.pem \
  -CA intermediate.cert.pem -CAkey private/intermediate.key.pem \
  -CAcreateserial -out ../certs/myservice/myservice.cert.pem \
  -days 365 -sha256 \
  -extfile <(printf "subjectAltName=DNS:myservice.local,DNS:myservice,IP:192.168.1.10
basicConstraints=critical,CA:FALSE
keyUsage=critical,digitalSignature,keyEncipherment
extendedKeyUsage=serverAuth
authorityKeyIdentifier=keyid:always")

Если снова нет поддержки <( ... ), создайте файл расширений и подставьте -extfile.

2) Полная цепочка (для web-сервера и клиентов)

Для ряда серверов требуется файл с цепочкой: leaf cert + intermediate.

cd ~/pki/certs/myservice
cat myservice.cert.pem ~/pki/intermediate/intermediate.cert.pem > myservice.fullchain.pem

Публичная PKI: варианты и практический подход

В реальных системах публичные сертификаты чаще всего выдаются коммерческими CA (или собственным публичным CA, если вы разворачиваете модель на уровне доменов). Из Termux обычно выполняют два сценария:

  • Использование публичной CA через клиентские инструменты (например, если вы получаете сертификаты для домена).
  • Включение вашего trust в клиентские устройства (например, корпоративное распространение root/intermediate для приватной PKI) — это уже «публичность» доверия в вашей среде, но остаётся приватной PKI по сути.

Если вам нужен именно публичный корневой путь (для публичного доверия браузеров), то сертификаты должны быть выданы CA, чьи корни встроены в клиентские доверенные хранилища. Термукс-подход здесь сводится к подготовке CSR, корректной SAN-структуре и последующему получению/установке сертификата по правилам конкретного провайдера CA.

Рекомендация: делайте генерацию CSR и ключей в Termux один раз, затем передавайте CSR в CA-процесс, а приватные ключи сохраняйте только у себя.

Управление PKI в Termux: структура, безопасность, ротация

Практики, которые реально уменьшают инциденты:

  • Разделяйте роли: Root храните отдельно, Intermediate — с более широким доступом, ключи сервисов — строго у конкретных хостов.
  • Ограничивайте права: применяйте chmod 600 для ключей, chmod 700 для директорий с секретами.
  • Не логируйте секреты: не выводите ключи в терминал и не копируйте их в общий текст.
  • Храните метаданные: серийные номера, даты выдачи, соответствие CSR–сертификат.
  • Ротация: планируйте выпуск новых сертификатов до истечения, а не после.

Автоматическое обновление сертификатов: безопасные схемы

Есть два уровня автоматизации:

  • Полностью автоматизированное перевыпуск (включает выпуск и установку) — чаще применимо для приватной PKI или при наличии правильных интеграций с публичной CA.
  • Полуавтоматизированное (автоматически готовим CSR/обновляем ключи, а подпись выполняется через ограниченный процесс) — хорошо для безопасности.

Ниже — практичная схема для приватной PKI в терминах Termux cron или task scheduler. Для Termux обычно удобнее crond (в зависимости от сборки), либо запуск через таск-менеджер Android. Рассмотрим универсальный подход: подготовка скрипта, который проверяет срок действия и перевыпускает сертификат.

1) Проверка срока действия

cert=~/pki/certs/myservice/myservice.cert.pem
end_date=$(openssl x509 -enddate -noout -in "$cert" | cut -d= -f2)
epoch_end=$(date -d "$end_date" +%s 2>/dev/null || date -j -f "%b %e %T %Y %Z" "$end_date" +%s)
epoch_now=$(date +%s)
left_days=$(( (epoch_end-epoch_now)/86400 ))
echo "Days left: $left_days"

На разных устройствах дата может быть обработана по-разному. Если date -d недоступна, адаптируйте команду под вашу среду.

2) Скрипт перевыпуска под приватную CA

Упрощённый пример: если осталось менее 30 дней — генерируем новый CSR/сертификат, обновляем fullchain и копируем на целевой хост. Копирование можно делать через scp по SSH (легитимный и безопасный способ для админов).

cat > ~/pki/renew-myservice.sh <<'EOF'
#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail

SERVICE_DIR="$HOME/pki/certs/myservice"
CERT="$SERVICE_DIR/myservice.cert.pem"
KEY="$SERVICE_DIR/private/myservice.key.pem"
CSR_DIR="$SERVICE_DIR/csr"
FULLCHAIN="$SERVICE_DIR/myservice.fullchain.pem"

THRESHOLD_DAYS=30

end_date=$(openssl x509 -enddate -noout -in "$CERT" | cut -d= -f2)
# date parsing может зависеть от окружения; при необходимости адаптируйте
epoch_end=$(date -d "$end_date" +%s)
epoch_now=$(date +%s)
left_days=$(( (epoch_end-epoch_now)/86400 ))

echo "[renew] Days left: $left_days"

if [ "$left_days" -gt "$THRESHOLD_DAYS" ]; then
  echo "[renew] Skip: not near expiration."
  exit 0
fi

# 1) Генерируем новый CSR
mkdir -p "$CSR_DIR"

cat > "$SERVICE_DIR/csr.conf" <<CONF
[req]
distinguished_name=req_distinguished_name
req_extensions=req_ext
prompt=no

[req_distinguished_name]
C=RU
O=RybinskLAB
CN=myservice.local

[req_ext]
subjectAltName=@alt_names

[alt_names]
DNS.1=myservice.local
DNS.2=myservice
IP.1=192.168.1.10
CONF

openssl req -new -key "$KEY" -out "$CSR_DIR/myservice.csr.pem" -config "$SERVICE_DIR/csr.conf"

# 2) Подписываем через Intermediate CA
# Лист сертификата
openssl x509 -req -in "$CSR_DIR/myservice.csr.pem" \
  -CA "$HOME/pki/intermediate/intermediate.cert.pem" \
  -CAkey "$HOME/pki/intermediate/private/intermediate.key.pem" \
  -CAcreateserial -out "$SERVICE_DIR/myservice.cert.pem" \
  -days 365 -sha256 \
  -extfile <(printf "subjectAltName=DNS:myservice.local,DNS:myservice,IP:192.168.1.10
basicConstraints=critical,CA:FALSE
keyUsage=critical,digitalSignature,keyEncipherment
extendedKeyUsage=serverAuth
authorityKeyIdentifier=keyid:always")

# 3) Полная цепочка
cat "$SERVICE_DIR/myservice.cert.pem" "$HOME/pki/intermediate/intermediate.cert.pem" > "$FULLCHAIN"

echo "[renew] Renewed: $FULLCHAIN"
EOF

chmod 700 ~/pki/renew-myservice.sh

Если у вас нет поддержки <( ... ), замените блок на временный файл конфигурации расширений.

3) Планировщик: запуск периодически

Вариант 1 (если доступен cron в вашей сборке Termux):

pkg install -y cronie
crontab -e

Добавьте, например, запуск раз в день:

0 2   * $HOME/pki/renew-myservice.sh >> $HOME/pki/logs/renew.log 2>&1

Вариант 2: запуск вручную/через Tasker/скрипт запуска (зависит от вашей инфраструктуры).

Установка сертификатов на сервис

Сертификаты нужно корректно установить в конфигурацию вашего веб-сервера/прокси/приложения. Пример для Nginx (как ориентир):

server {
  listen 443 ssl;
  server_name myservice.local;

  ssl_certificate     /path/to/myservice.fullchain.pem;
  ssl_certificate_key /path/to/private/myservice.key.pem;
}

После замены обычно требуется перезапуск сервиса.

CRL и отзыв: практический баланс

Для приватной PKI часто вводят минимальный процесс отзыва:

  • ведение списка отозванных серий (CRL),
  • публикация CRL на доступном URL или в локальном файловом репозитории,
  • регулярная загрузка CRL клиентами (настраивается под стек).

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

Локальная сеть и VPN (только для инфраструктуры)

Если вы используете VPN для создания локальной сети между устройствами (например, для админских узлов или внутреннего тестирования), то сертификаты остаются сертификатами доверия; VPN не является инструментом “обхода”. В этом случае удобно выпускать сертификаты под имена/адреса внутренних хостов и убедиться, что SAN включает фактические доменные имена или IP, которые видит клиент.

Типовые ошибки

  • Нет SAN или SAN не совпадает с тем, что вводит клиент (доменные имена, алиасы, IP).
  • Неправильные extended key usage: например, серверный сертификат для clientAuth или наоборот.
  • Секретные ключи без ограничений прав: утечки при бэкапах и публикациях.
  • Путают fullchain и leaf: часть клиентов может требовать intermediate в цепочке.
  • Планируют автоматизацию без мониторинга: скрипт должен логировать результат и быть привязан к расписанию.

Заключение

Построить PKI в Termux реально и практично: приватную инфраструктуру — через Root/Intermediate и выпуск сертификатов с корректными SAN, а публичную — через подготовку CSR и интеграцию с доверенными публичными CA или через распространение вашего доверия в корпоративной среде. Главное — строгое управление ключами, дисциплина цепочек сертификатов и автоматизация обновлений с контролем срока действия и логированием.

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

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

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

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

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