Почему Windows 2012 R2 не доверяет моему самозаверяющему сертификату?


9

В тестовой среде меня в настоящее время удерживают от тестирования некоторых вещей, которые должны быть развернуты в ближайшее время (на самом деле уже, но вы знаете, как проходят сроки ...), потому что Windows отказывается доверять самоподписанному сертификату, который мы имеем в нашем изолированная среда тестирования. Хотя я мог бы просто обойти проблему с «настоящим» сертификатом и некоторыми хитростями DNS, по соображениям безопасности / разделения я не сказал этот сертификат.

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

В соответствии с инструкциями, которые я нашел здесь и здесь , это должен быть простой процесс установки сертификата в хранилище Trusted Root Certification Authority на локальном компьютере. Что я и сделал, а также вручную скопировал сертификат и импортировал его непосредственно через оснастку MMC. Выход из системы и перезагрузка ничего не меняют.

Вот ошибка сертификата, которую я получаю каждый раз: введите описание изображения здесь

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

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

В этих инструкциях конкретно упоминаются Vista (ну, вторая не упоминает ОС) и IIS, в то время как я использую Server 2012 R2 для подключения к серверу на основе Linux; В мастере импорта есть некоторые различия (например, у меня есть опция импорта для текущего пользователя или локальной системы, хотя я пробовал оба), так что, может быть, я должен сделать что-то другое здесь? Параметр где-то, которого я не нашел, должен быть изменен, чтобы действительно доверять сертификату, которому я уже сказал доверять?

Как правильно заставить Windows Server 2012 R2 доверять самозаверяющему сертификату?


Невозможно воспроизвести вашу проблему. Если вы используете «Создание самозаверяющего сертификата» IIS и выбираете его установку в личном хранилище (также пробовали в хранилище веб-хостинга), проблем вообще не возникает. Как вы создали сертификат? Из IIS или из оснастки MMC Центра сертификации?

Вы пытались явно выбрать хранилище назначения (импорт из консоли mmc)?
JoaoCC

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

@ user1703840 Да, я явно указал целевое хранилище, а также разрешил Windows автоматически выбирать его через MMC и мастер импорта сертификатов в IE. В любом случае, одни и те же результаты, которых нет.
Кромей

А? Откуда появился Linux? Весь ваш вопрос и опубликованные вами ссылки (включая снимки экрана) относятся к Windows Server 2012 R2 и IIS. Просьба уточнить.

Ответы:


1

Ошибка, которую вы получаете, заключается не в том, что это не доверенный корневой сертификат, а в том, что он не может проверить цепочку до доверенного сертификата. Если какая-либо часть цепочки сломана, ненадежна или отсутствует, вы получите такую ​​ошибку. Ошибка, которую я получаю с недоверенным, самозаверяющим рутомэто: Этот корневой сертификат CA не является доверенным. Чтобы включить доверие, установите этот сертификат в хранилище доверенных корневых центров сертификации. Но для вас он говорит, что не может проверить до доверенного корневого сертификата. Это может быть связано с тем, что в процессе самоподписания вы, возможно, сказали openssl подписать сертификат с другим корнем (не самоподписанным), или он не был установлен в качестве корневого ЦС. Если это первый, вы должны доверять корню, с которым он был подписан. Если это последнее, это вопрос установки нескольких свойств в openssl.conf.


Снимки экрана показывают, что сертификат установлен в Trusted Root CA, а также показывают, что вся цепочка является самим сертификатом - это корень, и поэтому должно быть достаточно наличия Trusted Root CA. Вопрос в том, почему не так?
Кромей

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

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

О, я понимаю, что вы имеете в виду. Извините, я неправильно понял. Но если это не корень, не должен ли он отображаться в окне «Путь сертификации»? В любом случае, к сожалению, я не могу проверить это дальше - мне удалось заполучить наш законный сертификат, и вместе с небольшим взломом в hostsфайле все заработало.
Кромей

Ваш сертификат получен от корневого центра сертификации на основе снимка экрана. Если вы посмотрите на детали сертификата для idp.godaddy.com, представлен весь путь, и вы можете использовать его для сравнения. Если вы посмотрите на свойства сертификата в MMC, включает ли он аутентификацию сервера в целях сертификата? (Щелкните правой кнопкой мыши на сертификате на втором снимке экрана и выберите свойства).
Джон Олд

1

Исходя из того, что я могу понять, вам нужно добавить zmaster в качестве доверенного исходного ЦС, так как это орган выдачи, WS2k12 пытается проверить сертификат на хосте, о котором он ничего не знает. Вы правы в том, что метод генерации не так важен, как проверяемый источник. Это имеет эффект, который вы испытываете: WS2k12 не доверяет сертификату только потому, что он имеет имя $ Random_issuing_authority, он должен иметь возможность проверить сертификат.


Это самозаверяющий сертификат - поместив сертификат в хранилище доверенных корневых центров сертификации, вы по определению доверяете эмитенту.
Крис Мак-

Если я что-то не упустил, это именно то, что я сделал - см. Третий снимок экрана, показывающий сертификат zmaster в хранилище доверенных корневых центров сертификации.
Кромей

0

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

Старая пара сертификат / ключ работала нормально в большинстве ситуаций, но не с outlook.com и не с MS Outlook 2013.

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


0

Я думаю, что проблема в том, как вы получили доступ к ресурсам. Для вашей локальной сети вы можете использовать имя хоста вместо полного имени домена. Тем не менее, ваш сертификат выдается на полное доменное имя.


На этот вопрос уже есть принятый ответ.
BE77Y

-1

Установите сертификат для доверенных корневых центров сертификации и доверенных издателей.

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