OpenVPN verify-x509-name: تفاوت subject و name و name-prefix

ابتدا نوع تطبیق را بخوانید و بعد متن را: یک verify-x509-name دستور می‌تواند درست به نظر برسد و با این حال گواهی‌ای را بپذیرد که قصد اعتماد به آن را نداشتید. دو خط با متن انتظاری یکسان اما نوع‌های متفاوت، دو شرط متفاوت‌اند. اول نوع را بخوانید، بعد متن را. دستور را یک شرط دیگر روی اتصال بدانید، نه کل بررسی.

این گزینه در واقع چه چیزی را تأیید می‌کند

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

این با اعتبارسنجی نام میزبان که مرورگر انجام می‌دهد نیز فرق دارد. مرورگر نام‌ها را بر اساس قواعد پشته TLS خود با نام‌های جایگزین subject تطبیق می‌دهد، در حالی که OpenVPN یک فیلد گواهی را با نوعی که انتخاب کرده‌اید مقایسه می‌کند. به همین دلیل چسباندن نام میزبان به سبک مرورگر در دستور می‌تواند ناسازگاری ایجاد کند، حتی وقتی گواهی واقعاً سرویس را پوشش می‌دهد.

subject: تمام نام تمایزی، حرف به حرف

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

این سخت‌گیری در میان تمدیدها شکننده است. CA ای که ویژگی‌ها را بازآرایی می‌کند، فیلد اضافه‌ای درج می‌کند یا شیوه escape یک مقدار را تغییر می‌دهد، برای همان دستگاه رشته جدیدی تولید می‌کند و دستوری که سال‌ها کار می‌کرد در صدور بعدی شروع به شکست می‌کند. نگه‌داشتن DN پذیرفته‌شده در سابقه تغییرات، تمدید بعدی را به یک تفاوت ساده تبدیل می‌کند. جایی که اپراتور DN کامل را منتشر می‌کند و شکل آن را تضمین می‌کند، subject انتخاب معقولی است؛ در جای دیگر نگه‌داشتن یک فیلد باریک‌تر آسان‌تر است.

name: یک فیلد، معمولاً نام مشترک

نوع name یک فیلد subject را مقایسه می‌کند. مگر اینکه پروفایل چیز دیگری بگوید، آن فیلد نام مشترک است و مقدار انتظاری دقیقاً همان فیلد است، نه DN پیرامون آن.

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

name-prefix: به‌طور طراحی گسترده، پس محدوده را تعیین کنید

یک انتظار از نوع name-prefix با ابتدای فیلد انتخاب‌شده مطابقت دارد. این برای یک طرح نام‌گذاری راحت و برای هر چیز مشترک خطرناک است.

اگر انتظار vpn.example باشد، هر دو vpn.example.com و vpn.example.net قبول می‌شدند، به شرطی که بقیه زنجیره قابل اعتماد باشد. گستردگی همان ویژگی است و در عین حال بخشی که باید مکتوب توجیه شود. پیشوند زمانی معقول است که CA و طرح نام‌گذاری از خودتان باشد، و زمانی بسیار ضعیف‌تر که یک CA عمومی در همان الگو صادر کند. اگر طرح به انعطاف نیاز دارد، آن را در CA محدود کنید نه با گستردن بررسی سمت کلاینت.

نوع را از روی شناسه انتخاب کنید، سپس آن را اثبات کنید

از هویتی که اپراتور در نظر دارد به عقب کار کنید. اگر DN کامل را منتشر می‌کند و آن را پایدار نگه می‌دارد، subject همین را بیان می‌کند. اگر سرویس را با نام مشترک نام می‌برد، از name استفاده کنید. اگر طرح نام‌گذاری دارد و تمام فضایش را می‌پذیرد، name-prefix این را صریح می‌گوید.

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

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