آیا زنجیرهٔ گواهی سرور می‌تواند مخزن اعتماد کلاینت را نادیده بگیرد؟
زنجیرهٔ کامل یک شاهد است، نه یک دستور. اعتبارسنجی در کلاینت و با لنگرهای خودش انجام می‌شود، پس هیچ سروری نمی‌تواند تصمیم اعتماد را تحمیل کند.
مرورگر روی سایتی که زنجیره‌اش کامل است هشدار گواهی نشان می‌دهد، و نخستین واکنش اصلاح سرور است. معمولاً سرور دقیقاً همان چیزی را ارائه می‌دهد که باید. کلاینت تصمیم می‌گیرد کدام لنگرها را می‌پذیرد، و هیچ چیدمانی از گواهی‌های میانی نمی‌تواند آن تصمیم را از سوی دیگر اتصال تغییر دهد. همین مرز بیشتر آنچه را که شبیه مشکل گواهی به نظر می‌رسد توضیح می‌دهد.
اعتبارسنجی در کلاینت و با لنگرهای کلاینت اجرا می‌شود
اعتبارسنجی مسیر، گواهی‌های ارائه‌شده را می‌گیرد و زنجیره‌ای تا یک لنگر اعتماد می‌سازد که سامانهٔ اعتبارسنج از پیش دارد. RFC 5280 همان مدل را توصیف می‌کند و انتخاب لنگر را به پیاده‌سازی محلی می‌سپارد، نه به سرور. یک برنامه می‌تواند سیاست خودش را روی آن بیفزاید: یک کلید سنجاق‌شده، یک مخزن اعتماد سازمانی، یا یک بررسی هویت سخت‌گیرانه‌تر. فهرست گواهی‌هایی که سرور می‌فرستد شاهدی است که به آن فرایند عرضه می‌شود، هرگز دستوری به آن نیست.
پس زنجیرهٔ کامل ثابت می‌کند که قطعه‌ها را سرور دارد. ثابت نمی‌کند که کلاینت آن‌ها را خواهد پذیرفت.
برای دیدن آنچه سرور واقعاً می‌فرستد، اجرا کنید openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts و گواهی‌های خروجی را بشمارید. زنجیرهٔ ناقص در آنجا اصلاحی در سمت سرور است. زنجیرهٔ کامل پرسش را به کلاینت و لنگرهایش منتقل می‌کند، جایی که سرور هیچ رأیی ندارد.
بازرسی TLS در واقع چه چیزی را تغییر می‌دهد
یک دستگاه بازرسی نشست TLS سمت کلاینت را پایان می‌دهد و نشستی جداگانه به سرویس واقعی باز می‌کند. سپس کلاینت گواهی دستگاه را اعتبارسنجی می‌کند، که باید به لنگری که کلاینت به آن اعتماد دارد متصل شود. به همین دلیل دستگاه‌های مدیریت‌شده ریشهٔ بازرسی را از طریق مدیریت دستگاه دریافت می‌کنند، و به همین دلیل دستگاه شخصی بدون آن هشدار نشان می‌دهد.
این چیدمان عمدی و محلی است. هیچ چیز در زنجیرهٔ سرور اصلی نمی‌تواند مرورگر مدیریت‌نشده را به پذیرش هویت جانشین مجبور کند، و هیچ چیز در آن مانع دستگاه مدیریت‌شده از این کار نمی‌شود.
پایان‌دادن VPN رمزگشایی HTTPS نیست
لایهٔ VPN بسته‌ها را میان کلاینت و دروازه حمل می‌کند. برداشتن آن، یا خواندن پیکربندی‌اش، بار HTTPS درون را آشکار نمی‌کند.
نشست TLS همچنان میان مرورگر و وب‌سرور جریان دارد، با همان قواعد اعتبارسنجی، مگر اینکه چیزی صریحاً آن را پایان دهد. اشتباه گرفتن دو لایه به درخواستی از مدیر VPN برای تأمین گواهی می‌انجامد، در حالی که گواهی موردبحث به یک پروکسی بازرسی یا به خود سایت تعلق دارد. پیش از تغییر هر مخزن اعتمادی بپرسید کدام مؤلفه گواهی را ارائه می‌دهد.
انتظارات را در مؤلفه‌ای که کنترل می‌کنید تعیین کنید
اگر برنامه و کلاینتش را اداره می‌کنید، هویت سرویس مورد انتظار، صادرکنندگان پذیرفته‌شده و هر الزام سنجاق‌کردن یا احراز هویت کلاینت را با هم تعریف کنید. تمدید و بازیابی را طوری برنامه‌ریزی کنید که تغییر مشروع گواهی به قطعی تبدیل نشود. اگر فقط سرور عمومی را اداره می‌کنید، مستند کنید چه احراز هویتی می‌خواهید و کدام محیط‌های کلاینت را پشتیبانی می‌کنید. فرستادن زنجیرهٔ ترجیحی، دستگاه یک غریبه را تصدیق نمی‌کند.
روی تجهیزات مدیریت‌شده، ناسازگاری را از طریق مالکان برنامه و شبکه حل کنید. غیرفعال‌کردن اعتبارسنجی، افزودن ریشهٔ بی‌توضیح، یا تلاش برای پشت سر گذاشتن سیاست بازرسی، رابطهٔ همتای موردنظر را برقرار نمی‌کند.
نتیجه را روی نمایهٔ کلاینت تمیز آزمایش کنید، نه روی ماشینی که از قبل استثنا به آن افزوده شده است. این تنها بررسی‌ای است که نشان می‌دهد دستگاه جدید چه تجربه‌ای خواهد داشت.