هدف گواهی پشتیبانی‌نشده: چرا CA میانی شکست می‌خورد

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

کدام گواهی را تأییدکننده واقعاً رد کرد

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

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

openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage

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

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

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

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

EKU غایب، EKU محدودکننده نیست

RFC 5280 افزونه کاربرد گسترده کلید را اختیاری می‌کند و در صورت وجود، محدودکننده. بنابراین گواهی CA بدون این افزونه به احراز هویت سرور «نه» نگفته است، در حالی که گواهی‌ای که تنها هدفی نامرتبط را فهرست می‌کند چیزی بسیار مشخص گفته است. برخورد با این دو حالت به‌عنوان هم‌ارز، تشخیص نادرست و بدتر از آن، تعمیر نادرست به بار می‌آورد. این تمایز همچنین توضیح می‌دهد چرا دو مرجعی که در یک کنسول شبیه هم به نظر می‌رسند، در یک زنجیره کاملاً متفاوت رفتار می‌کنند.

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

پیش از صدور دوباره، شکست را برون‌خط بازتولید کنید

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

openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem

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

سیاست صدور را اصلاح کنید، نه فراخوان تأیید را

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

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