(Опубликовано в ServerFault вместо StackOverflow, потому что я чувствую, что это касается конфигурации ОС больше, чем программный код)
В настоящее время я отвечаю за обслуживание системы, которая подключается к стороннему веб-сервису. Для этого веб-сервиса требуются сертификаты аутентификации клиента, что достаточно справедливо, но сам веб-сервис защищен самозаверяющим сертификатом, созданным самостоятельно созданным корневым сертификатом центра сертификации - тем же корневым, который создает клиентские аутентификационные сертификаты.
Было бы достаточно просто добавить текущий сертификат службы в список известных доверенных и игнорировать самодельный сертификат полномочий, к сожалению, сертификат службы регулярно меняется, поэтому сертификат полномочий должен быть доверенным, чтобы приложение не сломалось, когда Сертификат службы обновлен.
Однако я (лично) не доверяю сертификату CA, основываясь на моем опыте работы с компанией, управляющей веб-сервисом - меня не удивит, если он попадет в Интернет, - и, к сожалению, сертификат CA не имеет никаких ограничений на использование ключей, это (хотя возможны внешние атаки MITM, хотя и удаленные, меня больше беспокоит утечка сертификата, используемого, например, для подписи кода).
Могу ли я сказать моему компьютеру (в настоящее время серверная коробка, но в будущем обычные клиентские настольные компьютеры) доверять ЦС, но только для заданного набора ключей и небольшого набора возможных имен субъектов (доменных имен) )?
В настоящее время сервер является Windows Server 2012 R2, но он может работать на компьютере с Linux - хотя все настольные компьютеры - это компьютеры с Windows.
Ответы:
Да, это возможно. В случае с Windows существует функция перекрестной сертификации или квалифицированного подчинения.
Идея заключается в том, что вы подписываете сертификат CA, выданный третьей стороной, в вашей среде. В результате удаленный сертификат SSL связывается с вашим собственным сертификатом корневого центра сертификации. Чтобы защитить себя от возможных поддельных сертификатов, вы реализуете
Name Constraintsрасширение сертификата, в котором вы указываете список допустимых имен. Если сторонний центр сертификации выпускает сертификат для любого другого имени (явно не указанного в расширении ограничения имени), он будет автоматически отклонен вашим поставщиком CryptoAPI.В дополнение к ограничениям имени, вы можете описать ограничение Расширенного использования ключей, определив
Application Policiesрасширение сертификата в перекрестном сертификате. Таким образом, ваш поставщик доверия будет успешно проверять только использование, указанное вApplication Policiesрасширении.Дополнительная информация: Планирование и реализация перекрестной сертификации и квалифицированного подчинения с использованием Windows Server 2003
PS Хотя статья написана для Windows Server 2003, она все еще применима к самой последней версии Windows Server.
источник