محتوای آموزشی وبلاگ نت‌آرام
برنامه‌ای روی سرور مجازی ایران هنگام اتصال امن به سرویس دیگری خطا می‌دهد و در Event Viewer رویداد
Schannel 36882 دیده می‌شود. در سناریوی مستند Microsoft، این رویداد به گواهی دریافتی از سرور مقابل و صادرکننده‌ای اشاره می‌کند که در زنجیره اعتماد ویندوز قابل اعتماد تشخیص داده نشده است. مشکل می‌تواند از گواهی خودامضا، نبود CA معتبر یا کامل‌نبودن زنجیره باشد.این رویداد همیشه نام مقصد یا همه جزئیات را نشان نمی‌دهد. ابتدا باید برنامه و اتصال دقیق را با زمان خطا پیدا کرد. گواهی را نباید صرفاً با خاموش‌کردن بررسی TLS یا اعتماد به یک CA ناشناس «درست» جلوه داد؛ این کار می‌تواند اتصال به مقصد جعلی را ممکن کند.
۱. رویداد را به برنامه و مقصد واقعی وصل کنید
PowerShell را با حساب مدیر باز کنید و رویدادهای اخیر را بخوانید:
کد / دستورGet-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Schannel'; Id=36882; StartTime=(Get-Date).AddDays(-2)} -MaxEvents 20 | Format-List TimeCreated, Id, Message
اگر رویدادی در این بازه وجود نداشته باشد دستور ممکن است پیام بدهد. ساعت رخداد را با لاگ برنامه، نام سرور مقصد و زمان تلاش ناموفق تطبیق دهید. یک رویداد 36882 قدیمی ممکن است به برنامه دیگری مربوط باشد. اگر برنامه خطای متفاوتی مثل نام گواهی ناهماهنگ یا انقضا می‌دهد، همان پیام را نیز در تشخیص لحاظ کنید.
طبق مستند Microsoft درباره CA نامعتبر در SQL Server، این خطا ممکن است پس از تغییر نسخه یا پیش‌فرض driver نیز ظاهر شود. مثال SQL نشان می‌دهد تغییر سمت کلاینت هم می‌تواند رفتار بررسی گواهی را عوض کند؛ علت را با نام برنامه و نسخه خودتان تأیید کنید.
۲. نام و گواهی‌ای را که واقعاً دریافت می‌شود ببینید
نام مورد استفاده برنامه، پورت و مسیر شبکه را یادداشت کنید. نامی مثل
db.example.com با IP مستقیم یا نام مستعار دیگری که در SAN گواهی نیست فرق دارد. اگر مقصد رابط HTTPS دارد، آن را از همان ماشین و با همان نام در مرورگر باز کنید و جزئیات گواهی، تاریخ، صادرکننده و مسیر گواهی را ببینید. این آزمایش فقط همان سرویس و مسیر مرورگر را نشان می‌دهد؛ SQL و پروتکل‌های دیگر ممکن است از گواهی یا روش متفاوتی استفاده کنند.از مدیر سرویس مقابل بخواهید گواهی عمومی و زنجیره آن را به‌صورت فایل دریافت‌شده از منبع معتبر در اختیار شما بگذارد. کلید خصوصی را برای عیب‌یابی زنجیره درخواست نکنید. روی ویندوز، با جایگزین‌کردن مسیر فایل عمومی اجرا کنید:
کد / دستورcertutil -dump 'C:\Temp\server-public.cer'
certutil -verify 'C:\Temp\server-public.cer'
دستور اول جزئیات فایل و دومی نتیجه ساخت زنجیره را نشان می‌دهد. خروجی را برای خطای نامعتبر بودن صادرکننده، زنجیره ناقص و تاریخ بررسی کنید. این بررسی فایلِ ارائه‌شده است و به‌تنهایی تضمین نمی‌کند برنامه دقیقاً همان گواهی را از مقصد واقعی دریافت می‌کند؛ اثر انگشت گواهی را با سرویس و زمان اتصال تطبیق دهید.
۳. تاریخ، نام و کاربرد را جداگانه بررسی کنید
کد / دستورGet-Date -Format 'yyyy-MM-dd HH:mm:ss zzz'
tzutil /g
ساعت اشتباه کلاینت یا سرور می‌تواند گواهی معتبر را خارج از بازه اعتبار نشان دهد. زمان واقعی و منطقه زمانی را با منبع معتبر سازمان مقایسه کنید. در گواهی، نام مقصد باید در SAN مناسب وجود داشته باشد و کاربرد گواهی با نقش سرور و الزامات برنامه سازگار باشد. بررسی زنجیره صادرکننده لزوماً تطبیق نام برنامه را به‌تنهایی ثابت نمی‌کند.
اگر نام در گواهی وجود ندارد، از نام صحیح تأییدشده استفاده کنید یا از صادرکننده گواهی جدید با SAN مناسب بخواهید. اگر گواهی منقضی شده، باید تمدید و در سرویس مقصد نصب شود؛ تغییر ساعت برای عبور از خطا راهکار نیست.
۴. زنجیره ناقص را در سمت درست کامل کنید
زنجیره معمولاً از گواهی سرویس، یک یا چند CA میانی و ریشه مورد اعتماد تشکیل می‌شود. اگر گواهی سرویس معتبر است اما سرور مقصد گواهی میانی لازم را ارائه نمی‌کند، مدیر سرویس باید زنجیره مناسب همان صادرکننده را در سرویس یا فروشگاه مربوط نصب و اتصال را دوباره آزمایش کند. افزودن تصادفی گواهی سرور به فروشگاه ریشه، مشکل زنجیره را به روش امن حل نمی‌کند.
برای CA داخلی سازمان، اثر انگشت و هویت گواهی ریشه را از مسیر مستقل و مورد تأیید مدیر امنیت تأیید کنید. سپس توزیع آن را با Group Policy یا روش مدیریت گواهیِ تأییدشده برای رایانه‌های لازم انجام دهید. فروشگاه
Local Computer و Current User متفاوت‌اند و برنامه‌ای که به صورت سرویس اجرا می‌شود ممکن است از زمینه دیگری استفاده کند. افزودن CA ناشناس به Trusted Root به آن اختیار صدور گواهی قابل اعتماد می‌دهد؛ هر فایل دریافتی را به آنجا اضافه نکنید. راهنمای مدیریت فروشگاه گواهی Windows Server محل‌های مختلف را توضیح می‌دهد.۵. اگر مشکل از بررسی ابطال یا دسترسی شبکه است
گواهی ممکن است نشانی‌های CA و فهرست ابطال یا OCSP داشته باشد. در محیط آزمایش مجاز می‌توانید از فایل عمومی گواهی این بررسی را انجام دهید:
کد / دستورcertutil -urlfetch -verify 'C:\Temp\server-public.cer'
این گزینه ممکن است به نشانی‌های موجود در گواهی اتصال شبکه بزند؛ پیش از اجرا سیاست شبکه و محرمانگی را رعایت کنید. اگر دسترسی به آدرس ابطال یا فایل CA میانی شکست خورد، DNS، پراکسی و مجوز همان مسیر را با مدیر شبکه اصلاح کنید. خطای دسترسی به منبع ابطال با اثبات باطل‌شدن گواهی یکسان نیست، اما نباید برای رفع سریع، بررسی ابطال را به‌طور سراسری خاموش کرد.
اگر از پراکسی با بازرسی TLS استفاده می‌شود، برنامه ممکن است گواهی صادرشده توسط CA سازمان را ببیند. هویت و سیاست آن را با مسئول امنیت تطبیق دهید. گواهی ناشناخته یا متفاوت از مسیر مورد انتظار می‌تواند نشانه اتصال به مقصد اشتباه باشد؛ قبل از اعتماد، علت را روشن کنید.
۶. اتصال اصلی را دوباره امتحان کنید
پس از اصلاح زنجیره یا گواهی، همان برنامه را با همان نام و حساب سرویس آزمایش کنید. موفقیت
certutil یا مرورگر کافی نیست، چون برنامه ممکن است فروشگاه اعتماد، پراکسی یا تنظیمات متفاوت داشته باشد. زمان تلاش تازه را با لاگ برنامه و رویداد Schannel مقایسه کنید. اگر رویداد جدید باقی است، اثر انگشت گواهی دریافتی، زنجیره و نام مقصد را دوباره بررسی کنید.در سرور مدیریت سخت‌افزار، گواهی iDRAC جدا از گواهی سیستم‌عامل است؛ اگر مشکل دقیقاً در آن پنل است، راهنمای تمدید گواهی iDRAC را دنبال کنید.
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام