Чи можна довіряти сертифікату у Windows, не довіряючи його кореневому CA?


14

Чи можна змусити Windows довіряти сертифікату, не довіряючи йому кореневому CA як довіреному кореневому CA?

скажіть, у мене є такий ланцюжок сертифікатів,

Dept-Root-CA
Dept-Intermediate-1
Server-Certificate

Я хочу довіряти Сертифікату сервера, але не хочу довіряти Dept-Root-CA, оскільки тоді він міг би підписати будь-який сертифікат, і мої сервери будуть йому довіряти. Тільки тому, що я готовий довіряти сертифікат серверного сертифіката для конкретної операції, не означає, що я готовий вірити, що Dept-Root-CA був належним чином захищений.

Спасибі


Чому саме ви хочете довіряти цьому? HTTPS? Або якась інша річ? Там є способи про те , що ви хочете прийняти один сертифікат без приймати що - небудь ще з кореневого центру сертифікації, але це залежить від того, що ви робите. (Ви все одно отримаєте помилки, якщо спробуєте перевірити сертифікат)
— Марк Хендерсон

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

Відповіді:


5

Ні. Поки в сертифікаті написано "Видано: xxx", ви також повинні довіряти xxx, аж до ланцюга. Якщо це сертифікат самопідписаний, його можна помістити в магазин Trusted Root CAs, а оскільки він виданий та виданий тим самим об'єктом, то йому слід довіряти.

Але ні, це взагалі неможливо або доцільно повністю обійти всю мету безпеки на основі сертифікатів.


6
Я цього боявся. Я б не назвав це обхідним шляхом. Тільки тому, що я хочу, щоб захищений канал спілкувався з машиною в іншій організаційній групі, не означає, що я хочу довіряти їхньому ЦА.
— bkr

Так ... але CA підписало цю програму, і без цього сертифікату CA інший кінець може просто продовжувати змінювати свій сертифікат.
— SpacemanSpiff

6
Я не впевнений, що розумію, що ти кажеш. Хочу прямо довірити їх сертифікату. Якби це було змінено, мені хотілося б знову довіритися цьому. Я в основному хочу, щоб модель довіри сертифікатів, як це є у Firefox. У Firefox, якщо cert не є дійсним у існуючих довірених CA, ви можете все-таки довіряти цьому - якщо він зміниться, вам доведеться довіряти новому сертифікату, оскільки йому явно не довіряли.
— bkr

3
just keep changing their certificateЯкби віддалений кінець змінив їхню частину, він не збігається з тим, який ви зберегли. Якщо ви ігноруєте весь бізнес з CA, чи не просто ви ставитесь до нього, як до ключів хоста SSH.
— Зоредаче

6
реально вони змінюватимуть її лише раз на 2 роки. продукт MS, який я використовую, вимагає з'єднання бути захищеним через https. тож йому треба довіряти. тому що він підписаний з їх CA, я повинен був би довіряти їх CA - я не хочу цього робити, тому що це дозволило б їм підробляти будь-який сертифікат на моєму сервері, на відміну від дозволу їм обмежувати взаємодію з конкретним іменем хоста.
— bkr

5

Ну .... Ви могли захопити цю інформацію про довіру іншим способом.

Це, на жаль, трохи складніше.

Створіть свій власний офіційний центр, а потім створіть власного емітента крос-підпису для Dept-Intermediate-1 (або Dept-Root-CA), підписавши його сертифікат у вашому ЦА, можливо, додавши обмеження домену. Якщо "справжній" Dep-Intermediate-1 вимкнено (бажано) або невідомий, Windows замість цього використовуватиме вашу мережу довіри.

Дивіться мою іншу відповідь тут: Обмежте кореневий сертифікат домену

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

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


Це цікаво. Мені доведеться знайти деякий час, щоб спробувати працювати через цей процес і подивитися, чи зможу я змусити його працювати.
— bkr
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.