Перейти к содержимому
-Advanced
UA RU
093 442 18 08 Консультация

Запись

FortiGate не подключается к FortiGuard: ошибка different CRL scope

В сентябре 2026 года часть устройств Fortinet потеряла доступ к сервисам FortiGuard из-за ошибки проверки сертификата different CRL scope. Проблема затрагивала TLS-соединения с FortiGuard Anycast: устройство отклоняло цепочку сертификатов и не могло получить обновления баз либо обратиться к части облачных сервисов.

Событие важно правильно классифицировать. Fortinet не называет его CVE, не сообщает о компрометации и отдельно указывает, что сертификаты не были отозваны. Это операционный инцидент PKI/CRL, который проявил поведение проверки отзыва сертификатов в FortiOS.

По состоянию на 11 сентября DigiCert откатил изменение CRL, вызвавшее сбой. Поэтому сейчас не следует автоматически переключать все FortiGate на Unicast. Сначала нужно подтвердить симптом, зафиксировать текущую конфигурацию и, если Anycast должен остаться включенным, очистить локальный CRL-кеш.

Какие системы могли быть затронуты

Fortinet указывает FortiGate, FortiProxy, FortiPAM и другие продукты, использовавшие соответствующую цепочку доверия. Для FortiGate определяющим условием была работа с сервисами FortiGuard через Anycast.

Официальный Technical Tip не содержит таблицы affected versions и не называет исправленную версию FortiOS. Связанная документация сообщает, что Anycast используется по умолчанию в FortiGate 6.4.3 и новее, но это нельзя превращать в утверждение «все версии от 6.4.3 уязвимы». Проверять нужно конфигурацию конкретного устройства, способ доступа к FortiGuard и фактический debug.

Fortinet сообщает:

  • сервисы FortiGuard Anycast могли быть недоступны;
  • сервисы Unicast не были затронуты;
  • FortiGuard Secure DNS, по оценке вендора, не должен был пострадать;
  • точный перечень моделей и веток FortiOS не опубликован.

Симптомы

Типичный признак - FortiGate не завершает TLS handshake с сервисом FortiGuard. В debug процессов update или forticldd появляется ошибка:

Cert error 44, different CRL scope. Depth 2
Certificate failed verification. Error: 44 (different CRL scope)
subject: ... CN=DigiCert High Assurance EV Root CA

Из-за этого могут не обновляться внутренние базы FortiGuard или не работать отдельные облачные обращения. Сам факт ошибки не означает, что сертификат отозван или устройство скомпрометировано.

До изменения конфигурации исключите другие причины: завершение лицензии, DNS, неправильное системное время, маршрут, фильтрацию исходящего трафика, недоступность FortiGuard и проблемы конкретного VDOM.

Безопасная диагностика

Работайте через SSH или CLI Console с административным доступом. Сначала зафиксируйте версию FortiOS, режим VDOM/HA, management VDOM и сделайте проверенную резервную копию конфигурации. Для точного rollback сохраните полный блок FortiGuard, включая default и unset values:

get system status
show full-configuration system fortiguard

На устройстве с VDOM запускайте диагностику в management VDOM, а изменение config system fortiguard выполняйте в global configuration context. На устройстве без VDOM используйте обычный system context. Перед вводом команд проверьте доступный синтаксис через CLI help именно для своей ветки FortiOS.

Для короткого debug Fortinet приводит такие команды:

diagnose debug disable
diagnose debug reset
diagnose debug console timestamp enable
diagnose debug application update -1
diagnose debug application forticldd -1
diagnose debug enable
execute update-now

Не оставляйте verbose debug включенным. После воспроизведения ошибки сразу завершите сбор:

diagnose debug disable
diagnose debug reset

Ищите одновременно error 44, different CRL scope, depth 2 и упоминание DigiCert High Assurance EV Root CA. Другая TLS-ошибка требует отдельной диагностики.

Почему возникла ошибка

FortiGuard Anycast использовал серверные сертификаты, подписанные промежуточным центром DigiCert SHA2 Extended Validation Server CA, который восходит к DigiCert High Assurance EV Root CA.

9 сентября 2026 года DigiCert добавил в соответствующий Certificate Revocation List расширение Issuing Distribution Point. IDP описывает область действия CRL и связанный distribution point. Изменение было технически допустимым, но активировало дополнительную проверку на FortiGate.

FortiOS сопоставил issuer CRL с subject корневого сертификата и начал проверять корневой сертификат по этому списку. Корневые CA обычно не содержат CRL Distribution Point. Из-за несоответствия FortiGate вернул different CRL scope и остановил TLS handshake.

Таким образом, проблема возникла не из-за отзыва сертификата, а из-за сочетания нового IDP в CRL и поведения certificate revocation check в FortiOS.

Актуальное решение после отката DigiCert

11 сентября DigiCert откатил IDP-изменения для соответствующих CRL. После этого Fortinet рекомендовал пользователям Anycast очистить CRL-кеш коротким переключением режима.

Выполняйте этот шаг только если до инцидента Anycast был включен и должен остаться целевым режимом:

config system fortiguard
    set fortiguard-anycast disable
end
config system fortiguard
    set fortiguard-anycast enable
end

После этого принудительно запустите обновление:

execute update-now

execute update-now обновляет внутренние базы FortiGuard, а не прошивку FortiOS.

Если устройство намеренно работает через Unicast, не включайте Anycast по этой инструкции. Сохраните прежний режим.

Временный Unicast workaround

Во время активного инцидента Fortinet предложил временно перейти с Anycast на Unicast, поскольку Unicast-серверы использовали другую цепочку сертификатов. Это fallback, а не обязательная постоянная конфигурация.

Перед применением команд:

  • сохраните show full-configuration system fortiguard и проверенную резервную копию;
  • проверьте исходящий доступ UDP/8888;
  • согласуйте maintenance window;
  • зафиксируйте точные исходные значения fortiguard-anycast, protocol, port и sdns-server-ip, включая состояние unset/default;
  • подготовьте возврат к исходной конфигурации.

Конфигурация из официального сообщения Fortinet приведена как vendor-supplied reference. Не применяйте ее, пока не проверите версию FortiOS, VDOM/HA context, CLI help и собственные нестандартные настройки FortiGuard:

config system fortiguard
    set fortiguard-anycast disable
    set protocol udp
    set port 8888
    set sdns-server-ip 208.91.112.220 173.243.140.53 210.7.96.53 200.91.112.220
end
execute update-now

Fortinet отмечает, что эти настройки меняют способ исходящей связи устройства с FortiGuard и не изменяют транзитный production traffic. Однако они меняют конфигурацию FortiGuard, поэтому их нельзя вставлять без проверки версии, VDOM, политик egress и резервной копии.

Rollback к исходной конфигурации

После восстановления сервисов верните все четыре измененных параметра к точно зафиксированным значениям: fortiguard-anycast, protocol, port и sdns-server-ip. Одного set fortiguard-anycast enable недостаточно: UDP/8888 и список серверов могут остаться скрытым изменением конфигурации.

Универсального rollback-блока здесь нет, потому что исходные значения могут быть explicit, default или unset. Восстановите exact pre-change block из проверенной резервной копии в правильном global context. Не используйте unset для параметра, если до инцидента он имел явное значение.

После восстановления выполните show full-configuration system fortiguard, сравните результат с frozen pre-state и только после точного совпадения запустите execute update-now.

Что проверить после изменения

Работа считается завершенной не после принятия CLI-команды, а после технической проверки:

  1. execute update-now завершается без different CRL scope.
  2. В debug нет certificate verification error 44.
  3. Статус лицензированных сервисов FortiGuard активен.
  4. Базы AV, IPS, web filtering и других приобретенных сервисов имеют актуальное время обновления.
  5. DNS, маршруты, VDOM и исходящие firewall policy остались штатными.
  6. Verbose debug выключен.
  7. Временный Unicast или другое исключение имеет ответственного и дату отмены.
  8. show full-configuration system fortiguard совпадает с согласованным target state, а после rollback - с exact pre-state.

Нужно ли обновлять FortiOS

Поддерживаемую ветку FortiOS следует обновлять по обычному change-процессу, но Fortinet не назвал конкретный fixed build для этого инцидента. Нельзя обещать, что произвольное обновление прошивки само по себе исправит different CRL scope.

Официальный статус на дату подготовки материала: непосредственный триггер отменен DigiCert, кеш рекомендовано очистить, а Fortinet продолжает работу над улучшением обработки certificate revocation.

Когда нужна помощь

Если FortiGuard остается недоступным, нужно раздельно проверить CRL-кеш, DNS, маршрут, VDOM, лицензию, egress policy и состояние серверов Fortinet. IT Advanced может проверить конфигурацию FortiGate, выполнить контролируемое изменение с резервной копией и проверить восстановление сервисов.

Выбратьться по поддержке сетевой инфраструктуры

Частые вопросы

Это уязвимость FortiGate?

Fortinet описывает операционный сбой TLS/PKI, а не CVE. Вендор не сообщает об эксплуатации, несанкционированном доступе или компрометации.

Сертификат DigiCert был отозван?

Нет. Fortinet отдельно указал, что сертификаты не были отозваны. Ошибка касалась области действия CRL и процедуры проверки.

Какие версии FortiOS затронуты?

Fortinet не опубликовал affected-version matrix. Известно, что Anycast является типовым режимом начиная с FortiGate 6.4.3, но это не полный и не официальный диапазон affected versions.

Нужно ли сейчас переходить на Unicast?

Не автоматически. После обновления Fortinet от 11 сентября 2026 года для устройств, уже использующих Anycast, текущая рекомендация - очистить CRL-кеш. Unicast можно рассматривать как контролируемый fallback по решению администратора, если доступность не восстановилась.

Что делает execute update-now?

Команда запускает обновление внутренних баз FortiGuard. Она не обновляет прошивку FortiOS.

Влияет ли переключение FortiGuard на транзитный трафик?

По данным Fortinet, приведенное изменение не влияет на production или passing-through traffic. При этом оно меняет служебную связь с FortiGuard, поэтому нужны backup, проверка egress и post-change test.

Как понять, что проблема устранена?

Повторный execute update-now должен пройти без error 44, статус сервисов и время баз должны обновиться, а verbose debug необходимо выключить.