Чому Windows 2012 R2 не довіряє моєму самопідписаному сертифікату?


9

У тестовому середовищі в даний час я переживаю тестування деяких речей, які потрібно незабаром розгорнути (насправді вже є, але ви знаєте, як проходять терміни ...), оскільки Windows відмовляється довіряти самопідписаному сертифікату, який ми маємо в нашому ізольоване тестове середовище. Хоча я міг просто побічно вирішити проблему з "справжнім" сертифікатом та деякими хитростями DNS, з міркувань безпеки / розділення я не зазначив цього сертифіката.

Я намагаюся підключитися до Linux-сервера електронної пошти під назвою Zimbra; він використовує автоматично створений самопідписаний сертифікат OpenSSL. Хоча сторінки, на яких Google спеціально звертається, посилаються на веб-сайти IIS з сертифікатами IIS, що підписуються самостійно, я не думаю, що метод її генерації насправді має значення.

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

Ось помилка сертифіката, яку я отримую щоразу: введіть тут опис зображення

А ось шлях до сертифікації (спойлер: це лише сам сертифікат): введіть тут опис зображення

Нарешті, ось сертифікат, безпечно захований у магазині сертифікатів місцевого комп'ютера, саме так, як я знайшов інструкції: введіть тут опис зображення

Ці інструкції конкретно посилаються на Vista (ну, у другій не згадується ОС) та IIS, тоді як я використовую Server 2012 R2 для підключення до сервера на базі Linux; У майстра імпорту є деякі відмінності (наприклад, у моєї є можливість імпортувати для поточного користувача чи локальної системи, хоча я спробував і те й інше), тож, можливо, тут щось інше? Налаштування десь я не знайшов, що має бути змінено, щоб він справді справді довіряв сертифікату, якому я вже сказав йому довіряти?

Який правильний спосіб змусити Windows Server 2012 R2 довіряти сертифікату, який підписав самостійно?


Неможливо відтворити проблему. Якщо ви використовуєте "Створити самопідписаний сертифікат" IIS і вибрати, щоб встановити його в Особистий магазин (також випробуваний магазин веб-хостингу), взагалі немає жодної проблеми. Як ви створили сертифікат? Від IIS або від центру сертифікації MMC Snapin?

Ви намагалися чітко вибрати магазин призначення (імпорт з консолі mmc)?
JoaoCC

@SujaySarma Це не для веб-сайту IIS, а для додатка Linux під назвою Zimbra. Це сертифікат з власним підписом OpenSSL.
Кромей

@ user1703840 Так, я чітко вказав цільовий магазин, а також дозволив Windows автоматично вибирати його через MMC та майстер імпорту сертифікатів в IE. У будь-якому випадку результати однакові, яких немає.
Кромей

Так? Звідки взявся Linux? Увесь ваш питання та посилання, які ви опублікували (включаючи скріншоти), стосуються Windows Server 2012 R2 та IIS. Будь ласка, поясніть.

Відповіді:


1

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


На знімках екрана видно, що сертифікат встановлено в Trusted Root CA, а також показано, що весь ланцюжок є самим сертифікатом - він є коренем, а тому перебування в Trusted Root CA повинно вистачити. Питання в тому, чому це не так?
Кромей

Я кажу, що це може бути не корінь, не те, що він не додається до магазину надійних коренів. Помилка полягає в тому, що в цьому дивно - він не повинен говорити, що він не може перевірити це до надійного КА, якщо це повинен бути CA - саме тому я припускаю, що це насправді не корінь, але підписано з ще один сертифікат.
flashbang

спробуйте запустити цю команду у вікні, для якого ви намагаєтесь отримати сертифікат для: openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 30 -sha256 -nodesта імпортувати цей сертифікат у надійний кореневий магазин CA. (звичайно, як і налаштувати його на серт і ключ, який, звичайно, використовує Zimbra).
flashbang

О, я бачу, що ти маєш на увазі. Вибачте, я неправильно зрозумів. Але якщо це не корінь, чи не повинно це відображатися у вікні Шлях сертифікації? У будь-якому випадку, на жаль, я більше не можу перевірити це далі - мені вдалося отримати наш легітимний сертифікат, і разом із трохи взломом hostsфайлу він так і працював.
Кромей

Ваш сертифікат походить з кореневого ЦА на основі знімка екрана. Якщо ви подивитесь деталі сертифікату для idp.godaddy.com, представлений весь шлях, і ви можете використовувати його для порівняння. Якщо ви подивитеся на властивості сертифіката в MMC, чи включає він автентифікацію сервера в цілях сертифікату? (Клацніть правою клавішею миші на kert у другому знімку екрана та виберіть властивості).
Джон Олд

1

з того, що я можу розробити, вам потрібно додати zmaster як довірене джерело CA, оскільки це орган, що видає, WS2k12 намагається перевірити сертифікат проти хоста, про який він нічого не знає. Ви маєте рацію в тому, що метод генерації не важливий, але джерело, яке може бути перевірено. Це відчуває те, що ви відчуваєте: що WS2k12 не довіряє сертифікату лише тому, що він має ім'я $ Random_issuing_authority, йому потрібно мати змогу перевірити сертифікат.


Це самопідписаний сертифікат - розміщуючи керт в магазині Trusted Root CA, ви за визначенням довіряєте емітенту.
Кріс МакКаун

Якщо я щось не пропускаю, саме це я і зробив - дивіться третій скріншот, на якому відображається сертифікат zmaster в магазині Trusted Root CA.
Кромей

0

У мене була така ж проблема, виявляється, моє рішення було оновити файли .crt і .key для поштового сервера, як використовується dovecot. У пошті Exim4 був оновлений набір cert / key, але dovecot все ще вказував на старий набір cert / key.

Стара пара сертифікованих ключів добре працювала в більшості ситуацій, але не з Outlook.com, ані з MS Outlook 2013.

Проблеми з outlook.com змусили мене нещодавно оновити сертифікат exim4 - тепер dovecot [і сервер веб-пошти] також використовує нові файли cert (та key). Сам поштовий сервер також нещодавно був оновлений [від старого Debian скрет-lts до wheezy], стара установка була в порядку все навколо зі старим набором cert / key, але після оновлення мені потрібно було створити новий набір cert / key раніше Продукти MS будуть належним чином працювати з поштовим сервером.


0

Я думаю, що проблема полягає в тому, як ви отримали доступ до ресурсів. Для вашої локальної мережі ви можете використовувати ім'я хоста замість повного доменного імені. Однак ваш сертифікат видається проти повного доменного імені.


На це питання вже є прийнята відповідь.
BE77Y

-1

Встановіть сертифікат довірених кореневих органів сертифікації та довірених видавців.

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