Назад | Перейти на главную страницу

«Подпись» CA с помощью openssl

Я довольно привык к созданию PKI, используемой для аутентификации x509 по какой-либо причине, причем проверка клиента SSL является основной причиной для этого. Я только начал баловаться OpenVPN (который, я полагаю, делает то же самое, что и Apache с сертификатом центра сертификации (CA))

У нас есть целый ряд поддоменов и приложений, которые в настоящее время представляют свои собственные самозаверяющие сертификаты. Мы устали принимать исключения в Chrome и думаем, что для наших клиентов это должно выглядеть довольно грубо, если наша адресная строка становится красной.

Для этого мне удобно купить подстановочный знак SSL. CN=*.example.com. Это не проблема.

Чего я, кажется, не могу узнать, так это:

  1. Можем ли мы подписать наш внутренний корень CA как дочерний для нашего сертификата с подстановочными знаками, чтобы установка этого сертификата на гостевые устройства / браузеры / что-либо еще не сообщала о ненадежном корне?
  2. Кроме того, с некоторой стороны, почему добавление подстановочного знака удваивает стоимость покупки сертификата?
  1. Нет - ограничения, наложенные на сертификат с подстановочными знаками, не позволят использовать его в качестве ЦС любым способом, формой или формой для предоставления доверия другому сертификату (или органу), находящемуся под вашим контролем. Проверьте поле x509 Basic Constraints; вероятно, он содержит CA:FALSE.

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

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

Можем ли мы подписать наш внутренний корень CA как дочерний элемент нашего подстановочного сертификата ...

Сертификат с подстановочными знаками может отображаться в сертификатах конечных объектов только в том случае, если все работает так, как предполагалось или ожидалось. И они будут отображаться только в сертификатах конечных объектов «нижнего уровня», таких как проверенный домен; а не сертификаты расширенной проверки «более высокого уровня».

Если все работает, как задумано или ожидается, сертификат конечного объекта будет отсутствовать. keyCertSign keyUsagecRLSign), поэтому он не сможет действовать как корень CA и закрепить цепочку доверия. Вы не сможете ничего скрепить сертификатом конечного объекта.

Это различие между разными уровнями или классами сертификатов затрагивается ниже, но мы рекомендуем вам прочитать две главы из книги Питера Гуттмана. Инженерная безопасность. В частности, см. Главы 1 и 8 (IIRC).

Центры сертификации могут подписывать другие центры сертификации (тут есть какие-то руки, пожалуйста, никаких камней). Это называется встречной подписью и используется для соединения различных PKI. Например, Федеральное управление США использует мосты, чтобы позволить казначейству использовать сертификаты государственного департамента (и т. Д.).

Мостовое соединение - это несколько иной вариант использования, чем тот, который используется в типичной модели браузера. В модели браузера не используются сертификаты с перекрестной подписью; скорее, сотни корневых и промежуточных сертификатов предустановлены и доверены для того же эффекта (и даже больше!).

Наконец, правило «Сертификаты EV не могут иметь подстановочных знаков» исходит из форумов CA-Browser (CA / B). У CA / B есть два руководства, которым следуют участвующие центры сертификации и браузеры, и правило взято из расширенных рекомендаций.

Из расширенного руководства, стр. 15:

9.2.2 Subject Alternative Name Extension

Certificate field: subjectAltName:dNSName

Required/Optional: Required

Contents: This extenstion MUST contain one or more host Domain Name(s)
owned or controlled by the Subject and to be associated with the Subject’s
server. Such server MAY be owned and operated by the Subject or another
entity (e.g., a hosting service). Wildcard certificates are not allowed
for EV Certificates. 

так что установка этого сертификата на гостевые устройства / браузеры / все, что угодно, ничего не говорит о ненадежном корне

Нет. Пользователь должен будет установить его как якорь доверия. Например, как «Trusted Certifcate» в хранилище сертификатов. Простое предоставление его как сертификата конечного объекта не должно иметь никакого эффекта.


Кроме того, с некоторой стороны, почему добавление подстановочного знака удваивает стоимость покупки сертификата?

Чтобы сохранить уровень прибыли.

Сертификаты расширенной проверки - это еще один трюк, используемый для восстановления уровней прибыли до времени до гонка ко дну разрушено доверие и прибыль. Взято из Питера Гуттмана Инженерная безопасность, стр. 63-64. (Гутман называет это «PKI мне сложнее»):

Введение ... так называемых сертификатов высокого уровня надежности или расширенной проверки (EV), которые позволяют центрам сертификации взимать за них больше, чем стандартные, - это просто случай округления вдвое большего числа подозреваемых - предположительно, кто-то будет впечатлен, но эффект от фишинга минимален, поскольку он не решает никаких проблем, которыми пользуются фишеры. В самом деле, циники сказали бы, что это была именно та проблема, которую сертификаты и центры сертификации должны были решить в первую очередь, и что сертификаты «высокой надежности» - это всего лишь способ вторичной оплаты существующей услуги. Несколько лет назад сертификаты все еще стоили несколько сотен долларов, но теперь, когда смещение базовой линии цен и качества сертификатов приблизилось к точке, где вы можете получить их за 9,95 долларов (или даже совсем бесплатно), крупным коммерческим центрам сертификации пришлось изобретать заново. сами, определив новый стандарт и убедив рынок вернуться к ценам, заплаченным в старые добрые времена.

Этот повторяющийся принцип дежавю можно увидеть, изучив заявление Verisign о практике сертификации (CPS), документ, который регулирует выпуск сертификатов. Требования безопасности в сертификате EV 2008 CPS (за исключением незначительных различий в юридическом языке, используемом для их выражения) практически идентичны требованиям для сертификатов класса 3, перечисленных в Verisign версии 1.0 CPS с 1996 года. Сертификаты EV просто откатывают часы до подход, который уже потерпел неудачу в первый раз, когда он был опробован в 1996 году, когда в качестве побочного эффекта был изменен сдвиг базовой линии и установлены цены 1996 года. Были даже предложения для своего рода подхода со скользящим окном к стоимости сертификата, при котором, поскольку неизбежная гонка за дно удешевляет эффективную ценность установленных классов сертификатов, они рассматриваются как все менее и менее эффективные со стороны программного обеспечения, которое их использует. ...