Різниця між самопідписаним ЦС та самопідписаним сертифікатом


81

Мені незрозуміла різниця між ключем ЦС та сертифікатом. Чи не є ключ CA просто сертифікатом? Дозвольте спробувати пояснити на прикладі.

У мене є клієнт і сервер. Я лише намагаюся перевірити своє підключення до мого сервера, а не намагаюся встановити довіру до інших, тому мені байдуже підписувати справжній центр сертифікації.

Варіант 1: Створіть власний підпис CA ( ssCA ) і використовуйте його для підписання сертифіката ( C ). Потім встановити SSCA в кореневому сховищі на моєму клієнтові і налаштувати мій сервер на використання сертифікат C .

Варіант 2: Створіть самопідписаний сертифікат ( SSC ). Встановіть SSC у кореневий магазин ключів мого клієнта. Налаштуйте мій сервер на використання сертифіката SSC .

Другий варіант здається набагато простішим процесом. Це все одно має працювати?

Відповіді:


62

Обидва варіанти дійсні, варіант 2 простіший.

Варіант 1 (налаштування власного центру сертифікації) є кращим, коли вам потрібні кілька сертифікатів. У компанії ви можете створити власний центр сертифікації та встановити сертифікат цього центру в кореневому сховищі всіх клієнтів. Потім ці клієнти приймуть усі сертифікати, підписані вашим ЦС.

Варіант 2 (самостійно підписати сертифікат без сертифіката) простіше. Якщо вам потрібен лише один сертифікат, то цього цілком достатньо. Встановіть його в магазинах ключів ваших клієнтів, і все готово. Але коли вам потрібен другий сертифікат, його потрібно встановити знову для всіх клієнтів.

Ось посилання з додатковою інформацією: Створення органів сертифікації та самопідписані сертифікати SSL


Якщо ЦС підписує сертифікат, чи можу я все одно просто довіряти згенерованому сертифікату ( у цьому випадку C ), знаючи, що мені просто потрібно буде довіряти кожному створеному сертифікату, а не одному сертифікату, який надходить від ЦС?
ivandov

65

По-перше, щодо різниці між ключем та сертифікатом (щодо "ключа CA"), є три частини, що використовуються, коли йдеться про сертифікати відкритих ключів (як правило, X.509): відкритий ключ, приватний ключ та сертифікат. Відкритий та приватний ключі утворюють пару. Ви можете підписати та розшифрувати за допомогою закритого ключа, ви можете перевірити (підпис) та зашифрувати за допомогою відкритого ключа. Відкритий ключ призначений для розповсюдження, тоді як приватний ключ призначений для збереження приватного.

Сертифікат відкритого ключа - це поєднання між відкритим ключем та різною інформацією (здебільшого стосовно особи власника пари ключів, хто контролює закритий ключ), причому ця комбінація підписується за допомогою приватного ключа емітента сертифікат. Сертифікат X.509 має тематичне відмінне ім’я та ідентифікаційне ім’я емітента. Назва емітента - це назва суб'єкта сертифіката суб'єкта, що видає сертифікат. Самостійно підписані сертифікати - це особливий випадок, коли видавець та предмет є однаковими. Підписуючи вміст сертифіката (тобто видаючи сертифікат), емітент стверджує його зміст, зокрема, прив’язку між ключем, ідентифікацією (предметом) та різними атрибутами (що може вказувати на намір або сферу використання для сертифікат).

Крім цього, специфікація PKIX визначає розширення (частину даного сертифіката), яке вказує, чи можна використовувати сертифікат як сертифікат ЦС, тобто чи можна його використовувати як видавача для іншого сертифіката.

З цього ви створюєте ланцюжок сертифікатів між сертифікатом кінцевої сутності (який ви хочете перевірити для користувача чи сервера) та сертифікатом ЦС, якому ви довіряєте. Між сертифікатами кінцевої сутності вашої послуги та сертифікатом ЦС, якому ви довіряєте, можуть бути проміжні сертифікати ЦС (видані іншими сертифікатами ЦС). Вам не потрібен строго кореневий центр сертифікації у верхній частині (самопідписаний сертифікат ЦС), але це часто так (ви можете довіряти проміжному сертифікату ЦС безпосередньо, якщо хочете).

Для вашого випадку використання, якщо ви створюєте самопідписаний сертифікат для певної служби, чи має він прапор CA (розширення основних обмежень) насправді не має значення. Він повинен бути сертифікатом ЦС, щоб мати можливість видавати інші сертифікати (якщо ви хочете створити свій власний PKI). Якщо сертифікат, який ви створюєте для цієї послуги, є сертифікатом ЦС, він не повинен завдати шкоди. Важливіше те, як ви можете налаштувати клієнта на довіру до цього сертифіката для цього конкретного сервера (наприклад, браузери повинні дозволяти вам зробити явне виняток). Якщо механізм конфігурації слідує моделі PKI (без використання конкретних винятків), оскільки не буде необхідності будувати ланцюжок (лише з одним сертифікатом), ви повинні мати можливість імпортувати сертифікат безпосередньо як частину прив'язок довіри до ваш клієнт, будь то


1
Спасибі за інформацію. Я збираюся дати Гельге правильну відповідь, оскільки вона прийшла раніше і стала коротшою. Однак це було добре знати.
Темп

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

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.