ورود PIV در ویندوز با EAP-TLS شکست می‌خورد؟ مسیر امضا را بررسی کنید
گواهی کارت می‌تواند قابل مشاهده باشد و ورود باز هم شکست بخورد. چهار مرحله را طی کنید: نمایه، انتخاب، امضای محلی و اعتبارسنجی از راه دور.
گواهی یک کارت PIV را در هر پنجره ویندوز نمایش دهید و ورود به VPN باز هم می‌تواند شکست بخورد، چون قابل مشاهده بودن و قابل استفاده بودن دو ویژگی متفاوت‌اند. گواهی یک شیء عمومی است؛ ورود به عملیاتی با کلید خصوصی نیاز دارد که کارت بر اساس قواعد دسترسی خودش انجام می‌دهد. میان این دو واقعیت چهار مرحله قرار دارد که هر کدام به شکلی متفاوت شکست می‌خورند: انتخاب نمایه، انتخاب گواهی، امضای محلی و اعتبارسنجی در سمت سرور. طی کردن آن‌ها به‌ترتیب، یک خطای عمومی دست‌دهی را به پرسشی مشخص برای کسی که بخش بعدی را در اختیار دارد تبدیل می‌کند.
با نمایه و روش EAP شروع کنید
ویژگی‌های اتصال را باز کنید و بخوانید که نمایه واقعاً از کدام روش EAP استفاده می‌کند، سپس بخوانید که روش برای انتخاب کدام گواهی پیکربندی شده است. بسیاری از استقرارها هم روش بیرونی مبتنی بر گواهی دارند و هم روش درونی، و گواهی‌ای که در سطح اتصال پیکربندی شده به‌طور خودکار همانی نیست که درون EAP-TLS ارائه می‌شود. اگر نمایه گواهی را بر پایه صادرکننده یا بر پایه فیلتر موضوع انتخاب کند، آن فیلتر از میان آنچه ویندوز در مخزن مربوط می‌بیند انتخاب می‌کند، نه از میان آنچه کارت به‌طور تصادفی دارد. فیلتری که با هیچ چیز مطابقت ندارد بسته به پیکربندی نمایه به یک پرسش یا به شکستی خاموش برمی‌گردد، به همین دلیل ثبت اثر انگشت انتخاب‌شده پیش از هر تغییری ارزش دارد.
همچنین مشخص کنید که اتصال با حساب کاربر واردشده اجرا می‌شود یا به‌عنوان ماشین. همین یک واقعیت تعیین می‌کند کدام مخازن گواهی در دامنه‌اند و کدام بافت امنیتی امضا را انجام می‌دهد.
تأیید کنید کدام گواهی انتخاب شد
اثر انگشتی را که ویندوز انتخاب کرده با نیازمندی مقایسه کنید: استفاده برای احراز هویت کلاینت، زنجیره‌ای که در ریشه مورد اعتماد پایان می‌یابد، هویتی که خط‌مشی سرور احراز هویت آن را نگاشت می‌کند، و دوره اعتباری که لحظه واقعی تلاش را پوشش می‌دهد. این‌ها بررسی‌های جداگانه‌اند و آخری بیش از انتظار مردم غافلگیری می‌گیرد، به‌ویژه با گواهی‌هایی که به‌صورت پیوسته صادر می‌شوند و نمایه‌های ذخیره‌شده در حافظه پنهان که هنوز به انتخاب دیروز اشاره می‌کنند.
بافت کاربر و ماشین نیمه دیگر بررسی است. گواهی‌ای که در مخزن شخصی کاربر است برای سرویسی که به‌عنوان ماشین اجرا می‌شود نامرئی است، و گواهی ماشین را تبادل EAP در حالت کاربر ارائه نمی‌دهد مگر آنکه نمایه چنین بگوید. وارد کردن دوباره گواهی در مخزن اشتباه، گواهی قابل مشاهده و اعتبارنامه ورود نامرئی پدید می‌آورد. مسیر مخزن را در نمایه بخوانید، نه مسیر آن پنجره‌ای که تصادفی باز شد.
عملیات کلید را بدون حدس زدن PIN بیازمایید
وقتی انتخاب روشن شد، پرسش این است که آیا کارت امضا را انجام می‌دهد. ویندوز برای رسیدن به کلید خصوصی به ارائه‌دهنده کارت پشتیبانی‌شده یا درایور کوچک نیاز دارد، و دستگاه قواعد PIN و حضور خود را بر عملیات اعمال می‌کند. کارتی که برای هر امضا نیاز به لمس دارد با کارتی که تأییدی را برای یک نشست ذخیره می‌کند متفاوت رفتار می‌کند، و هر دو پیکربندی‌های مشروعی هستند که زمان ظهور پرسش را تغییر می‌دهند. همین تفاوت ورودی را توضیح می‌دهد که با جاگذاری تازه موفق می‌شود و پس از بازگشت از تعلیق شکست می‌خورد، بدون آنکه هیچ گواهی‌ای نادرست باشد.
certutil.exe -scinfo
certutil.exe -store -user My
Get-WinEvent -LogName Application -MaxEvents 40 | Where-Object ProviderName -like '*Ras*'فرمان نخست کارت را فهرست می‌کند و وضعیت خواننده و ارائه‌دهنده را گزارش می‌دهد، که در راهنمای مایکروسافت برای اشکال‌زدایی کارت هوشمند مستند شده است. فرمان دوم فهرست می‌کند که بافت کاربر واقعاً چه می‌بیند. هیچ‌کدام احراز هویت موفق را اثبات نمی‌کند؛ هر دو جاهایی را که متوقف شده محدود می‌کنند.
PIN را حدس نزنید. کارت‌ها محدودیت تلاش دوباره را اعمال می‌کنند و چند تلاش خوش‌بینانه یک مشکل مجوز را به اعتبارنامه قفل‌شده‌ای تبدیل می‌کند که به بازیابی اداری نیاز دارد. اگر امضای محلی شکست خورد، وضعیت ارائه‌دهنده و وضعیت کارت را ثبت کنید به‌جای آزمودن حالت‌های مختلف. تلاش را یک بار با همان نمایه، همان گواهی و مسیر خواننده شناخته‌شده سالم تکرار کنید، سپس دو ثبت را مقایسه کنید؛ تغییر چند متغیر هم‌زمان یک روایت می‌سازد نه یک نتیجه.
دو طرف دست‌دهی را بخوانید
امضای کامل‌شده هنوز پذیرش نیست. سرور احراز هویت باید زنجیره را بپذیرد، ابطال را بررسی کند، هویت را بر پایه قواعد کنونی خود نگاشت کند و درخواست را مجاز بداند؛ کلاینت نیز باید گواهی سرور را همان‌گونه که نمایه می‌خواهد اعتبارسنجی کند. هشدار TLS که سرور تولید می‌کند در گزارش کلاینت مانند هشداری دیده می‌شود که به‌صورت محلی تولید شده است، به همین دلیل سمت صادرکننده از متن هشدار مهم‌تر است.
رویدادهای ویندوز و رویدادهای سمت سرور را با مهرهای زمانی هم‌تراز جمع کنید، سپس مشخص کنید کدام سمت نخستین شکست را تولید کرده است. RFC 5216 گام اثبات مالکیت را در EAP-TLS توصیف می‌کند و یک هشدار عمومی دست‌دهی به‌تنهایی علت محلی مربوط به کلید را نام نمی‌برد. مقایسه مهرهای زمانی است که دو گزارش را به یک توالی تبدیل می‌کند.
مرزها را در گزارش روشن نگه دارید
گزارش را به‌صورت چهار مرحله با یک حکم برای هرکدام بنویسید: کدام نمایه و بافت اجرا شد، ویندوز کدام گواهی را انتخاب کرد، آیا کارت امضا کرد و سرور چه تصمیمی گرفت. این ساختار گام بعدی را آشکار می‌کند و تعمیر رایج خاموش کردن اعتبارسنجی برای گذر از مرحله‌ای که هیچ‌کس آن را شناسایی نکرده جلوگیری می‌کند.
گواهی نرم‌افزاری به‌عنوان مقایسه موقت آزمون مشروع مدیر است، اما مدل اعتبارنامه و تضمین را تغییر می‌دهد، پس جای آن در تغییری تأییدشده است نه در یک راه‌حل موقت خاموش در محیط تولید. همین انضباط برای تلاش‌های PIN و برای صدور دوباره اعتبارنامه‌ها پیش از شناخته شدن مرحله شکست‌خورده صدق می‌کند. کارت جایگزینی که به همان شکل شکست می‌خورد شاهد گران‌قیمتی است بر اینکه مشکل هرگز روی کارت نبوده است.