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: X.509, OCSP и CRL для шифрования и подписи

03 сен 2026 в 01:01 Усачёв Денис Евгеньевич

Тема: разработка и внедрение собственного PKI в Termux с поддержкой сертификатов X.509, OCSP и CRL для шифрования и подписи коммуникаций Android‑устройства.

Зачем нужна собственная PKI в Termux

В сценариях, где требуется контролируемая доверительная модель (внутренние сервисы, лабораторные стенды, закрытые каналы обмена данными между устройствами), «самодельная» PKI часто оказывается практичнее, чем использование публичных удостоверяющих центров. Termux на Android позволяет собрать воспроизводимую инфраструктуру: выпуск сертификатов, их отзыв (CRL), проверку статуса (OCSP), а также применение этих механизмов в криптографических протоколах.

Ниже — подход, который не привязан к конкретному мессенджеру или протоколу уровня приложения. Он сосредоточен на PKI как фундаменте для:

  • шаблонов сертификатов X.509 для сервера/клиента;
  • CRL (списки отзыва сертификатов);
  • OCSP (On-line Certificate Status Protocol) для онлайн‑проверки статуса;
  • шифрования и подписей на основе доверия к вашему CA.

Юридические и организационные замечания

Статья носит инженерный характер и описывает настройку криптографической инфраструктуры для легитимных задач защищённого обмена и аутентификации. Используйте решения исключительно в рамках действующего законодательства РФ и внутренних регламентов организации. Не применяйте сертификаты/сервисы для несанкционированного доступа.

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

Для создания CA, выпуска сертификатов, генерации CRL и OCSP удобно использовать OpenSSL. В Termux можно автоматизировать процесс через оболочку и набор скриптов.

Рекомендуемая последовательность действий:

pkg update
pkg upgrade
pkg install openssl

Проверьте версию:

openssl version -a

Проектирование PKI: роли, сертификаты, расширения

Перед запуском важно определить модель доверия.

  • Root CA — корневой удостоверяющий центр. Обычно offline: ключ не используется для ежедневных выпусков.
  • Intermediate CA — промежуточный центр. Именно он выпускает конечные сертификаты и поддерживает удобный оборот.
  • Server/Client сертификаты — сертификаты конечных узлов (устройств, сервисов).
  • OCSP signer — сертификат для подписи ответов OCSP.

Для корректной работы CRL/OCSP в сертификатах должны присутствовать расширения:

  • CRL Distribution Points — ссылки на URL/пути, где доступна CRL;
  • Authority Information Access — ссылки на OCSP;
  • Key Usage / Extended Key Usage — ограничения по назначению;
  • Basic Constraints — CA:TRUE/FALSE.

Структура каталогов для PKI

Создадим рабочую папку. В примере ниже предполагается локальная среда разработки в Termux.

mkdir -p ~/pki/{root,intermediate,certs,crl,ocsp,newcerts,private,requests}
chmod 700 ~/pki/private

Инициализируем служебные файлы:

touch ~/pki/intermediate/index.txt
echo 1000 > ~/pki/intermediate/serial
touch ~/pki/intermediate/crlnumber.txt
chmod 600 ~/pki/intermediate/index.txt ~/pki/intermediate/serial ~/pki/intermediate/crlnumber.txt

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

Root CA лучше держать как offline‑ключ. В Termux это можно реализовать организационно (не хранить в общем доступе) и ограничить операции.

Создадим ключ и самоподписанный Root сертификат:

mkdir -p ~/pki/root/private
chmod 700 ~/pki/root/private
openssl genrsa -aes256 -out ~/pki/root/private/root.key.pem 4096

openssl req -x509 -new -nodes \
  -key ~/pki/root/private/root.key.pem \
  -sha256 -days 3650 \
  -out ~/pki/root/root.crt.pem \
  -subj "/C=RU/ST=Region/L=City/O=Org/OU=PKI/CN=RootCA"

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

Генерация Intermediate CA и выпуск его сертификата Root CA

Intermediate CA будет использоваться чаще, поэтому держите ключ защищённым паролем и аккуратно управляйте доступом.

1) Генерируем ключ Intermediate:

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

2) Готовим CSR:

openssl req -new \
  -key ~/pki/intermediate/private/intermediate.key.pem \
  -out ~/pki/intermediate/intermediate.csr.pem \
  -subj "/C=RU/ST=Region/L=City/O=Org/OU=PKI/CN=IntermediateCA"

3) Подписываем CSR Root CA. Для корректной работы CA применяем расширения (примерно). В практике удобно использовать файл конфигурации OpenSSL.

Создадим конфигурацию для расширений Intermediate:

cat > ~/pki/root/openssl-root-ext.cnf <<'EOF'
[ v3_intermediate_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical,CA:true,pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
EOF

4) Подписываем:

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

Конфигурация для выпуска конечных сертификатов (X.509)

Чтобы массово выпускать сертификаты устройств/сервисов, подготовьте конфигурацию OpenSSL под ваши требования (Subject, SAN, EKU и точки CRL/OCSP).

Создадим шаблон расширений для end-entity (пример: сертификат сервера). Важно указать SAN (Subject Alternative Name).

cat > ~/pki/intermediate/openssl-end-entity.cnf <<'EOF'
[ v3_end_entity ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
basicConstraints = critical,CA:false
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth

# Укажите, где вы будете публиковать CRL/OCSP.
# В локальной сети это может быть HTTP на вашем узле.
crlDistributionPoints = @crl_dp

[ crl_dp ]
fullname = URI:http://127.0.0.1:8080/pki/crl/intermediate.crl.pem

authorityInfoAccess = @ocsp_aia
[ ocsp_aia ]
OCSP;URI:http://127.0.0.1:8080/pki/ocsp/intermediate-ocsp
EOF

Если вам нужны клиентские сертификаты, вы измените extendedKeyUsage = clientAuth (или добавите отдельный профиль).

Выпуск сертификата сервера/устройства

Допустим, нам нужен сертификат для сервера (или устройства), доступного по имени device1.local.

1) Генерируем ключ сервера:

openssl genrsa -out ~/pki/private/device1.key.pem 2048

2) Создаём CSR с SAN. SAN задаётся через конфигурацию.

cat > ~/pki/requests/device1-san.cnf <<'EOF'
[ req ]
distinguished_name = req_distinguished_name
req_extensions = req_ext
prompt = no

[ req_distinguished_name ]
C = RU
ST = Region
L = City
O = Org
OU = Devices
CN = device1.local

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = device1.local
IP.1 = 127.0.0.1
EOF

openssl req -new -key ~/pki/private/device1.key.pem -out ~/pki/requests/device1.csr.pem -config ~/pki/requests/device1-san.cnf

3) Подписываем CSR Intermediate CA. Для этого используйте openssl ca и создайте minimal-configuration для CA. Ниже — базовый пример.

cat > ~/pki/intermediate/openssl-ca.cnf <<'EOF'
[ ca ]
default_ca = CA_default

[ CA_default ]
dir               = ~/pki/intermediate
certs            = $dir/certs
new_certs_dir    = $dir/newcerts
database         = $dir/index.txt
serial           = $dir/serial
crlnumber        = $dir/crlnumber.txt

private_key      = $dir/private/intermediate.key.pem
certificate      = $dir/intermediate.crt.pem

default_md       = sha256
policy           = policy_any

x509_extensions  = v3_end_entity

copy_extensions = copy

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

EOF

Важно, что расширения end-entity определены отдельно. Мы указываем x509_extensions на профиль v3_end_entity, а сам профиль можно подтянуть через -extfile.

4) Запускаем подписание:

mkdir -p ~/pki/intermediate/certs ~/pki/intermediate/newcerts
openssl ca \
  -batch -config ~/pki/intermediate/openssl-ca.cnf \
  -in ~/pki/requests/device1.csr.pem \
  -out ~/pki/certs/device1.crt.pem \
  -extfile ~/pki/intermediate/openssl-end-entity.cnf \
  -extensions v3_end_entity

Подготовка CRL: выпуск списка отозванных сертификатов

CRL позволяет проверять статус сертификата через регулярную публикацию. В вашей PKI нужно уметь:

  • отозвать сертификат;
  • сгенерировать CRL;
  • опубликовать CRL по URL, указанному в crlDistributionPoints.

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

Предположим, вы хотите отозвать сертификат device1.crt.pem.

Сначала найдём серийный номер:

openssl x509 -in ~/pki/certs/device1.crt.pem -noout -serial

Далее отметим сертификат как revoked через openssl ca. Для этого потребуется точная команда с параметрами reason и датой. Типовой сценарий:

openssl ca -config ~/pki/intermediate/openssl-ca.cnf -revoke ~/pki/certs/device1.crt.pem

Генерация CRL

Выпустим CRL от Intermediate CA:

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

Проверьте содержимое CRL:

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

Публикация CRL/OCSP в локальной сети

Для примера проще всего развернуть локальный HTTP-сервер, который отдаёт файл CRL и принимает OCSP запросы. Если вы создаёте локальную сеть для лабораторного обмена, это делается безопасно и без целей обхода ограничений.

Вариант: поднять простой HTTP сервер, который раздаёт каталог ~/pki (например, на тестовой машине/устройстве).

Например, структуру публикации удобно сделать так:

mkdir -p ~/pki/web/crl ~/pki/web/ocsp
cp ~/pki/crl/intermediate.crl.pem ~/pki/web/crl/intermediate.crl.pem

Дальше настройте веб-доступ на вашем стенде. Конкретный способ (nginx, caddy, python http.server и т.д.) зависит от вашей среды; важно, чтобы URL совпадал с тем, что вы указали в crlDistributionPoints.

OCSP: настройка онлайн-проверки статуса

OCSP снижает необходимость тянуть CRL целиком при каждой проверке, но требует отдельного компонента:

  • сертификат OCSP responder с правильными расширениями;
  • подпись OCSP ответов;
  • доступность сервиса по URL из authorityInfoAccess.

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

Для OCSP responder используйте отдельную пару ключей и сертификат, подписанный вашим Intermediate CA.

openssl genrsa -out ~/pki/private/ocsp-responder.key.pem 2048

CSR OCSP responder:

cat > ~/pki/requests/ocsp-responder-san.cnf <<'EOF'
[ req ]
distinguished_name = req_distinguished_name
req_extensions = req_ext
prompt = no

[ req_distinguished_name ]
C = RU
ST = Region
L = City
O = Org
OU = PKI
CN = OCSP-Responder

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = ocsp.local
EOF

openssl req -new -key ~/pki/private/ocsp-responder.key.pem -out ~/pki/requests/ocsp-responder.csr.pem -config ~/pki/requests/ocsp-responder-san.cnf

Расширения для OCSP signer:

cat > ~/pki/intermediate/openssl-ocsp-signer.cnf <<'EOF'
[ v3_ocsp_signer ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
basicConstraints = critical,CA:false
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning
EOF

Подписываем сертификат OCSP signer через Intermediate:

openssl ca \
  -batch -config ~/pki/intermediate/openssl-ca.cnf \
  -in ~/pki/requests/ocsp-responder.csr.pem \
  -out ~/pki/certs/ocsp-responder.crt.pem \
  -extfile ~/pki/intermediate/openssl-ocsp-signer.cnf \
  -extensions v3_ocsp_signer

Тестовая генерация OCSP ответов (проверка логики)

Реализация OCSP сервера может быть интегрирована по-разному. На уровне инженерной проверки полезно уметь делать тестовый OCSP ответ и сверять, что цепочка доверия и статус отзывов корректны.

Прежде чем поднимать сервер, убедитесь, что в базе CA обновляется состояние сертификатов (index.txt) и CRL/статус отражает отзыв.

Практическое применение OCSP/CRL при шифровании и подписи

После того как у вас есть:

  • CA цепочка (Root и Intermediate);
  • сертификаты устройств;
  • CRL для offline/кэшируемых проверок;
  • OCSP endpoint для онлайн‑проверок,

можно использовать mTLS/TLS‑подобные схемы и подписывать сообщения.

На уровне обмена данными типовой рабочий принцип:

  • каждая сторона предъявляет сертификат;
  • клиент/сервер валидирует цепочку до Root/Intermediate;
  • проверяет статус сертификата через CRL и/или OCSP;
  • после успешной проверки происходит установление защищённого канала (шифрование) и/или обмен подписанными данными.

Для строгой проверки статуса на стороне клиента важно настроить проверки OCSP и CRL в том инструменте, который использует TLS/проверку сертификатов. OpenSSL умеет OCSP‑проверки при определённых сценариях, но точная команда зависит от выбранного «верхнего» протокола.

Рекомендованный минимальный «чек‑лист» внедрения

  • Хранение ключей: Root key — наиболее защищённо; Intermediate key — строго с контролем доступа; ключи устройств — по отдельности.
  • Проверка расширений: SAN, EKU, AIA/CRL Distribution Points совпадают с реальными URL публикации.
  • Процедуры отзыва: отзыв → генерация CRL → публикация → контроль обновления.
  • OCSP режим: OCSP responder signing certificate корректный (OCSPSigning), и доступен по URL.
  • Тестирование: проверка цепочки, статуса до/после отзыва.

Безопасность и эксплуатационные нюансы на Android/Termux

Termux удобен для разработки и локальных стендов, но в эксплуатационной модели учитывайте:

  • перезапуск/потерю сессий и необходимость воспроизводимости генерации;
  • защиту файлов в ~/.ssh/~/pki/private и исключение случайного бэкапа в облако;
  • контроль прав доступа (chmod 600/700 для приватных ключей).

Базовая практика для приватных ключей:

chmod 700 ~/pki/private
chmod 600 ~/pki/private/*.key.pem 2>/dev/null || true

Заключение

Собственная PKI в Termux — реалистичный и контролируемый способ организовать доверие между Android‑устройствами: выпуск сертификатов X.509, публикацию и проверку CRL, а также онлайн‑проверку через OCSP. Ключ к успеху — правильно спроектированные роли CA, корректные расширения в сертификатах и согласованность URL публикации статуса.

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

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

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

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

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