Dlaczego system Windows 2012 R2 nie ufa mojemu samopodpisanemu certyfikatowi?

W środowisku testowym obecnie powstrzymuję się od testowania niektórych rzeczy, które trzeba wkrótce wdrożyć (właściwie już, ale wiesz, jak minęły terminy ...), ponieważ Windows odmawia zaufania do samopodpisanego certyfikatu, który mamy w naszym izolowane środowisko testowe. Chociaż mogę po prostu rozwiązać problem z „prawdziwym” certyfikatem i niektórymi sztuczkami DNS, ze względów bezpieczeństwa / podziału na segmenty nie powiedziałem tego certyfikatu.

Próbuję połączyć się z serwerem poczty e-mail opartym na systemie Linux o nazwie Zimbra; wykorzystuje automatycznie wygenerowany samopodpisany certyfikat OpenSSL. Chociaż strony, które pojawiły się w Google, odnoszą się konkretnie do stron internetowych IIS z samopodpisanymi certyfikatami IIS, nie sądzę, że metoda ich generowania ma znaczenie.

Zgodnie z instrukcjami, które znalazłem tu i tutaj , powinna to być prosta kwestia zainstalowania certyfikatu w sklepie Trusted Root Certification Authority na komputerze lokalnym. Zrobiłem to, a także ręcznie kopiowałem certyfikat i importowałem go bezpośrednio za pomocą przystawki MMC. Wylogowania i ponowne uruchomienie nic nie zmieniają.

Oto błąd certyfikatu, który otrzymuję za każdym razem:

A oto ścieżka certyfikacji (spoiler: to tylko sam certyfikat):

Wreszcie, oto certyfikat bezpiecznie schowany w magazynie certyfikatów lokalnego komputera, dokładnie tak, jak znalazłem instrukcje, które powinny być:

Te instrukcje odnoszą się konkretnie do Visty (cóż, drugi nie wspomina o systemie operacyjnym) i IIS, podczas gdy ja korzystam z Server 2012 R2 łączącego się z serwerem opartym na Linuksie; istnieją pewne różnice w kreatorze importu (np. mój ma opcję importowania dla bieżącego użytkownika lub systemu lokalnego, chociaż próbowałem obu), więc może jest coś innego, co muszę tutaj zrobić? Ustawienie, którego nie znalazłem, które należy zmienić, aby naprawdę zaufało certyfikatowi, który już mu zaufałem?

Jaki jest właściwy sposób, aby system Windows Server 2012 R2 ufał certyfikatowi z podpisem własnym?

Otrzymany błąd nie polega na tym, że nie jest to zaufany certyfikat główny, ale że nie jest w stanie zweryfikować łańcucha do zaufanego certyfikatu. Jeśli jakaś część łańcucha zostanie zerwana, niezaufana lub zaginie, otrzymasz taki błąd. Błąd, który otrzymuję z niezaufanym, samopodpisanym rootemjest to: ten certyfikat główny urzędu certyfikacji nie jest zaufany. Aby włączyć zaufanie, zainstaluj ten certyfikat w sklepie Zaufane główne urzędy certyfikacji. Ale dla ciebie mówi, że nie może zweryfikować do zaufanego certyfikatu głównego. Może się tak zdarzyć, że podczas procesu samopodpisywania mógłbyś powiedzieć openssl, aby podpisał certyfikat innym rootem (nie samopodpisaniem) lub może nie zostać ustawiony jako główny urząd certyfikacji. Jeśli jest to pierwszy, musisz zaufać rootowi, z którym został podpisany. Jeśli jest to ten ostatni, to kwestia ustawienia kilku właściwości w openssl.conf.

z tego, co mogę wypracować, musisz dodać zmaster jako Zaufany źródłowy urząd certyfikacji, ponieważ jest to organ wydający, WS2k12 próbuje zweryfikować certyfikat na hoście, o którym nic nie wie. Masz rację, że metoda generowania nie jest ważna, ale możliwe do zweryfikowania źródło jest. Ma to taki skutek, że doświadczasz: że WS2k12 nie ufa certyfikatowi tylko dlatego, że ma nazwę $ Random_issuing_authority, musi być w stanie zweryfikować certyfikat.

Miałem ten sam problem, okazało się, że moim rozwiązaniem było zaktualizowanie plików .crt i .key dla serwera poczty, tak jak to robił dovecot. Exim4 na poczcie miał zaktualizowany zestaw certyfikatów / kluczy, ale dovecot nadal wskazywał na stary zestaw certyfikatów / kluczy.

Stara para certyfikatu / klucza działała dobrze w większości sytuacji, ale nie w przypadku outlook.com ani MS Outlook 2013.

Problemy z outlook.com spowodowały, że ostatnio zaktualizowałem certyfikat exim4 - teraz dovecot [i serwer poczty internetowej] również korzysta z nowych plików cert (i key). Sam serwer pocztowy został niedawno zaktualizowany [ze starego squeeze-lts Debiana do wheezy], stara konfiguracja była w porządku ze starym zestawem certyfikatów / kluczy, ale po aktualizacji musiałem utworzyć nowy zestaw certyfikatów / kluczy przed Produkty MS działałyby poprawnie z serwerem poczty.

Myślę, że problem polega na tym, w jaki sposób uzyskałeś dostęp do zasobów. W sieci lokalnej możesz użyć nazwy hosta zamiast pełnej nazwy domeny. Jednak certyfikat jest wystawiany na pełną nazwę domeny.

Zainstaluj certyfikat w Zaufanych głównych urzędach certyfikacji i Zaufanych wydawcach.