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 потрібно вимкнути.