رمز عبور درست VPN جایگزین گواهی مفقود نمی‌شود

اعتبارنامه‌ها درست هستند، نمایه بی‌دردسر وارد می‌شود و اتصال هنوز پیش از تکمیل احراز هویت شکست می‌خورد. در Windows ممکن است پیام خطای 798 باشد، درباره گواهی‌ای که برای روش EAP پیدا نشد. در OpenVPN گزارش مشتری یک دست‌دهی TLS را نشان می‌دهد که هرگز سرور را راضی نمی‌کند. هر دو همان شیء مفقود را توصیف می‌کنند: گواهی مشتری که قرار بود مشتری ارائه دهد.

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

رمز عبور هرگز مشکل نبود

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

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

مخزن مشتری باید چه چیزی داشته باشد

دو شیء درگیر است. گواهی مشتری باید برای کاربری که مشتری VPN را اجرا می‌کند همراه با کلید خصوصی‌اش نصب شود و ریشه صادرکننده باید مورد اعتماد باشد. فایل .cer فقط گواهی عمومی را در خود دارد، بنابراین به‌تنهایی نمی‌تواند چیزی را احراز هویت کند. در مدیر گواهی Windows، هویت مشتری در مخزن شخصی کاربر جاری و ریشه در مخزن ریشه‌های مورد اعتماد قرار می‌گیرد.

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

دو محصول، همان اعتبارنامه مفقود

سرورهای OpenVPN به‌طور پیش‌فرض گواهی مشتری می‌خواهند. افزودن auth-user-pass به مشتری نام کاربری و رمز عبور می‌فرستد و دست‌دهی TLS هنوز گواهی می‌خواهد، پس رمز عبور تنها نمی‌تواند اتصال را تحت verify-client-cert require کامل کند. سرور را می‌توان طوری تنظیم کرد که هیچ‌چیز نخواهد، که رمز عبور را تنها اعتبارنامه مشتری می‌کند و کاهش واقعی در قدرت است. یک اسکریپت shell پشت auth-user-pass-verify می‌تواند اعتبارنامه‌ها را اعتبارسنجی کند و نیازمند فعال بودن اجرای اسکریپت است، که آن را طراحی پرخطرتری از یک بک‌اند احراز هویت درست می‌کند.

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

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

وسوسه آن است که تأیید را شل کنید تا پیام ناپدید شود. این کار کنترلی را که داشت کارش را می‌کرد حذف می‌کند و اتصالی باقی می‌گذارد که دیگر آنچه ادعا می‌کند را اثبات نمی‌کند. اگر دروازه به‌تازگی ریشه‌اش را عوض کرده است، به‌جای ویرایش نمایه، بسته مشتری را دوباره بارگیری کنید، زیرا بسته قدیمی ممکن است هنوز ریشه پیشین را داشته باشد. اگر گزینه احراز هویت با گواهی در ویرایشگر نمایه نیست، ممکن است نسخه نصب‌شده Windows آن روش را ارائه نکند؛ به‌جای ویرایش دستی XML، سیستم را به‌روزرسانی کنید.

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

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