Действительно ли возможно ограничить использование корневого сертификата домену
Мой клиент использует сам подписанный сертификат для рвения. Чтобы смочь работать, я должен установить корневой сертификат, они раньше подписывали сертификат.
Действительно ли возможно настроить корневой сертификат, таким образом, это только проверяет к одному домену?
Эмпирическое правило:
Нет , подразумевается, что доверие к сертификату CA клиента - это доверие к каждому сертификату, подписанному этим CA.
Я не знаю ни одного приложения / библиотеки, в котором есть простой вариант, позволяющий вам, как конечному пользователю, выбирать, доверять ли вы своим клиентам или любому другому сертификату CA только для определенных (под) доменов, т.е. только для * .example.com и * .example.org и ничего больше.
Mozilla озабочена аналогичными проблемами в отношении доверенных в настоящее время ЦС, спонсируемых государством, как открытая точка внимания и, например, Chrome ] имеет встроенные дополнительные проверки для доступа к сайтам Google, именно поэтому мошеннический сертификат * .google.com и взлом ЦС Diginotar стали общедоступными.
Но даже если вы не доверяете ЦС, вы все равно можете импортировать / доверять определенному сертификату сервера, подписанному этим ЦС, что предотвратит предупреждения SSL для имен хостов в этом сертификате. Это должно заставить ваше приложение работать без ошибок или жалоб.
Исключения:
Очень редко используемый вариант стандарта PKI X.509v3 - это расширение Name Constraints , которое позволяет сертификату CA содержать белый - и черные списки шаблонов доменных имен, для которых разрешено выдавать сертификаты.
Возможно, вам повезет, и ваш заказчик воздержался от настройки инфраструктуры PKI и включил это ограничение Name в свой сертификат CA. Затем вы можете напрямую импортировать их сертификат CA и знать, что он может проверять только ограниченный диапазон доменных имен.
@CryptoGuy дал здесь довольно хороший ответ, но я хотел его расширить.
Перефразируя:
Вы можете ограничить сторонний CA доверять сертификатам (от этого CA) выдается на список имен, который вы хотите. Даже если сторонний CA не имеет расширения Name Constraints, их можно применить, используя собственный внутренний сервер CA посредством перекрестной сертификации.Хитрость заключается в том, что вы подписываете сторонний ЦС, используя свой внутренний ЦС.
листовой сертификат SSL -> перекрестный сертификат -> ваш сертификат ЦС -> ваш внутренний корневой сертификат.
И вот как это работает (используя ЦС командной строки OpenSSL)
Создание простого ЦС
openssl req -new -x509 -days 3650 -newkey rsa:2048 -sha256 -out root-ca.crt -keyout root-ca.key -subj "/CN=My Root CA"
Вы можете пропустить создание промежуточного ЦС
Создание запроса промежуточного ЦС с ограничениями имени.
openssl req -new -days 3650 -newkey rsa:2048 -out domain-ca.req -sha256 -keyout domain-ca.key -config ossl_domain_com.cfg
С этим в ossl_domain_com.cfg файл:
[ req ]
prompt=no
distinguished_name=req_distinguished_name
req_extensions=domain_ca
[ req_distinguished_name ]
CN=somedomain.com trust CA
[ domain_ca ]
basicConstraints=critical,CA:true,pathlen:1
nameConstraints=critical,permitted;DNS:.somedomain.com
Затем подпишите этот промежуточный ЦС домена своим ЦС.
openssl x509 -req -in domain-ca.req -CA root-ca.crt -CAkey root-ca.key -sha256 -set_serial 1 -out domain-ca.crt -extensions domain_ca -extfile ossl_domain_com.cfg
Если вы пропустили создание промежуточного ЦС, используйте корневой ЦС для подписи
Теперь повторно подпишите ЦС исходного домена под своими полномочиями, используя их сертификат. Здесь вы можете добавить расширения CA.
openssl x509 -in third_party_ca.crt -CA domain-ca.crt -CAkey domain-ca.key -set_serial 47 -sha256 -extensions domain_ca -extfile ossl_domain_com.cfg -out domain-cross-ca.crt
Возможно, вам понадобится использовать аргумент -x509-to-req , чтобы создать запрос, который вы должны подписать точно так же, как и промежуточный выше.
Теперь добавьте корневой CA, промежуточный CA и домен-кросс-CA в базу данных доверия вашего браузера.