Можно ли ограничить использование корневого сертификата доменом


28

Мой клиент использует самозаверяющий сертификат для приложения для работы. Чтобы иметь возможность работать, я должен установить корневой сертификат, который они использовали для подписи сертификата.

Можно ли настроить корневой сертификат, чтобы он действовал только для одного домена?


Это может быть только я, но мне неясно, что вы на самом деле спрашиваете. Какое конечное состояние вы пытаетесь достичь? Если вы импортируете их корневой сертификат в доверие контроллеров домена, то только системы в этом домене смогут проверить его ...
Gravy

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

у вас есть внутренний сервер CA?
Crypt32

1
CA может ограничить себя определенными доменами с ограничениями имени , но применение ограничений задним числом к ​​чужому CA - это другой вопрос.
Мэтт Нордхофф

3
нет никакой разницы. Вы также можете применить ограничения имени к стороннему ЦС. Вы просто подписываете сертификат стороннего корневого CA, используя свой частный CA, и публикуете сгенерированный перекрестный сертификат. В этом случае иностранная сеть переходит в вашу частную сеть через ограниченный перекрестный сертификат.
Crypt32

Ответы:


24

Как правило большого пальца:

Нет , доверие к сертификату CA клиента означает доверие к каждому сертификату, подписанному этим CA.

Я не знаю каких-либо приложений / библиотек, в которых есть простой вариант, который позволяет вам как конечному пользователю выбрать, что вы будете доверять своим клиентам или любому другому сертификату CA только для определенных (суб) доменов, то есть только для *. example.com и * .example.org и ничего больше.

Mozilla испытывает аналогичные опасения по поводу того, что в настоящее время доверенные правительственные центры сертификации выступают в качестве открытой точки внимания, и, например, в Chrome встроены дополнительные проверки для доступа к сайтам Google. Именно так стали известны публичный сертификат * .google.com и компрометация Diginotar CA ,

Но даже если вы не доверяете ЦС, вы все равно можете импортировать / доверять определенному сертификату сервера, подписанному этим ЦС, что предотвратит предупреждения SSL для имен хостов в этом сертификате. Это должно заставить ваше приложение работать без ошибок и жалоб.

Исключения:

Очень недопустимым вариантом стандарта PKI X.509v3 является расширение « Ограничения имен» , которое позволяет сертификату CA содержать белые и черные списки шаблонов доменных имен, для которых разрешено выдавать сертификаты.

Возможно, вам повезет, и ваш клиент сдержался, когда они настроили свою инфраструктуру PKI и включили это ограничение имени в свой сертификат CA. Затем вы можете импортировать их сертификат CA напрямую и знать, что он может проверять только ограниченный диапазон доменных имен.


2
@CryptoGuy: внутренний ЦС также может выдавать сертификаты для внешних доменов. После того, как вы доверяете своему внутренний ЦС нет ограничений , так что только сертификаты на собственном домене (каталог или DNS Active) example.comили *.ad.example.com являются действительными. Ваш внутренний ЦС также может выдавать сертификаты, *.example.bankпозволяющие проводить приятную атаку «посредник» и отслеживать ваши учетные данные в онлайн-банке.
HBruijn

1
Ну, «все» не совсем точно. Есть такие вещи, как списки отзыва сертификатов. Но это не меняет суть.
Бен Фойгт

1
извините, вы снова ошиблись. Вы можете ограничить сторонний ЦС доверенными сертификатами (от этого ЦС), выданными по желаемому списку имен. Что касается вашего собственного внутреннего CA, я полагаю, доверие не вызывает сомнений. Если вы не доверяете своему собственному центру сертификации, значит, что-то не так с вашими ИТ Я хочу сказать, что, имея частный CA, OP может установить частичное доверие к стороннему CA (ограничивая имена, которым они доверяют).
Crypt32

3
К вашему отредактированному сообщению: даже если сторонний CA не имеет расширения Name Constraints, их можно применить, используя собственный внутренний сервер CA через перекрестную сертификацию. В этом случае цепочка сертификатов будет выглядеть следующим образом: лист SSL-сертификат -> перекрестный сертификат -> ваш сертификат CA -> ваш внутренний корневой сертификат. Хитрость заключается в том, что вы подписываете сторонний CA, используя свой внутренний CA. И кросс-сертификат будет иметь все необходимые ограничения.
Crypt32

1
CryptoGuy говорит, что это возможно, но найти детали реализации сложно. Как насчет ответа, описывающего, как это можно сделать? И, возможно, обсуждение того, какие платформы поддерживают nameConstraints.
Йорфус

17

У @CryptoGuy был довольно хороший ответ, но я хотел бы остановиться на нем.

Перефразировать:

Вы можете ограничить сторонний ЦС доверенными сертификатами (от этого ЦС), выданными по желаемому списку имен. Даже если сторонний CA не имеет расширения Name Constraints, их можно применить, используя собственный внутренний сервер CA через перекрестную сертификацию. Хитрость заключается в том, что вы подписываете сторонний CA, используя свой внутренний CA.

лист SSL-сертификат -> перекрестный сертификат -> ваш сертификат CA -> ваш внутренний корневой сертификат.

И вот как вы это делаете (используя командную строку OpenSSL CA)

Создать простой CA

openssl req -new -x509 -days 3650 -newkey rsa:2048 -sha256 -out root-ca.crt -keyout root-ca.key -subj "/CN=My Root CA"

Вы можете пропустить создание промежуточного CA

Создайте промежуточный запрос 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

Затем подпишите этот промежуточный домен CA с вашим CA.

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 для подписи

Теперь заново подпишите ЦС исходного домена под вашим полномочием, используя их сертификат. Вы можете добавить расширения 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 в базу данных доверия вашего браузера.


2
MacOS не поддерживает nameConstraints. Просто FIY для тех, кто работает над именем внутреннего CA. security.stackexchange.com/questions/95600/… archive.is/6Clgb
jorfus

Вопрос: каков статус этого решения? В каких системах он работает в настоящее время (2018)? // Я хотел этого каждый раз, когда мне пришлось установить еще один сертификат собственной подписи компании; и каждый раз, когда я думаю о почтовом отделении Гонконга или Symantec. // Я думаю, что мне может быть все равно, что никто не реализует описанное сужение, если только оно случайно не реализует расширение.
Крейзи Глеу

@KrazyGlew У меня есть командный файл, и я до сих пор использую его регулярно. Иногда мне приходится переиздавать промежуточные сертификаты по истечении или вращению, так что это немного больше ручного, но это не было проблемой. Я иногда сталкиваюсь с сайтами, управляемыми властями, которым мой браузер не доверяет из-за использования другого промежуточного органа или добавленного ими дополнительного доменного имени, которому мое доверять не может.
davenpcj

2
Я только что успешно использовал это, спасибо. Он прекрасно работает без промежуточного сертификата, есть ли преимущество в его использовании? Кроме того, basicConstraintsстрока в файле конфигурации, по-видимому, приводит к тому, что расширение ограничений включается в сертификат дважды, что заставляет Firefox отклонять сертификат с загадочным сообщением об ошибке. Я думаю, что это может быть безопасно удалено.
wrtlprnft

Я получаю сообщение об ошибке на последний шаг: error with certificate to be certified - should be self signed. Что это значит и как это решить? pastebin.ubuntu.com/p/QHhpQh2N6J
mymedia
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.