Центр Диагностики & База Системных Ошибок

Решения для Windows Server, Active Directory, 1С, СУБД, Linux, Cisco, MikroTik и IP-телефонии.

⚠️ Важная информация Все материалы, инструкции, команды и скрипты предоставлены исключительно в ознакомительных целях. Их применение может повлиять на работу операционной системы, баз данных и сетевого оборудования. Перед выполнением действий обязательно создайте резервную копию. При отсутствии необходимой квалификации обратитесь к ИТ-специалистам.

Траблшутинг ошибок сертификатов IPsec в Cisco: %CRYPTO-4-IKEMP_BAD_CERT

Обновлено: 24.08.2026  ·  Официальная база знаний
  • В логах Cisco регистрируется ошибка %CRYPTO-4-IKEMP_BAD_CERT: Certificate validation failed for peer /CN=vpn.remote.com: certificate expired or CRL check failed.
  • VPN-туннель IPsec (Site-to-Site или Remote Access AnyConnect) не устанавливается на Phase 1 (IKE SA).
  • Команда show crypto isakmp sa или show crypto ikev2 sa показывает отсутствие установленных сессий.

1. Проверка системного времени и статуса NTP

Основная причина отказа сертификата — рассинхронизация часов:

show clock detail
show ntp status

2. Проверка срока действия локальных и CA сертификатов

show crypto pki certificates verbose
show crypto pki trustpoints

3. Диагностика проверки списков отзыва (CRL / OCSP)

Если маршрутизатор не имеет прямого доступа к серверу CRL Distribution Point (CDP):

configure terminal
crypto pki trustpoint CA_ROOT
 revocation-check none
exit

4. Проверка цепочки доверия и соответствия FQDN / Subject Name

show crypto ikev2 profile
show crypto isakmp profile

5. Включение детальной отладки PKI и IKEv2

debug crypto pki messages
debug crypto pki transactions
debug crypto ikev2 internal
Практический опыт инженера: Всегда настраивайте аппаратные часы 'clock timezone' и синхронизацию с надежным NTP-сервером до генерации ключей RSA и отправки запроса на подпись сертификата (CSR).

Частые вопросы (FAQ)

Почему ошибка IKEMP_BAD_CERT возникает внезапно на работающем туннеле?

Чаще всего это связано с истечением срока действия сертификата узла или корневого CA, сбоем доступности сервера списков отзыва CRL (HTTP/LDAP таймаут) или скачком системного времени при сбое NTP.

Безопасно ли использовать 'revocation-check none'?

Это снижает безопасность, так как маршрутизатор перестает проверять отозванные сертификаты. Для production рекомендуется настраивать локальный кэш CRL или проверку через протокол OCSP.

Что делать, если в сертификате не совпадает FQDN/IP пира?

В IKEv2 профиле настройте сопоставление через команду 'match identity remote fqdn <имя>' или скорректируйте Subject Alternative Name (SAN) при перевыпуске сертификата.

Как очистить кэш CRL вручную на Cisco IOS?

Используйте привилегированную команду: 'clear crypto pki crl'.