Архитектура валидации цепочки доверия X.509 и отказ INVALID_CERTIFICATE

При проверке подлинности удаленного пира в фазе IKE_AUTH устройство выполняет криптографическую валидацию предоставленного сертификата узла (End-Entity / Peer Certificate). Ошибка IKE_NOTIFY: INVALID_CERTIFICATE (код ошибки 28) или внутренняя ошибка стека Untrusted Certificate Authority / Certificate Verification Failed фиксируется в следующих случаях:

• Отсутствие корневого сертификата (Root CA): В локальном доверенном хранилище шлюза (Truststore) нет сертификата CA, подписавшего сертификат удаленного пира.
• Разрыв промежуточной цепочки (Intermediate CA missing): Удаленный пир не передал в пакете CERT Payload цепочку промежуточных сертификатов.
• Несоответствие назначения ключа (Extended Key Usage, EKU): Сертификат не содержит расширений IPsec IKE Intermediate (OID 1.3.6.1.5.5.8.2.2), Server Authentication (OID 1.3.6.1.5.5.7.3.1) или Client Authentication (OID 1.3.6.1.5.5.7.3.2).
• Истекший срок действия: Дата проверки находится вне диапазона NotBefore – NotAfter.

Бизнес-риски

Полная блокировка безопасного межфилиального взаимодействия; невозможность авторизации сотрудников через корпоративный Remote Access VPN (Cisco AnyConnect, strongSwan Client, IKEv2 Mobile).

Пошаговый регламент восстановления цепочки доверия сертификатов

Сценарий 1: Установка и назначение доверия корневым сертификатам (Trust Root CA)

Импортируйте открытый сертификат корневого удостоверяющего центра (Root CA) на все шлюзы сети и пометьте его как доверенный:

# Импорт сертификата Root CA на MikroTik RouterOS v7
/certificate import file-name=CorporateRootCA.crt

# Проверка наличия флага 'T' (Trusted) в хранилище сертификатов
/certificate print where name~"CorporateRootCA"
/certificate set [find name~"CorporateRootCA"] trusted=yes

Сценарий 2: Проверка и генерация сертификата с корректными EKU расширениями

Убедитесь, что конфигурационный файл OpenSSL содержит необходимые флаги для IPsec IKEv2:

# Фрагмент openssl.cnf для выпуска IPsec-сертификатов
[ v3_ipsec ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, keyAgreement
extendedKeyUsage = serverAuth, clientAuth, 1.3.6.1.5.5.8.2.2
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = vpn.company.com
IP.1 = 198.51.100.1

# Проверка EKU готового сертификата через OpenSSL
openssl x509 -in gateway_cert.pem -noout -text | grep -A 2 "Extended Key Usage"

Сценарий 3: Сборка полной цепочки (Full Chain Bundle) на Linux strongSwan

# Объединение сертификата шлюза и промежуточного CA в единый файл
cat /etc/swanctl/x509/gateway_cert.pem /etc/swanctl/x509/intermediate_ca.pem > /etc/swanctl/x509/fullchain.pem

# Копирование Root CA в каталог доверенных центров
sudo cp /tmp/RootCA.pem /etc/swanctl/x509ca/
sudo swanctl --load-creds

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

• Использование самоподписанного сертификата без импорта на противоположный шлюз: Самоподписанный сертификат обязан быть явно добавлен в список Trusted CA на стороне принимающего узла.
• Несовпадение Subject Alternative Name (SAN / CN) с IKE Remote ID: Если в сертификате прописан SAN vpn.corp.com, а шлюз передает в заголовках IP-адрес, валидация имени сертификата завершится сбоем.