Довіра ненадійного КА - Чи можу я обмежити те, як система довіряє їй?

(Опубліковано на ServerFault замість StackOverflow, оскільки я вважаю, що це стосується конфігурації ОС більше, ніж код програмування).

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

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

Однак я (особисто) не довіряю сертифіката CA на основі мого досвіду роботи з компанією, яка працює за веб-сервісом - це не здивувало б мене, якщо воно просочиться в Інтернет - і тривожно, що в сертінгу CA немає обмежень щодо використання ключів це (хоча зовнішні атаки MITM - це можливість, хоч і віддалена, я більше стурбований протікаючим сертифікатом, наприклад, для підписання коду).

Чи можна мені сказати моєму комп’ютеру (наразі серверну коробку, але в майбутньому звичайні скриньки клієнтів для настільних ПК) довіряти CA, але лише для заданого набору ключових звичок та невеликого набору можливих імен предметів (доменних імен )?

На даний момент сервером є Windows Server 2012 R2, але він може працювати на вікні Linux - хоча настільні машини - це всі вікна Windows.

ssl-certificate certificate-authority x509

— Дай
джерело

Принаймні, у Linux багато додатків мають можливість вказати місце розташування сертифікатів рівних сертифікатів CA, тому ви можете обмежити сферу дії цього CA лише програмою, що використовує його. Відповідь @CryptoGuy також буде працювати і в Linux, в цьому немає нічого конкретного Windows.

— Edheldil

@Edheldil: Хоча це специфічно для впровадження - наприклад, Windows підтримує обмеження імен X.509 набагато довше, ніж, наприклад, NSS або GnuTLS.

— grawity

Ваша система підключається до цієї сторонньої послуги; чи може конфігурація клієнтського коду у вашій системі довіряти ЦС служби таким чином, що це робиться саме для цього клієнтського коду , а не для всієї вашої системи?

— Касталья

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

— Дай

Так, можливо. У випадку з Windows існує функція під назвою перехресна сертифікація або кваліфікована підпорядкованість.

Ідея полягає в тому, щоб ви підписали сертифікат сертифікату, який видає сторонніх, у вашому оточенні. У результаті віддалений сертифікат SSL прив'язується до вашого власного кореневого сертифіката CA. Щоб убезпечити себе від можливих шахрайських сертифікатів, ви реалізуєте Name Constraintsрозширення сертифіката, де вказуєте список прийнятних імен. Якщо сертифікат третьої сторони видасть сертифікат на будь-яке інше ім’я (не вказане прямо в розширенні обмеження імені), він буде автоматично відхилений постачальником CryptoAPI.

Окрім обмежень для імен, ви можете описати обмеження в поліпшених ключових ключових словах, визначивши Application Policiesрозширення сертифікату в крос-сертифікаті. Отже, ваш постачальник довіри успішно перевірить лише звичаї, зазначені в Application Policiesрозширенні.

Додаткова інформація: Планування та впровадження перехресної сертифікації та кваліфікованого підпорядкування за допомогою Windows Server 2003

ps, хоча стаття написана проти Windows Server 2003, ця стаття все ще стосується останньої версії Windows Server.

— Crypt32
джерело