Можно ли доверять сертификату в Windows, не доверяя его корневому центру сертификации?

Можно ли заставить Windows доверять сертификату, не заставляя его доверять корневому ЦС в качестве доверенного корневого ЦС?

скажем, у меня есть следующая цепочка сертификатов,

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

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

Благодарность

windows ssl

— BKR
источник

За что именно вы хотите этому доверять? HTTPS? Или какая-то другая вещь? Там являются способы о том , что вы хотите принять один сертификат без принимать что - либо еще из корневого центра сертификации, но это зависит от того, что вы делаете. (Вы все равно будете получать ошибки, если попытаетесь подтвердить сертификат)

— Марк Хендерсон

По сути да. Если бы это был пользовательский код, то это не было бы проблемой - но это использует ADFS 2, и единственное, что я могу сделать в отношении того, как он обрабатывает сертификаты, это изменить то, как сервер доверяет этому сертификату. Есть и другие случаи, но это только текущий пример.

— BKR

Ответы:

Нет. Пока в сертификате написано «Выдано: ххх», вы также должны доверять ххх по всей цепочке. Если это самозаверяющий сертификат, его можно поместить в хранилище доверенных корневых центров сертификации, и, поскольку он выдается и выдается одним и тем же объектом, ему следует доверять.

Но нет, это вообще не выполнимо или не целесообразно, чтобы полностью обойти всю цель безопасности на основе сертификатов.

— Райан Райс
источник

Я боялся этого. Я бы не назвал это обходом, хотя. То, что я хочу, чтобы безопасный канал мог общаться с компьютером в другой организационной группе, не означает, что я хочу доверять их ЦС.

— БКР

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

— SpacemanSpiff

Я не уверен, что понимаю, что вы говорите. Я хочу явно доверять их сертификату. Если бы это было изменено, я хотел бы явно верить этому снова. Я в основном хочу модель доверия сертификата, как в Firefox. В Firefox, если сертификат недействителен в существующих доверенных центрах сертификации, вы можете в любом случае выбрать доверять ему - если он изменится, вам придется выбирать, доверять ли новому сертификату, поскольку он явно не был доверенным.

— 2013 г.

just keep changing their certificateЕсли удаленный конец изменил свой сертификат, он не будет соответствовать тому, который вы сохранили. Если вы игнорируете весь бизнес CA, разве вы не рассматриваете это как ключи хоста SSH?

— Зоредаче

реально они будут менять его только раз в 2 года. продукт MS, который я использую, требует, чтобы соединение было защищено через https. так что этому нужно доверять. потому что он подписан с их CA, я должен был бы доверять их CA - я не хочу этого делать, потому что это позволило бы им подделать любой сертификат для моего сервера, а не ограничить их взаимодействие с определенным именем хоста.

— BKR

Ну ... Вы могли бы получить эту информацию о доверии другим способом.

Это, к сожалению, немного сложно.

Создайте свой собственный CA, а затем создайте собственного эмитента перекрестной подписи для Dept-Intermediate-1 (или Dept-Root-CA), подписав свой сертификат с вашим CA, возможно, добавив ограничения домена. Если «настоящий» Dep-Intermediate-1 деактивирован (предпочтительно) или неизвестен, Windows вместо этого будет использовать вашу цепочку доверия.

Смотрите мой другой ответ здесь: ограничить корневой сертификат для домена

Именно так должны работать сертификаты, используя цифровые подписи для представления подтверждения владения ключом. Поскольку вы хотите утверждать, что сертификат и ключ принадлежат серверу, вы сами подписываете его под своей властью и затем указываете системе доверять вам.

В сертификате без CA-иерархии все еще много полезности , помимо того, что предоставляют ключи SSH; часть этого - ограничения на них. Использование ключа, сроки действия, информация об аннулировании, ограничения домена и т. Д. Другая часть - это идентифицирующая информация; сервер, которому принадлежит ключ, личность эмитента, применяемые политики CA, информация о хранилище ключей и т. д.

— davenpcj
источник

Это интересно. Мне нужно найти время, чтобы попытаться проработать этот процесс и посмотреть, смогу ли я заставить его работать.

— БКР