Jak zainstalować komercyjny certyfikat SSL na serwerze Zimbra

Komercyjny certyfikat SSL w systemie Zimbra może nie zostać zatwierdzony z kilku powodów, nawet jeśli urząd certyfikacji twierdzi, że certyfikat został wydany prawidłowo. Najczęstsze problemy zazwyczaj nie dotyczą samego certyfikatu: klucz prywatny nie zgadza się z zwróconym certyfikatem, brakuje pośredniego urzędu certyfikacji, brakuje nazwy hosta w alternatywnej nazwie podmiotu (SAN) certyfikatu lub administrator wdraża pliki przed walidacją łańcucha.

Najbezpieczniejszym sposobem wykonania tego zadania jest potraktowanie go jako sekwencji sprawdzeń, a nie pojedynczego polecenia „zainstaluj certyfikat”. Udokumentowane narzędzie certyfikacyjne Zimbra, zmcertmgr, może utworzyć żądanie podpisania certyfikatu (CSR), zweryfikować klucz prywatny i łańcuch CA, wdrożyć certyfikat w usługach Zimbra i wyświetlić aktualnie aktywny certyfikat. Oficjalne Centrum Techniczne Zimbra dokumentuje te polecenia w swoim przewodniku po Konsoli Administracyjnej i Narzędziach Certyfikatów CLI .

Jak powinna wyglądać udana instalacja Zimbra SSL

Zanim cokolwiek zmienisz, zdefiniuj pożądany rezultat. Prawidłowe wdrożenie powinno spełniać wszystkie poniższe warunki:

• Lista SAN certyfikatu zawiera wszystkie publiczne nazwy hostów faktycznie używane przez klientów, takie jak mail.example.com.
• Wydany certyfikat jest zgodny z kluczem prywatnym zapisanym w certyfikacie komercyjnym.
• Zimbra może zweryfikować cały łańcuch od certyfikatu serwera, poprzez certyfikaty pośrednich urzędów certyfikacji, aż do głównego urzędu certyfikacji.
• zmcertmgr deploycrt commkończy się bez błędu niezgodności klucza lub walidacji łańcucha.
• Usługi Zimbra restartują się bez problemów.
• zmcertmgr viewdeployedcrtpokazuje oczekiwany certyfikat.
• Przeglądarka lub klient TLS łączący się z publiczną nazwą hosta zobaczy nowy certyfikat i ostrzeżenie o braku zaufania.

Jeśli jedno z tych sprawdzeń się nie powiedzie, napraw tę konkretną warstwę przed kontynuacją. Wielokrotne ponowne wdrażanie tych samych plików rzadko rozwiązuje problem z kluczem, siecią SAN lub łańcuchem.

Zanim zaczniesz: wybierz odpowiedni obieg certyfikatów

Aktualna strona Centrum Technicznego Zimbry informuje, że w wersji Zimbra 8.7 i nowszych program zmcertmgrjest uruchamiany jako zimbraużytkownik. Dokumentuje również, że komercyjny klucz prywatny musi być nazwany commercial.keyw /opt/zimbra/ssl/zimbra/commercial, a certyfikat serwera wraz z plikiem łańcucha CA powinny zostać umieszczone w katalogu tymczasowym przed wdrożeniem.

Krok 1: wykonaj kopię zapasową bieżącego materiału certyfikatu

Nie zaczynaj od usuwania istniejącego katalogu SSL. Najpierw utwórz kopię zapasową, którą będziesz mógł przywrócić w razie niepowodzenia wdrożenia. Dla użytkownika root, konserwatywnym przykładem jest:

cp -a /opt/zimbra/ssl/zimbra /opt/zimbra/ssl/zimbra.backup-$(date +%Y%m%d-%H%M%S)

Przed zmianą certyfikatu należy go również zapisać:

su - zimbra
/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Daje to punkt odniesienia do porównania po zmianie. Jeśli Twoje środowisko ma wiele węzłów Zimbra, przechwyć aktualny stan certyfikatu na każdym odpowiednim serwerze, zamiast zakładać, że są identyczne.

Krok 2: wygeneruj CSR z nazwami hostów, których faktycznie potrzebujesz

W przypadku nowego certyfikatu komercyjnego utwórz CSR z nazwą hosta produkcyjnego i wszelkimi dodatkowymi numerami SAN. Zimbra dokumentuje następującą składnię:

/opt/zimbra/bin/zmcertmgr createcsr comm -new \
-subject "/C=US/ST=CA/L=Sunnyvale/O=Example/OU=IT/CN=mail.example.com" \
-subjectAltNames "mail.example.com"

Jeśli użytkownicy łączą się również za pomocą innej nazwy, takiej jak webmail.example.com, należy uwzględnić ją na liście SAN podczas żądania certyfikatu. Współcześni klienci TLS weryfikują nazwy hostów pod kątem nazw SAN, więc certyfikat, który wygląda na poprawny tylko na podstawie nazwy wspólnej, może nadal generować ostrzeżenie w przeglądarce, jeśli nazwa hosta jest brakująca.

Przed wysłaniem CSR do urzędu certyfikacji należy go przejrzeć:

/opt/zimbra/bin/zmcertmgr viewcsr comm /opt/zimbra/ssl/zimbra/commercial/commercial.csr

Punkt kontrolny: zatrzymaj się tutaj, jeśli żądane nazwy DNS są nieprawidłowe. Wydanie certyfikatu jako pierwsze i późniejsze odkrycie brakującego numeru SAN oznacza, że ​​zazwyczaj konieczne jest jego ponowne wydanie przez urząd certyfikacji.

Krok 3: zbierz certyfikat serwera i cały łańcuch CA

Po walidacji komercyjny urząd certyfikacji zazwyczaj zwraca certyfikat serwera oraz jeden lub więcej certyfikatów pośrednich. Oficjalna procedura certyfikacji komercyjnej Zimbra dla pojedynczego węzła wymaga certyfikatu serwera w formacie PEM i instruuje administratorów, aby połączyli certyfikaty pośrednich i głównych urzędów certyfikacji w plik łańcuchowy.

Typowy układ sceny wygląda następująco:

/tmp/commercial.crt
/tmp/ca_intermediary.crt
/tmp/ca.crt

Następnie zbuduj łańcuch w kolejności udokumentowanej przez Zimbra:

cat /tmp/ca_intermediary.crt /tmp/ca.crt > /tmp/ca_chain.crt

Użyj plików dostarczonych przez urząd certyfikacji dla konkretnego produktu certyfikacyjnego. Nie kopiuj certyfikatu pośredniego z niepowiązanego samouczka tylko dlatego, że nazwa marki urzędu certyfikacji jest podobna. Hierarchie urzędów certyfikacji zmieniają się z czasem, a niewłaściwy certyfikat pośredni jest częstą przyczyną problemów unable to get local issuer certificate.

Krok 4: sprawdź klucz prywatny, certyfikat serwera i łańcuch przed wdrożeniem

To najważniejsza bramka bezpieczeństwa. Uruchom udokumentowane polecenie weryfikacyjne jako użytkownik Zimbra w bieżących wersjach Zimbra:

su - zimbra
/opt/zimbra/bin/zmcertmgr verifycrt comm \
/opt/zimbra/ssl/zimbra/commercial/commercial.key \
/tmp/commercial.crt \
/tmp/ca_chain.crt

Pomyślna weryfikacja potwierdza zgodność certyfikatu z kluczem prywatnym oraz jego ważność. Dokumentacja narzędzi certyfikacyjnych Zimbra wyjaśnia, że verifycrt​​łączy ona weryfikację klucza z weryfikacją łańcucha certyfikatów.

Jeśli weryfikacja się nie powiedzie, wybierz rozwiązanie na podstawie błędu

• Niezgodność certyfikatu i klucza prywatnego: certyfikat CA nie został wydany z CSR powiązanego z bieżącym commercial.key. Przywróć poprawny klucz lub ponownie wydaj certyfikat z nowego CSR.
• Nie można zweryfikować łańcucha certyfikatu: pakiet pośredni/główny jest niekompletny, w niewłaściwej kolejności, wygasł lub nie jest łańcuchem dla tego certyfikatu serwera. Uzyskaj poprawny łańcuch od wystawiającego urzędu certyfikacji.
• Certyfikat wygasł: nie wdrażaj go. Poproś o aktualny certyfikat i sprawdź, czy certyfikat pośredni lub główny w łańcuchu nie wygasł. Zimbra dokumentuje ten tryb awarii w swoich poradnikach rozwiązywania problemów z wygasłym głównym urzędem certyfikacji .
• Brak nazwy hosta: weryfikacja może nie odzwierciedlać tej samej nazwy hosta, którą sprawdza przeglądarka. Sprawdź wydane numery SAN i wydaj je ponownie, jeśli nazwa publiczna nie jest obecna.

Krok 5: wdrożenie certyfikatu komercyjnego

Wdrożenie powinno nastąpić dopiero po pomyślnym zakończeniu weryfikacji:

/opt/zimbra/bin/zmcertmgr deploycrt comm /tmp/commercial.crt /tmp/ca_chain.crt

Udokumentowany proces wdrażania systemu Zimbra kopiuje certyfikat komercyjny do obszaru SSL, dołącza łańcuch urzędów certyfikacji, aktualizuje konfigurację certyfikatu i instaluje materiał certyfikatu dla usług, takich jak MTA, LDAP, serwer proxy i komponenty skrzynki pocztowej, w zależności od potrzeb serwera.

Nie nadpisuj ręcznie losowych magazynów kluczy Java ani plików certyfikatów usług, chyba że dokumentacja konkretnej wersji Zimbra wyraźnie tego wymaga. Celem zmcertmgrjest zachowanie spójności treści certyfikatów specyficznych dla danej usługi.

Krok 6: ponowne uruchomienie usług Zimbra

Po wdrożeniu należy ponownie uruchomić Zimbrę:

su - zimbra
zmcontrol restart

Następnie sprawdź stan usługi:

zmcontrol status

Jeśli usługa nie powraca do Running, należy to sprawdzić przed zadeklarowaniem zakończenia zmiany certyfikatu. Problemy z certyfikatem mogą mieć wpływ na komunikację LDAP, proxy, skrzynkę pocztową lub inną komunikację zależną od protokołu TLS, szczególnie w instalacjach wielowęzłowych.

Krok 7: sprawdź wynik zarówno po stronie Zimbry, jak i klienta

Najpierw użyj własnego widoku certyfikatów Zimbra:

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Można również sprawdzić, czy któryś z wdrożonych certyfikatów usług zbliża się do terminu wygaśnięcia:

/opt/zimbra/bin/zmcertmgr checkcrtexpiration all -days 30

Na koniec przetestuj dokładną publiczną nazwę hosta, którą otwierają użytkownicy. Przydatny sposób sprawdzenia OpenSSL z innego komputera to:

openssl s_client -connect mail.example.com:443 -servername mail.example.com -showcerts

Poszukaj oczekiwanego certyfikatu potomnego, prawidłowej nazwy hosta, kompletnego łańcucha i pomyślnego wyniku weryfikacji. Następnie otwórz ten sam adres URL HTTPS w bieżącej przeglądarce. Test przeglądarki jest ważny, ponieważ sprawdza nazwę hosta, do której faktycznie docierają użytkownicy, a nie tylko pliki certyfikatów na dysku.

Kiedy standardowa procedura nie wystarcza

Zmień podejście zamiast wymuszać kroki na pojedynczym węźle, jeśli ma zastosowanie którykolwiek z poniższych warunków:

• Wielowęzłowa Zimbra: wdrożenie certyfikatu może wymagać objęcia ról proxy, skrzynki pocztowej, LDAP i MTA na różnych hostach. Narzędzie do obsługi certyfikatów Zimbra obsługuje opcje wieloserwerowe, ale przed ich użyciem należy zweryfikować procedurę dla swojej topologii.
• Odwrotny serwer proxy lub zewnętrzny moduł równoważenia obciążenia kończy działanie protokołu TLS: może być również konieczne zainstalowanie certyfikatu publicznego na tym urządzeniu. Sam prawidłowy certyfikat Zimbra nie zmieni tego, co widzą klienci, jeśli protokół TLS zostanie zakończony.
• Importujesz istniejący klucz: przed weryfikacją upewnij się, że zostanie on umieszczony w miejscu, w którym Zimbra oczekuje komercyjnego klucza prywatnego, a uprawnienia odpowiadają wymaganiom danej wersji.
• Twój urząd certyfikacji dostarcza jedynie pakiet pośredni: postępuj zgodnie z bieżącymi instrukcjami dotyczącymi łańcucha urzędu certyfikacji, zamiast tworzyć certyfikat główny. Zimbra potrzebuje łańcucha, który może zweryfikować; dokładne pliki zależą od wystawcy.
• Certyfikat został odnowiony z tą samą nazwą hosta, ale innym kluczem: przed weryfikacją należy zaktualizować pasujący klucz prywatny. Poprzedni commercial.keynie może zweryfikować certyfikatu wydanego dla nowej pary kluczy.

Ostateczna samokontrola

Instalacja zostanie ukończona tylko wtedy, gdy spełnione zostaną wszystkie poniższe warunki: verifycrtzakończy się powodzeniem, deploycrtpomyślnie przejdzie, usługi Zimbra powrócą do stanu Uruchomione, viewdeployedcrtzostanie wyświetlony nowy certyfikat, a zewnętrzne połączenie TLS z rzeczywistą nazwą hosta otrzyma ten sam ważny certyfikat bez ostrzeżenia dotyczącego zaufania lub nazwy hosta.

W przypadku składni poleceń i zachowania specyficznego dla wersji, należy skorzystać z oficjalnej dokumentacji narzędzi certyfikacyjnych Zimbra jako głównego źródła. Poniższe przykłady służą mail.example.comjako symbole zastępcze; zastąp nazwy, pliki certyfikatów i dane organizacyjne wartościami wydanymi dla Twojego środowiska.