Чи можна довіряти сертифікату у 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.