Чому 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.