Разница между самозаверяющим ЦС и самозаверяющим сертификатом


81

Я не понимаю разницы между ключом CA и сертификатом. Разве ключ CA не является просто сертификатом? Позвольте мне попытаться прояснить ситуацию на примере.

У меня есть клиент и сервер. Я только пытаюсь проверить свое соединение с моим сервером и не пытаюсь установить доверие к другим, поэтому меня не волнует подписание с настоящим ЦС.

Вариант 1. Создайте самоподписанный ЦС ( ssCA ) и используйте его для подписания сертификата ( C ). Затем установить SSCA в корневом хранилище на моем клиенте и настроить мой сервер на использование сертификат C .

Вариант 2: Создайте самозаверяющий сертификат ( SSC ). Установите SSC в корневое хранилище ключей на моем клиенте. Настроить мой сервер на использование сертификата SSC .

Второй вариант кажется намного более простым. Должно ли это работать?

Ответы:


62

Оба варианта допустимы, вариант 2 проще.

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

Вариант 2 (самоподписание сертификата без ЦС) проще. Если вам нужен только один сертификат, этого достаточно. Установите его в хранилища ключей ваших клиентов, и все готово. Но когда вам нужен второй сертификат, вам нужно снова установить его на всех клиентах.

Вот ссылка с дополнительной информацией: Создание центров сертификации и самоподписанных сертификатов SSL.


Если центр сертификации подписывает сертификат, могу ли я просто доверять сгенерированному сертификату ( в данном случае C ), зная, что мне просто нужно доверять каждому сгенерированному сертификату, а не одному сертификату, который исходит от центра сертификации?
ivandov

65

Во-первых, что касается различия между ключом и сертификатом (в отношении «ключа CA»), при разговоре о сертификатах открытого ключа (обычно X.509) используются 3 части: открытый ключ, закрытый ключ и сертификат. Открытый ключ и закрытый ключ образуют пару. Вы можете подписать и расшифровать с помощью закрытого ключа, вы можете проверить (подпись) и зашифровать с помощью открытого ключа. Открытый ключ предназначен для распространения, а закрытый ключ предназначен для хранения в секрете.

Сертификат открытого ключа - это комбинация открытого ключа и различных частей информации (в основном, касающихся личности владельца пары ключей, который контролирует закрытый ключ), эта комбинация подписывается с использованием закрытого ключа эмитента сертификат. Сертификат X.509 имеет отличительное имя субъекта и отличительное имя издателя. Имя издателя - это имя субъекта сертификата организации, выдающей сертификат. Самоподписанные сертификаты - это особый случай, когда издатель и субъект совпадают. Подписывая содержимое сертификата (т. Е. Выдавая сертификат), издатель утверждает его содержимое, в частности, связь между ключом, идентификатором (субъектом) и различными атрибутами (которые могут указывать на намерение или объем использования для сертификат).

Вдобавок к этому, спецификация PKIX определяет расширение (часть данного сертификата), которое указывает, может ли сертификат использоваться в качестве сертификата CA, то есть может ли он использоваться в качестве эмитента для другого сертификата.

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

В вашем случае, если вы создаете самозаверяющий сертификат для определенной службы, не имеет значения, есть ли у него флаг CA (расширение базовых ограничений). Вам понадобится сертификат CA, чтобы иметь возможность выдавать другие сертификаты (если вы хотите создать свой собственный PKI). Если сертификат, который вы генерируете для этой службы, является сертификатом CA, он не должен причинить вреда. Более важно то, как вы можете настроить своего клиента для доверия этому сертификату для этого конкретного сервера (например, браузеры должны позволять вам довольно легко создавать явное исключение). Если механизм конфигурации следует модели PKI (без использования конкретных исключений), поскольку нет необходимости создавать цепочку (только с одним сертификатом), вы должны иметь возможность импортировать сертификат напрямую как часть якорей доверия ваш клиент, будь то '


1
Спасибо за информацию. Я дам Хельге правильный ответ, поскольку он пришел раньше и был короче. Однако это было хорошо знать.
Pace

8

Вы можете openssl x509 -noout -text -in $YOUR_CERT увидеть различия между содержимым файлов:

В самозаверяющем ЦС вы можете увидеть :

    X509v3 extensions:                                                          
        X509v3 Basic Constraints:
            CA:TRUE, pathlen:0

А в вашем самозаверяющем сертификате это:

    X509v3 extensions:                                                          
        X509v3 Basic Constraints:
            CA:FALSE

0

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.