ابطال گواهی‌ها شکست می‌خورد: کدام میزبان به چه چیزی دسترسی ندارد

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

مسیر واکشی در اختیار اعتبارسنج است

با شناسایی اعتبارسنج شروع کنید. وقتی لپ‌تاپ گواهی دروازه را بررسی می‌کند، واکشی را لپ‌تاپ انجام می‌دهد؛ وقتی دروازه گواهی کلاینت را بررسی می‌کند، این کار را دروازه انجام می‌دهد. یک سرویس احراز هویت پشتیبان می‌تواند اعتبارسنج سوم با موقعیت شبکه‌ای خودش اضافه کند. هر کدام مسیر متفاوتی به اینترنت و پیکربندی پروکسی متفاوتی دارند. شواهدی که روی ایستگاه کاری مدیر جمع می‌شود هیچ چیزی درباره سروری درون DMZ نمی‌گوید.

پیش از تغییر هر چیزی، گواهی، اعتبارسنج، زمان تلاش و کد وضعیت دقیق را یادداشت کنید.

نقطه انتشار را از گواهی بخوانید

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

openssl x509 -in gateway.cer -noout -text | grep -A3 "CRL Distribution Points"
openssl x509 -in gateway.cer -noout -text | grep -A2 "Authority Information Access"

گستره نخست نقاط توزیع CRL را فهرست می‌کند و دومی روش‌های دسترسی به اطلاعات مرجع را که می‌تواند وضعیت OCSP و واکشی گواهی صادرکننده را پوشش دهد. این‌ها سازوکارهای متفاوتی هستند و پاسخ‌دهنده OCSP یک فایل CRL نیست. میزبان انتشار اغلب یک وب‌سرور معمولی است نه ماشین CA، زیرا صادرکننده آفلاین می‌تواند CRL را امضا کند که سرور دیگری آن را توزیع می‌کند. بنابراین قاعده فایروالی که به‌عنوان دسترسی به CA توصیف شود برای پیاده‌سازی یا بازبینی بیش از حد مبهم است.

واکشی را از دستگاهی که اعتبارسنجی می‌کند آزمایش کنید

آزمایش واکشی را در محیطی اجرا کنید که واقعاً اعتبارسنجی را انجام می‌دهد، با مواد گواهی تأییدشده و بدون کلید خصوصی.

certutil -urlfetch -verify .\client-test.cer
curl -sS -o /dev/null -w "%{http_code}\n" http://crl.example.com/ca.crl

اجرای certutil زنجیره را بررسی می‌کند و گزارش می‌دهد کدام واکشی‌های URL موفق یا ناموفق بوده‌اند، در حالی که فراخوانی curl یک نشانی انتشار را از همان میزبان آزمایش می‌کند و فقط یک کد وضعیت برمی‌گرداند. واکشی ناموفق از نشانی قابل دسترس به مشکلات محتوا یا امضا اشاره دارد؛ خطای اتصال به مسیریابی، DNS یا پروکسی اشاره دارد. هر دو نتیجه را نگه دارید، زیرا یک واکشی موفق ثابت نمی‌کند که کل زنجیره قابل استفاده است. میزبان و مسیر نمونه را به نقطه توزیعی که در گواهی یافت شده تغییر دهید.

داده‌های ناقص را از وضعیت ابطال جدا کنید

چهار نتیجه از بیرون شبیه هم به نظر می‌رسند: نقطه در دسترس نیست، فهرست کهنه است، فهرست را صادرکننده اشتباه امضا کرده یا گواهی واقعاً باطل شده است. تنها مورد آخر یک نتیجه وضعیت است و فقط همان حذف دسترسی را توجیه می‌کند. حافظه نهان تصویر را پیچیده‌تر می‌کند، زیرا داده‌های پیش‌تر واکشی‌شده می‌توانند مسیر انتشار خراب را تا نوسازی بعدی پنهان کنند. غیرفعال کردن بررسی ابطال، حذف گواهی‌های بی‌ربط یا راه‌اندازی مجدد دروازه همه تشخیص را با فعالیت جایگزین می‌کنند.

پس از اصلاح، یک احراز هویت تازه را اجباری کنید و تأیید کنید که واکشی وضعیت مورد نظر موفق است. جایی که هویت آزمایشی کنترل‌شده وجود دارد، تأیید کنید که هنوز رد می‌شود، زیرا دسترس‌پذیری‌ای که بررسی را حذف می‌کند اصلاح نیست.