Почему Windows 2012 R2 не доверяет моему самозаверяющему сертификату?
В тестовой среде я в настоящее время задерживаюсь от тестирования некоторых вещей, которые необходимо развернуть в ближайшее время (на самом деле, уже, но вы знаете, как идут сроки ...), потому что Windows отказывается доверять самозаверяющему сертификату, который есть в нашем изолированная среда тестирования. Хотя я мог бы просто обойти проблему с помощью «настоящего» сертификата и некоторых уловок с DNS, по соображениям безопасности / разделения я не указал сертификат.
Я пытаюсь подключиться к почтовому серверу Zimbra на базе Linux; он использует автоматически созданный самоподписанный сертификат OpenSSL. Хотя страницы, созданные Google, конкретно относятся к веб-сайтам IIS с самозаверяющими сертификатами IIS, я не думаю, что метод их создания действительно имеет значение.
По инструкции нашел Вот и Вот, это должен быть простой вопрос установки сертификата в хранилище доверенного корневого центра сертификации локального компьютера. Что я и сделал, а также вручную скопировал сертификат и импортировал его напрямую через оснастку MMC. Выходы из системы и перезагрузки ничего не меняют.
Вот ошибка сертификата, которую я получаю каждый раз: 
А вот и Путь сертификации (спойлер: это просто сам сертификат): 
Наконец, вот сертификат, надежно спрятанный в хранилище сертификатов локального компьютера, в точности как в инструкциях, которые я нашел: 
Эти инструкции конкретно относятся к Vista (ну, во второй ОС не упоминается) и IIS, в то время как я использую Server 2012 R2 для подключения к серверу на базе Linux; в мастере импорта есть некоторые различия (например, у меня есть возможность импортировать для текущего пользователя или локальной системы, хотя я пробовал оба), так что, может быть, мне нужно сделать что-то другое? Где-то я не нашел настройки, которые нужно изменить, чтобы действительно правда доверять сертификату, который я уже сказал ему доверять?
Как правильно заставить Windows Server 2012 R2 доверять самозаверяющему сертификату?
из того, что я могу понять, вам нужно добавить zmaster в качестве доверенного исходного центра сертификации, поскольку это орган выдачи, WS2k12 пытается проверить сертификат на хосте, о котором он ничего не знает. Вы правы в том, что важен не метод генерации, а проверяемый источник. Это имеет эффект, который вы испытываете: WS2k12 не доверяет сертификату только потому, что он имеет имя $ Random_issuing_authority, он должен иметь возможность проверить сертификат.
Вы получаете ошибку не в том, что это не доверенный корневой сертификат, а в том, что он не может проверить вверх по цепочке к доверенному сертификату. Если какая-либо часть цепочки сломана, ненадежна или отсутствует, вы получите такую ошибку. Ошибка, которую я получаю с ненадежным самоподписанным корень это: Этот корневой сертификат CA не является доверенным. Чтобы включить доверие, установите этот сертификат в хранилище доверенных корневых центров сертификации. Но для вас он говорит, что не может проверить до доверенного корневого сертификата. Это может быть так, что во время процесса самоподписи вы могли указать openssl подписать сертификат с другим корнем (не самоподписанным), или он мог быть не установлен как корневой ЦС. Если это первый, вы должны доверять корню, которым он был подписан. В последнем случае нужно установить несколько свойств в openssl.conf.
У меня была та же проблема, оказалось, что я решил обновить файлы .crt и .key для почтового сервера, который используется dovecot. Exim4 в почте имел обновленный набор сертификатов / ключей, но dovecot все еще указывал на старый набор сертификатов / ключей.
Старая пара сертификат / ключ отлично работала в большинстве ситуаций, но не с outlook.com или MS Outlook 2013.
Проблемы с outlook.com заставили меня недавно обновить сертификат exim4 - теперь dovecot [и сервер веб-почты] также использует новые файлы сертификатов (и ключей). Сам почтовый сервер также был недавно обновлен [со старого Debian squeeze-lts на wheezy], старая установка была в порядке со старым набором сертификатов / ключей, но после обновления мне нужно было создать новый набор сертификатов / ключей до Продукты MS будут корректно работать с почтовым сервером.
Я думаю, проблема в том, как вы получили доступ к ресурсам. Для вашей локальной сети вы можете использовать имя хоста вместо полного имени домена. Однако ваш сертификат выдается на полное доменное имя.
Установите сертификат в доверенные корневые центры сертификации и доверенные издатели.