Чи може ланцюжок сертифікатів сервера перевизначити сховище довіри клієнта?

Браузер показує попередження про сертифікат на сайті, ланцюжок якого повний, і перший порив — виправити сервер. Зазвичай сервер подає саме те, що має. Клієнт вирішує, які якорі він приймає, і жодне розташування проміжних сертифікатів не може змінити це рішення з іншого кінця з’єднання. Ця межа пояснює більшість того, що виглядає як проблема із сертифікатом.

Перевірка виконується на клієнті, з якорями клієнта

Перевірка шляху бере подані сертифікати й будує ланцюжок до якоря довіри, який система перевірки вже має. RFC 5280 описує цю модель і поміщає вибір якоря в локальну реалізацію, а не на сервер. Програма може додати свою політику зверху: закріплений ключ, корпоративне сховище довіри, або суворішу перевірку особи. Список сертифікатів, який надсилає сервер, — це доказ, запропонований цьому процесу, а не вказівка йому.

Отже, повний ланцюжок доводить, що сервер має частини. Він не доводить, що клієнт їх прийме.

Щоб побачити, що сервер справді надсилає, виконайте openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts і порахуйте сертифікати у виводі. Неповний ланцюжок там — це виправлення на боці сервера. Повний ланцюжок переносить питання до клієнта та його якорів, де сервер не має голосу.

Що насправді змінює перевірка TLS

Пристрій перевірки завершує TLS-сеанс на боці клієнта й відкриває окремий сеанс до справжньої служби. Далі клієнт перевіряє сертифікат пристрою, який має ланцюжком вести до якоря, якому клієнт довіряє. Тому керовані пристрої отримують корінь перевірки через керування пристроями, і тому особистий пристрій без нього показує попередження.

Схема навмисна й локальна. Ніщо в ланцюжку початкового сервера не може змусити некерований браузер прийняти підмінену особу, і ніщо в ньому не заважає керованому пристрою це зробити.

Завершення VPN — це не розшифрування HTTPS

Рівень VPN переносить пакети між клієнтом і шлюзом. Його видалення або читання його конфігурації не розкриває HTTPS-навантаження всередині.

TLS-сеанс і далі відбувається між браузером і вебсервером із тими самими правилами перевірки, якщо щось явно його не завершує. Змішування двох рівнів породжує запит до адміністратора VPN надати сертифікат, хоча сертифікат належить проксі перевірки або самому сайту. Запитайте, який компонент подає сертифікат, перш ніж змінювати будь-яке сховище довіри.

Задайте очікування в компоненті, яким ви керуєте

Якщо ви керуєте програмою та її клієнтом, визначте разом очікувану ідентичність служби, прийнятних видавців і будь-яку вимогу закріплення або автентифікації клієнта. Плануйте оновлення й відновлення так, щоб законна зміна сертифіката не стала збоєм. Якщо ви керуєте лише публічним сервером, задокументуйте, яка автентифікація потрібна і які клієнтські середовища підтримуються. Надсилання бажаного ланцюжка не засвідчує пристрій стороннього.

На керованому обладнанні усувайте несумісність через власників програми й мережі. Вимкнення перевірки, додавання непоясненого кореня або спроба пережити політику перевірки не встановлюють потрібних довірчих відносин.

Перевіряйте результат на чистому профілі клієнта, а не на машині, де вже додано виняток. Це єдина перевірка, яка показує, що відчує новий пристрій.