گواهی مشتری خودامضاشده؟ سرور VPN باز هم آن را رد می‌کند

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

اعتماد روی سرور زندگی می‌کند، نه در پروفایل شما

احراز هویت با گواهی یک مقایسه است. کلاینت گواهی را ارائه می‌کند؛ دروازه بررسی می‌کند که آیا یکی از CA‌های پیکربندی‌اش آن را امضا کرده است.

پروفایل شما فایل CA‌ای را نام می‌برد که کلاینت باید برای بررسی سرور استفاده کند. نمی‌تواند CA‌ای را نام ببرد که سرور باید برای بررسی شما استفاده کند. آن نیمه از پیکربندی مال شما نیست.

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

چرا گواهی خودامضاشده نمی‌تواند جایگزین شود

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

دروازه نمی‌پرسد آیا گواهی دروناً سازگار است. می‌پرسد آیا صادرکننده مورد اعتمادی آن را امضا کرده است.

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

مسیر CSR کلید خصوصی شما را نگه می‌دارد

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

openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"

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

سرویس‌های مدیریت‌شده اغلب CSR را رد می‌کنند و کل بسته را صادر می‌کنند. این معامله معقولی است وقتی همان ارائه‌دهنده از قبل تونل را پایان می‌دهد و CA را در اختیار دارد. نگهداری کلید با نگه داشتن آن بهتر نمی‌شود، چون ارائه‌دهنده می‌تواند هر زمان کلید تازه‌ای بسازد.

بسته‌ها وارد می‌شوند، نصب نمی‌شوند

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

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

بررسی‌هایی را اضافه کنید که اپراتور شاید جا انداخته باشد

پروفایل ساخته‌شده توسط روتر گاهی بررسی همتا را ندارد. remote-cert-tls server می‌خواهد که گواهی همتا هدف احراز هویت سرور را داشته باشد، تا گواهی کلاینت نتواند به‌عنوان سرور بازپخش شود. همان یک خط تغییری کوچک با توجیهی روشن است.

verify-x509-name جلوتر می‌رود وقتی اپراتور می‌تواند موضوع یا SAN مورد انتظار را نام ببرد. هر دو افزوده‌های کوچکی به پروفایل‌اند و هر دو قابل دفاع. پیش از وارد کردن، آنچه دریافت کرده‌اید را بررسی کنید.

openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt

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

یک بسته بخواهید: گواهی مرجع به‌صورت PEM، گواهی کلاینتی که آن مرجع امضا کرده، کلیدی که خودتان ساخته‌اید یا از کانالی رسیده که به آن اعتماد دارید، و نام دقیق سروری که گواهی باید ارائه دهد. تاریخ انقضا را در همان پیام یادداشت کنید، چون گواهی منقضی ماه‌ها بعد شبیه خرابی شبکه به نظر می‌رسد.