Перейти к содержанию

Получение ГОСТ CRL по HTTPS без внешнего загрузчика

В НАЙС.ОС charon с включёнными curl и revocation может самостоятельно запрашивать CRL по HTTPS, проверять TLS-сервер, ГОСТ-подпись CRL и её применимость к сертификату. В реальном испытании ссылка https://192.168.10.15:18444/current.der была запрошена самим charon на узле Б, после чего IKE/CHILD SA успешно установились.

1. Подготовка защищённого CRL-сервера

В производственной сети используйте утверждённый HTTPS-сервер с действительным сертификатом, подходящим DNS SAN/IP SAN, нужным набором доверенных TLS CA и контролируемым доступом. Разместите публичный DER CRL (без закрытых ключей) по постоянному URL. В лаборатории использован Python HTTPS-сервер только для демонстрации; он не является частью RPM strongSwan и не рекомендуется как производственный HTTP-сервер.

Пример URI:

https://pki.example.internal/ike/crl/current.der

Адрес из испытаний 192.168.10.15:18444 — временный и не должен использоваться на чужих машинах. Срок действия HTTPS-сертификата и доверие к его УЦ проверяются отдельно от ГОСТ-подписи самой CRL.

2. Настроить доверие TLS в НАЙС.ОС 5.2

На проверенной НАЙС.ОС установлены ca-certificates, p11-kit, p11-kit-trust, update-ca-trust, а OpenSSL использует /etc/ssl/certs/ca-certificates.crt → /etc/pki/tls/certs/ca-bundle.crt. Команда update-ca-trust extract сама по себе не обновила рабочий bundle в протестированном RPM. Исправно сработал штатный make-ca -r с локальным сертификатом в /etc/ssl/local/.

Для внутреннего тестового CA (пример, при внедрении следуйте корпоративной PKI):

# Предварительно проверьте, что make-ca существует:
command -v make-ca
# Пример: внутренняя корпоративная HTTPS CA уже находится в /root/corp-https-ca.crt
cp -a /etc/pki/tls/certs/ca-bundle.crt \
  "/root/ca-bundle-before-ike.$(date +%Y%m%d-%H%M%S).crt"
openssl x509 -in /root/corp-https-ca.crt \
  -trustout -addtrust serverAuth \
  -out /etc/ssl/local/corp-ike-https-ca.pem
chmod 644 /etc/ssl/local/corp-ike-https-ca.pem
/usr/sbin/make-ca -r

Проверка:

openssl verify -CAfile /etc/pki/tls/certs/ca-bundle.crt /root/corp-https-ca.crt
python3 - <<'PY'
import ssl
print(ssl.get_default_verify_paths())
PY

Проверяйте TLS настоящим клиентом без опции пропуска сертификата (curl -k запрещён). Не смешивайте CA для HTTPS и ГОСТ CA для IKEv2: это разные доверенные цепочки. На НАЙС.ОС работающий bundle OpenSSL в проверенной системе обновляется именно через make-ca -r.

3. Указать URL выдающего CRL УЦ

cat > /etc/swanctl/conf.d/niceos-ike-ca-source.conf <<'EOF'
authorities {
  niceos-ike-ca {
    cacert = niceos-ike-ca.der
    crl_uris = https://pki.example.internal/ike/crl/current.der
  }
}
EOF
swanctl --load-authorities
swanctl --list-authorities

Замените URI на свой, убедитесь в работающем TLS SAN и доверии на стороне charon. Проверенные плагины: curl, revocation, x509, niceos-gost.

4. Проверить получение непосредственно через charon

В тестовое окно завершите действующую SA. На стороне, которая должна получить CRL, временно уберите локальную CRL с резервной копией и вызовите swanctl --load-creds --clear. Убедитесь, что swanctl --list-certs --type x509_crl пуст. Инициируйте VPN с этой стороны:

swanctl --initiate --child gost-x509
swanctl --list-certs --type x509_crl
journalctl -u strongswan.service --since '3 minutes ago' --no-pager \
  | grep -Ei 'fetching crl|crl correctly signed|certificate status|IKE_SA'

На HTTPS-сервере должен появиться новый GET от узла в момент IKE_AUTH. Реальный проверенный журнал:

fetching crl from 'https://192.168.10.15:18444/current.der' ...
crl correctly signed by "CN=NiceOS-RPM-Test-GOST-CA"
certificate status is good
IKE_SA gost-x509 established

После испытания верните локальный файл из резервной копии и swanctl --load-creds --clear.

5. Отказы и особенности кэша

Если нет действительной локальной CRL и HTTPS недоступен, revocation = strict отклонит новое IKE_AUTH. В испытании зафиксированы libcurl request failed [7], crl fetching failed, RULE_CRL_VALIDATION is FAILED, but requires at least GOOD; после восстановления CRL подключение снова установилось с 10/10 ICMP.

Если в памяти уже есть действительная CRL, она может быть использована без нового HTTP GET. Не трактуйте crl_uris как непрерывный фоновый опрос, не заявляйте автоматический anti-rollback и немедленное закрытие уже установленных SA. Отрицательные сценарии · эксплуатация.