رفع خطای SSL در FortiGate؛ چرا سایت‌ها با Deep Inspection باز نمی‌شوند؟

ARIANA بدون دیدگاه
رفع خطای SSL Deep Inspection در FortiGate و عیب‌یابی گواهی Certificate و HTTPS

11 دقیقه مطالعه

آموزش

10 آبان 1405

FORTINET | SSL/TLS | NETWORK SECURITY

رفع خطای SSL در FortiGate؛ چرا سایت‌ها با Deep Inspection باز نمی‌شوند؟

اگر بعد از فعال‌سازی SSL Deep Inspection در فایروال FortiGate بعضی سایت‌ها باز نمی‌شوند، مرورگر خطای Certificate نشان می‌دهد یا نرم‌افزارهای سازمانی ارتباطشان را از دست می‌دهند، قبل از غیرفعال‌کردن قابلیت‌های امنیتی باید علت را پیدا کنید. در این راهنما روش بررسی CA، گواهی سرور، Certificate Pinning، احراز هویت mTLS، لاگ‌های SSL و تنظیم استثناهای محدود را مرحله‌به‌مرحله یاد می‌گیرید.

پاسخ سریع: علت خطای SSL Inspection در FortiGate چیست؟

در حالت Deep Inspection، فایروال ارتباط رمزگذاری‌شده HTTPS را برای بررسی امنیتی رمزگشایی می‌کند و سپس ارتباط جدیدی با کلاینت برقرار می‌کند. گواهی جایگزین توسط CA انتخاب‌شده در پروفایل SSL/SSH امضا می‌شود. اگر کلاینت به این CA اعتماد نداشته باشد، خطای Certificate ظاهر می‌شود. البته اگر فقط یک نرم‌افزار یا وب‌سایت خاص مشکل داشته باشد، احتمال Certificate Pinning، احراز هویت دوطرفه mTLS، گواهی نامعتبر سرور یا ناسازگاری پروتکل نیز وجود دارد.

قابلیت SSL Inspection یکی از بخش‌های مهم امنیت در فایروال‌های Fortinet است. بسیاری از تهدیدات امروزی در ترافیک رمزگذاری‌شده HTTPS پنهان می‌شوند و بدون بررسی مناسب، امکان شناسایی محتوای مخرب کاهش پیدا می‌کند.

اما فعال‌کردن Deep Inspection بدون آماده‌سازی گواهی‌ها و کلاینت‌ها می‌تواند باعث اختلال در تجربه کاربران شود. هدف این مقاله حذف هشدار مرورگر به هر قیمت نیست؛ هدف، بازگرداندن دسترسی کاربران همراه با حفظ سطح امنیت شبکه است.

۱. تفاوت Certificate Inspection و Deep Inspection چیست؟

قبل از عیب‌یابی باید بدانیم کدام نوع بازرسی روی ترافیک اعمال شده است. FortiGate دو روش اصلی برای بررسی ارتباطات SSL/TLS دارد که از نظر سطح دسترسی به محتوای رمزگذاری‌شده متفاوت هستند.

Certificate Inspection

اطلاعات گواهی و بخش‌های قابل مشاهده در فرایند TLS را بررسی می‌کند، اما محتوای رمزگذاری‌شده HTTPS را برای بازرسی کامل باز نمی‌کند.

مناسب برای سناریوهایی که نیاز به بررسی گواهی دارند اما رمزگشایی کامل محتوا موردنظر نیست.

Deep / Full SSL Inspection

ترافیک TLS را رمزگشایی می‌کند، محتوای آن را برای کنترل‌های امنیتی بررسی می‌کند و سپس ارتباط را مجدداً رمزگذاری می‌کند.

برای بررسی محتوای HTTPS به CA مناسب، مدیریت اعتماد کلاینت‌ها و سازگاری نرم‌افزارها نیاز دارد.

در نتیجه، اگر فقط Certificate Inspection فعال باشد، نباید انتظار داشته باشید تمام محتوای HTTPS مانند Deep Inspection بررسی شود. از طرف دیگر، فعال‌کردن Deep Inspection نیز بدون مدیریت صحیح CA می‌تواند موجب هشدارهای امنیتی در مرورگرها شود.

۲. Deep Inspection چگونه گواهی سایت را تغییر می‌دهد؟

برای درک خطا، ابتدا باید فرایند ارتباط را بشناسیم.

فرض کنید کاربر می‌خواهد به آدرس HTTPS یک وب‌سایت متصل شود. در حالت عادی، مرورگر گواهی اصلی وب‌سرور را دریافت و زنجیره اعتماد آن را بررسی می‌کند. اما وقتی Deep Inspection روی ترافیک اعمال شود، FortiGate نقش واسط بازرسی را بر عهده می‌گیرد.

مراحل عملکرد SSL Deep Inspection

مرحله اول: ارتباط کاربر

کلاینت درخواست اتصال HTTPS را به مقصد ارسال می‌کند.

↓
مرحله دوم: رمزگشایی در FortiGate

فایروال ارتباط TLS را بررسی و گواهی جایگزین را با CA انتخاب‌شده امضا می‌کند.

↓
مرحله سوم: اعمال سیاست امنیتی

محتوای قابل بررسی به کنترل‌های امنیتی مانند Antivirus، Web Filtering و سایر پروفایل‌های فعال ارجاع می‌شود.

↓
مرحله چهارم: رمزگذاری مجدد

ترافیک مجدداً رمزگذاری شده و به مقصد ارسال می‌شود.

در پروفایل پیش‌فرض FortiGate، گواهی Fortinet_CA_SSL برای امضای گواهی‌های جایگزین استفاده می‌شود. سازمان‌ها می‌توانند براساس معماری PKI خود از CA اختصاصی و مورد اعتماد استفاده کنند.

۳. سناریوی واقعی: بعد از فعال‌سازی Deep Inspection سایت‌ها باز نمی‌شوند

فرض کنید یک شرکت با ۸۰ کاربر، برای افزایش امنیت شبکه پروفایل Deep Inspection را روی Policy خروجی اینترنت فعال کرده است.

بعد از اعمال تغییرات، اتفاقات زیر رخ می‌دهد:

  • مرورگر Chrome و Edge برای تعدادی از سایت‌ها خطای NET::ERR_CERT_AUTHORITY_INVALID نمایش می‌دهند.
  • یک نرم‌افزار حسابداری ابری دیگر به سرور متصل نمی‌شود.
  • برخی کاربران موبایل همچنان به سایت‌ها دسترسی دارند، اما کاربران ویندوز با خطا مواجه‌اند.
  • دسترسی به بعضی سایت‌ها برقرار است، اما چند مقصد مشخص همچنان مشکل دارند.

این نشانه‌ها لزوماً یک علت مشترک ندارند. خطای مرورگر می‌تواند از نصب نبودن CA ناشی شود، درحالی‌که اختلال نرم‌افزار حسابداری ممکن است به Certificate Pinning یا mTLS مربوط باشد.

قبل از هر تغییر این اطلاعات را ثبت کنید:

مدل دستگاه، نسخه و Build سیستم‌عامل FortiOS، نام Firewall Policy، نام SSL/SSH Profile، IP کلاینت، دامنه مقصد، زمان رخداد و متن دقیق خطا.

۴. مرحله اول عیب‌یابی: بررسی Firewall Policy و SSL Profile

یکی از اشتباهات رایج این است که مدیر شبکه یک SSL Inspection Profile را بررسی می‌کند، درحالی‌که ترافیک موردنظر از Policy دیگری عبور می‌کند.

ابتدا به مسیر زیر بروید:

Policy & Objects → Firewall Policy

Policy مربوط به کاربران را پیدا کنید و بررسی کنید:

  • Source و Destination با ترافیک موردنظر تطابق دارند؟
  • Service و Interfaceها درست تعریف شده‌اند؟
  • SSL/SSH Inspection Profile به همین Policy متصل است؟
  • آیا Policy دیگری قبل از آن ترافیک را Match می‌کند؟
  • آیا پروفایل انتخاب‌شده Certificate Inspection است یا Deep Inspection؟

سپس به مسیر زیر بروید:

Security Profiles → SSL/SSH Inspection

پروفایل مورد استفاده را باز کنید و CA Certificate، وضعیت Inspection، تنظیمات گواهی نامعتبر و استثناهای تعریف‌شده را بررسی کنید.

برای ثبت وضعیت اولیه، دستورات زیر را در CLI اجرا کنید:

get system status
show firewall policy
show firewall ssl-ssh-profile

این دستورات برای مشاهده تنظیمات هستند. اگر دستگاه از VDOM استفاده می‌کند، بررسی را در VDOM مربوط انجام دهید. خروجی‌ها ممکن است شامل اطلاعات حساس شبکه باشند؛ پیش از ارسال آن‌ها برای پشتیبانی، اطلاعات محرمانه را محافظت کنید.

۵. مرحله دوم: بررسی Issuer و زنجیره اعتماد Certificate

این مرحله یکی از مهم‌ترین قسمت‌های عیب‌یابی است.

در مرورگر روی آیکون اطلاعات اتصال کلیک کنید و جزئیات Certificate را مشاهده کنید. موارد زیر را بررسی کنید:

  • نام دامنه گواهی با آدرس وب‌سایت مطابقت دارد؟
  • گواهی از چه صادرکننده‌ای دریافت شده است؟
  • تاریخ شروع و پایان اعتبار گواهی صحیح است؟
  • زنجیره اعتماد کامل است؟
  • آیا گواهی جایگزین توسط CA مربوط به FortiGate امضا شده است؟
حالت اول: Issuer برابر Fortinet_CA_SSL

معمولاً نشان می‌دهد FortiGate گواهی جایگزین را امضا کرده است. اگر کلاینت به این CA اعتماد نداشته باشد، هشدار مرورگر ظاهر می‌شود.

حالت دوم: گواهی نامعتبر سرور

ممکن است مشکل از انقضا، نام دامنه، زنجیره ناقص یا CA غیرقابل اعتماد در سمت وب‌سرور باشد.

نکته مهم این است که مشاهده Issuer به‌تنهایی علت نهایی را اثبات نمی‌کند. باید جزئیات گواهی اصلی سرور و رویدادهای SSL FortiGate را نیز بررسی کنید.

۶. مرحله سوم: نصب و توزیع صحیح CA Certificate

اگر مشکل به عدم اعتماد کلاینت به CA مربوط باشد، باید گواهی عمومی CA مورد استفاده در پروفایل Deep Inspection روی دستگاه‌های مدیریت‌شده سازمان مورد اعتماد قرار بگیرد.

در FortiGate ابتدا مسیر زیر را بررسی کنید:

System → Certificates

گواهی CA مورد استفاده در SSL/SSH Inspection Profile را شناسایی کنید. اگر از CA داخلی FortiGate استفاده می‌کنید، گواهی عمومی مربوط را از دستگاه دریافت کنید.

در شبکه سازمانی مبتنی بر Windows Active Directory، روش مناسب برای توزیع متمرکز گواهی عمومی CA می‌تواند Group Policy باشد.

مسیر معمول توزیع گواهی در Windows Group Policy

  1. گواهی عمومی CA را از FortiGate دریافت کنید.
  2. اصالت گواهی و اثرانگشت آن را از مسیر مورد اعتماد تأیید کنید.
  3. کنسول Group Policy Management را باز کنید.
  4. یک GPO مشخص برای کلاینت‌های مشمول بسازید.
  5. به مسیر Computer Configuration بروید.
  6. Windows Settings → Security Settings → Public Key Policies را باز کنید.
  7. Trusted Root Certification Authorities را انتخاب کنید.
  8. گواهی عمومی تأییدشده را وارد و GPO را روی کلاینت‌های هدف اعمال کنید.

پس از اعمال Policy، در کلاینت ویندوز می‌توانید با دستور زیر وضعیت به‌روزرسانی Group Policy را اجرا کنید:

gpupdate /force

سپس مرورگر را مجدداً باز کنید و گواهی سایت را بررسی کنید.

هشدار امنیتی بسیار مهم

فقط گواهی عمومی CA را برای کلاینت‌ها توزیع کنید. کلید خصوصی CA نباید روی کامپیوتر کاربران قرار بگیرد. همچنین گواهی Fortinet_CA_Untrusted را به Trusted Root اضافه نکنید؛ این کار می‌تواند هشدار گواهی نامعتبر را پنهان کند و اعتماد امنیتی کاربران را تضعیف کند.

اگر از Firefox استفاده می‌کنید، Trust Store مرورگر را هم بررسی کنید؛ رفتار آن می‌تواند با Chrome و Edge متفاوت باشد. در محیط‌های مدیریت‌شده، سیاست توزیع CA باید برای مرورگرهای مورد استفاده سازمان نیز در نظر گرفته شود.

۷. چرا بعضی نرم‌افزارها با وجود نصب CA همچنان کار نمی‌کنند؟

این سناریو معمولاً زمانی دیده می‌شود که مرورگر به‌درستی کار می‌کند، اما یک نرم‌افزار خاص نمی‌تواند به سرور خود متصل شود.

Certificate Pinning چیست؟

بعضی نرم‌افزارها فقط به یک گواهی مشخص یا کلید عمومی مشخص اعتماد می‌کنند. این روش Certificate Pinning نام دارد.

در Deep Inspection، گواهی واقعی سرور با گواهی جایگزین امضاشده توسط CA فایروال جایگزین می‌شود. بنابراین ممکن است نرم‌افزار به‌جای اعتماد به CA سازمان، انتظار گواهی یا کلید مشخصی را داشته باشد و ارتباط را رد کند.

در این شرایط نصب CA روی ویندوز الزاماً مشکل را حل نمی‌کند. باید با سازنده نرم‌افزار یا مستندات رسمی سرویس بررسی شود که آیا Pinning وجود دارد یا خیر.

mTLS یا احراز هویت دوطرفه چیست؟

در برخی سرویس‌های سازمانی، تنها سرور گواهی ارائه نمی‌کند؛ کلاینت نیز باید Certificate هویتی خود را ارائه دهد. این روش Mutual TLS یا mTLS نام دارد.

در بعضی سناریوها، Deep Inspection می‌تواند با فرایند احراز هویت مبتنی بر Client Certificate ناسازگار شود. بنابراین اگر سامانه‌ای با گواهی کلاینت کار می‌کند، باید مستندات Fortinet و سازنده آن سامانه بررسی شود.

در این شرایط، تعریف یک استثنای محدود برای دامنه یا سرویس مشخص ممکن است لازم باشد؛ اما قبل از آن باید نوع احراز هویت و ریسک کاهش بازرسی تأیید شود.

۸. بررسی تنظیمات گواهی نامعتبر در SSL/SSH Profile

یکی از بخش‌هایی که در عیب‌یابی نادیده گرفته می‌شود، نحوه برخورد FortiGate با گواهی نامعتبر سرور است.

در پروفایل Deep Inspection، تنظیمات مربوط به Untrusted SSL Certificates و Validation Failed Certificates را بررسی کنید.

در مستندات FortiOS، رفتارهای مهم زیر مطرح شده‌اند:

Keep Untrusted & Allow

اتصال با حفظ وضعیت نامعتبر گواهی اجازه عبور می‌گیرد. هشدار اعتماد نباید به‌عنوان گواهی معتبر تلقی شود.

Block

ارتباط دارای گواهی نامعتبر مسدود می‌شود.

Trust & Allow

گواهی نامعتبر پذیرفته و به‌صورت مورد اعتماد بازامضا می‌شود. استفاده از آن نیازمند ارزیابی دقیق ریسک است.

نام گزینه‌ها و رفتار دقیق آن‌ها به نوع Inspection و نسخه FortiOS وابسته است. برای رفع یک خطای ناشناخته، گزینه Trust & Allow را به‌صورت عمومی فعال نکنید.

اگر گواهی اصلی وب‌سرور دارای زنجیره ناقص یا نام دامنه اشتباه است، راه‌حل اصولی معمولاً اصلاح گواهی در سمت وب‌سرور است؛ نه تغییر کورکورانه Trust Store فایروال.

۹. بررسی SSL Anomaly Logs و ثبت جزئیات Certificate

اگر هنوز علت خطا مشخص نیست، سراغ لاگ‌های SSL بروید.

در GUI مسیر زیر را بررسی کنید:

Log & Report → Security Events / UTM

نام دقیق بخش و فیلترها ممکن است با نسخه FortiOS و نوع Logging متفاوت باشد. در رویدادها به موارد زیر توجه کنید:

  • IP مبدأ و مقصد
  • نام دامنه یا SNI
  • نام SSL/SSH Inspection Profile
  • نوع رخداد SSL Anomaly
  • وضعیت Certificate Validation
  • Action اعمال‌شده روی ارتباط
  • زمان و تعداد تکرار خطا

برای مشاهده جزئیات بیشتر درباره گواهی سرور، Fortinet امکان فعال‌کردن SSL Server Certificate Logging را در پروفایل‌های مربوط فراهم کرده است.

نمونه پیکربندی زیر را فقط پس از بررسی نام پروفایل و در بازه نگهداری مناسب اجرا کنید:

config firewall ssl-ssh-profile
    edit "custom-deep-inspection"
        set ssl-server-cert-log enable
    next
end

نام پروفایل نمونه است؛ آن را با نام واقعی پروفایل خود جایگزین کنید. پس از پایان عیب‌یابی، در صورت عدم نیاز به ثبت جزئیات بیشتر، تنظیم را مطابق سیاست Logging سازمان بازبینی کنید.

۱۰. خطای Certificate Probe Failure چیست؟

FortiGate در برخی حالت‌های Certificate Inspection و Deep Inspection، پیش از تکمیل اتصال HTTPS، گواهی سرور را بررسی می‌کند. اگر دریافت گواهی یا برقراری Handshake با مشکل مواجه شود، ممکن است رخداد Certificate Probe Failure ثبت شود.

علت‌های احتمالی عبارت‌اند از:

  • اشکال در TCP یا TLS Handshake
  • مسیر اشتباه یا اختلال Routing
  • گواهی Root یا Intermediate غیرقابل اعتماد
  • زنجیره ناقص گواهی سرور
  • اختلال ارتباطی بین FortiGate و مقصد

در برخی نسخه‌ها گزینه Cert Probe Failure برای پروفایل‌های سفارشی و شرایط مشخص در دسترس است. دو رفتار اصلی آن Allow و Block هستند.

توصیه امنیتی

تغییر Cert Probe Failure از Block به Allow می‌تواند در شرایطی باعث عبور ارتباطی شود که گواهی آن قابل بررسی نبوده است. این تغییر را راه‌حل عمومی خطای SSL در نظر نگیرید و فقط با تحلیل ریسک و مستندات همان نسخه انجام دهید.

۱۱. نقش TLS 1.3، HTTP/3، QUIC و ECH در اختلال SSL Inspection

پروتکل‌های جدید وب می‌توانند در رفتار بازرسی ترافیک تفاوت ایجاد کنند. به همین دلیل اگر یک وب‌سایت در یک مرورگر کار می‌کند اما در مرورگر دیگر مشکل دارد، نباید فقط سراغ CA رفت.

مواردی که باید بررسی شوند

HTTP/3 و QUIC: ارتباط HTTP/3 معمولاً بر بستر QUIC و UDP اجرا می‌شود. رفتار آن با مسیر TLS مبتنی بر TCP یکسان نیست.

ECH: قابلیت Encrypted Client Hello بخشی از اطلاعات Client Hello را رمزگذاری می‌کند و می‌تواند روی قابلیت‌های وابسته به مشاهده SNI اثر بگذارد.

TLS 1.3: تنظیمات و قابلیت‌های پشتیبانی‌شده در Inspection باید با نسخه FortiOS و حالت Flow یا Proxy تطبیق داده شوند.

در نسخه‌های جدید FortiOS گزینه‌های مرتبط با HTTP/3 و ECH در تنظیمات SSL/SSH Inspection وجود دارند، اما رفتار و دسترسی آن‌ها ممکن است با نسخه، مدل و حالت بازرسی تفاوت داشته باشد.

قبل از تغییر سیاست Block یا Bypass، Release Notes و راهنمای همان Build را بررسی کنید. غیرفعال‌کردن یک پروتکل در کل شبکه فقط برای حل مشکل یک کاربر، تصمیم مناسبی نیست.

۱۲. چگونه SSL Exemption تعریف کنیم بدون اینکه امنیت کل شبکه کاهش پیدا کند؟

اگر مشخص شد یک نرم‌افزار یا وب‌سایت به‌دلیل Certificate Pinning یا محدودیت فنی با Deep Inspection سازگار نیست، می‌توان برای همان مقصد استثنای مشخص تعریف کرد.

در پروفایل SSL/SSH Inspection بخش مربوط به Exemptions را بررسی کنید. بسته به نسخه و نوع تنظیمات می‌توانید از Address، FQDN، Wildcard FQDN یا دسته‌های وب استفاده کنید.

روش پیشنهادی:

  1. دامنه واقعی موردنیاز سرویس را از مستندات سازنده یا لاگ استخراج کنید.
  2. مطمئن شوید خطا واقعاً ناشی از Deep Inspection است.
  3. فقط مقصدهای ضروری را در فهرست استثنا قرار دهید.
  4. نام سرویس، علت استثنا و مسئول تأییدکننده را ثبت کنید.
  5. پس از اعمال تغییر، دسترسی و لاگ‌ها را دوباره بررسی کنید.
  6. برای استثنا تاریخ بازبینی تعیین کنید.
نمونه تصمیم درست

یک نرم‌افزار سازمانی به دو دامنه مشخص نیاز دارد و سازنده استفاده از Certificate Pinning را تأیید کرده است. به‌جای Bypass کل دامنه‌های یک سرویس‌دهنده بزرگ، فقط همان دو مقصد با تأیید مسئول امنیت از Deep Inspection مستثنا می‌شوند.

به خاطر داشته باشید که SSL Exemption به معنی عبور بدون هیچ کنترل امنیتی نیست؛ سایر کنترل‌های اعمال‌شده روی Policy همچنان باید بررسی شوند. با این حال، محتوای رمزگذاری‌شده مقصد استثناشده دیگر مانند حالت Deep Inspection قابل بررسی نخواهد بود.

۱۳. جدول تشخیص سریع خطاهای SSL در FortiGate

خطا روی اکثر سایت‌ها

CA انتخاب‌شده در پروفایل، نصب گواهی عمومی روی Endpointها و Trust Store مرورگرها را بررسی کنید.

خطا فقط روی یک وب‌سایت

گواهی واقعی سرور، Chain، SNI، Certificate Validation و SSL Anomaly Logs را بررسی کنید.

مرورگر سالم است ولی نرم‌افزار قطع است

Certificate Pinning، mTLS، Trust Store اختصاصی نرم‌افزار و مقصدهای ارتباطی آن را بررسی کنید.

فقط یک مرورگر مشکل دارد

Trust Store مرورگر، QUIC، HTTP/3 و تفاوت سیاست‌های مرورگر را بررسی کنید.

خطای Certificate Probe Failure

دسترسی FortiGate به مقصد، Routing، TLS Handshake و زنجیره CA سرور را بررسی کنید.

۱۴. چک‌لیست نهایی قبل از بستن مشکل

☐ نسخه و Build دقیق FortiOS ثبت شده است.

☐ Firewall Policy مؤثر شناسایی شده است.

☐ نوع Inspection و SSL/SSH Profile مشخص شده است.

☐ CA انتخاب‌شده در پروفایل بررسی شده است.

☐ Issuer و زنجیره گواهی در مرورگر بررسی شده‌اند.

☐ گواهی عمومی CA با روش مدیریت‌شده روی کلاینت‌های مجاز توزیع شده است.

☐ احتمال Certificate Pinning و mTLS بررسی شده است.

☐ SSL Anomaly Logs و Certificate Probe Failure بررسی شده‌اند.

☐ HTTP/3، QUIC و ECH در صورت مرتبط بودن بررسی شده‌اند.

☐ استثناهای SSL محدود، مستند و قابل بازبینی هستند.

☐ پس از تغییر، هم دسترسی کاربر و هم سطح امنیت مجدداً آزمایش شده است.

۱۵. آیا برای SSL Inspection باید مدل FortiGate را ارتقا داد؟

مشاهده خطای Certificate به‌تنهایی دلیل ضعیف بودن سخت‌افزار نیست. ابتدا باید مشکلات مربوط به CA، گواهی سرور، Policy و سازگاری نرم‌افزار برطرف شوند.

اما اگر پس از تنظیم صحیح، در زمان فعال بودن Deep Inspection مصرف منابع بالا می‌رود و شبکه با افت عملکرد مواجه می‌شود، باید ظرفیت واقعی دستگاه را بررسی کنید.

برای انتخاب سخت‌افزار مناسب، فقط Firewall Throughput خام را ملاک قرار ندهید. ظرفیت Threat Protection، تعداد ارتباطات هم‌زمان، SSL Inspection، VPN و رشد آینده شبکه نیز اهمیت دارند.

برای مقایسه تجهیزات می‌توانید مشخصات FortiGate FG-70G و FortiGate FG-100F را بررسی کنید.

اگر مشکل پس از ارتقای سیستم‌عامل آغاز شده، قبل از تغییر نسخه، Release Notes و مسیر ارتقای دستگاه را بررسی کنید. راهنمای Firmware و ارتقای FortiGate 100F نیز برای این موضوع مفید است.

همچنین اگر هم‌زمان با خطاهای ارتباطی، حافظه دستگاه به محدوده بحرانی رسیده است، مقاله عیب‌یابی Conserve Mode و مصرف بالای RAM در FortiGate را مطالعه کنید. این دو مشکل از نظر علت فنی یکسان نیستند.

۱۶. سؤالات متداول درباره SSL Deep Inspection

آیا نصب Fortinet_CA_SSL روی همه دستگاه‌ها ضروری است؟

فقط دستگاه‌هایی که تحت Deep Inspection قرار می‌گیرند و طبق سیاست سازمان مجاز به مدیریت آن‌ها هستید، باید CA عمومی تأییدشده را دریافت کنند. برای دستگاه‌های شخصی یا خارج از مدیریت سازمان، نصب گواهی ریشه بدون سیاست و رضایت مناسب نیست.

چرا بعد از نصب CA هنوز بعضی سایت‌ها باز نمی‌شوند؟

ممکن است گواهی اصلی سرور نامعتبر باشد، برنامه از Certificate Pinning استفاده کند، mTLS فعال باشد یا Trust Store نرم‌افزار با سیستم‌عامل متفاوت باشد.

آیا برای رفع خطای SSL باید Deep Inspection را خاموش کنیم؟

خیر. ابتدا علت را شناسایی کنید. در صورت نیاز به استثنا، فقط مقصد مشخص و تأییدشده را از Deep Inspection خارج کنید.

تفاوت Fortinet_CA_SSL و Fortinet_CA_Untrusted چیست؟

Fortinet_CA_SSL برای امضای گواهی‌های جایگزین در سناریوهای Deep Inspection استفاده می‌شود. Fortinet_CA_Untrusted با وضعیت گواهی نامعتبر مرتبط است و نباید به Trusted Root کاربران اضافه شود.

آیا Certificate Inspection همان Deep Inspection است؟

خیر. Certificate Inspection اطلاعات گواهی و لایه قابل مشاهده TLS را بررسی می‌کند؛ Deep Inspection محتوای رمزگذاری‌شده را نیز برای کنترل امنیتی باز می‌کند.

آیا SSL Exemption امنیت شبکه را کاهش می‌دهد؟

روی مقصد استثناشده دید محتوایی Deep Inspection کاهش می‌یابد. بنابراین استثنا باید محدود، مستند و با تأیید مسئول امنیت باشد.

جمع‌بندی: خطای SSL را اصولی برطرف کنید، نه با حذف امنیت

در عیب‌یابی SSL Deep Inspection، حذف هشدار مرورگر هدف اصلی نیست؛ باید مشخص شود مشکل از اعتماد کلاینت به CA، گواهی واقعی سرور، Certificate Pinning، احراز هویت mTLS یا تنظیمات پروتکل است.

با بررسی Policy، SSL/SSH Profile، زنجیره گواهی و لاگ‌های FortiGate می‌توان بیشتر خطاهای رایج را شناسایی کرد. در صورت نیاز نیز می‌توان استثناهای محدود و قابل کنترل تعریف کرد؛ بدون اینکه با غیرفعال‌کردن عمومی Inspection، دید امنیتی سازمان از بین برود.

FARABORD TECH | NETWORK SECURITY

انتخاب فایروال مناسب برای امنیت ترافیک رمزگذاری‌شده

برای انتخاب مدل FortiGate، ظرفیت SSL Inspection، تعداد کاربران، VPN و سرویس‌های امنیتی فعال باید در کنار یکدیگر بررسی شوند.

مشاهده تجهیزات Fortinet

مشاوره خرید و فنی: 02191097707

منابع رسمی و مستندات فنی Fortinet

برای تهیه این راهنما از مستندات رسمی Fortinet در شاخه FortiOS 7.6 و مقالات فنی جامعه Fortinet استفاده شده است. بعضی گزینه‌ها و مسیرهای GUI ممکن است براساس مدل و Build دستگاه متفاوت باشند؛ قبل از اعمال تغییر در محیط عملیاتی، مستندات همان نسخه را بررسی کنید.

مطالب مرتبط

دیدگاه ها برای این نوشته بسته می باشد