certyfikat serwera

Certyfikat serwera to plik kryptograficzny potwierdzający tożsamość infrastruktury pocztowej wobec łączących się klientów.

Certyfikat serwera w połączeniach pocztowych

Certyfikat serwera jest dokumentem kryptograficznym zgodnym z profilem X.509. Zawiera między innymi nazwę podmiotu, nazwę wystawcy, okres obowiązywania, klucz publiczny oraz identyfikatory nazw, dla których certyfikat został wydany. W przypadku infrastruktury pocztowej potwierdza, że klient łączy się z serwerem wskazanym w konfiguracji, a nie z innym systemem podszywającym się pod właściwy host. Sam certyfikat nie jest hasłem i nie zawiera prywatnego klucza serwera.

Certyfikat jest wykorzystywany podczas negocjowania szyfrowanego połączenia TLS. Dotyczy to między innymi połączeń klienta pocztowego z usługą IMAP lub POP3, a także połączeń SMTP używanych do wysyłania wiadomości. W zależności od konfiguracji TLS może być uruchamiany od początku połączenia, jak przy portach określanych jako implicit TLS, albo po wydaniu przez klienta żądania STARTTLS. Certyfikat służy wtedy do uwierzytelnienia serwera i ustanowienia parametrów bezpiecznej sesji.

Jak klient weryfikuje tożsamość hosta

Podczas połączenia klient otrzymuje certyfikat serwera oraz, zazwyczaj, certyfikaty pośrednich urzędów certyfikacji. Następnie sprawdza podpisy tworzące łańcuch zaufania aż do urzędu certyfikacji znajdującego się w lokalnym magazynie zaufanych certyfikatów. Weryfikowany jest również okres ważności, status certyfikatu oraz zgodność nazwy serwera z nazwą wpisaną w konfiguracji programu pocztowego.

Współczesne klienty sprawdzają przede wszystkim pole Subject Alternative Name, skrótowo SAN. Jeżeli program łączy się z hostem poczta.example.pl, ta nazwa powinna znajdować się w SAN certyfikatu. Sama obecność nazwy w starszym polu Common Name nie zawsze wystarcza. Certyfikat wystawiony dla mail.example.pl nie potwierdza automatycznie tożsamości hosta smtp.example.pl, nawet jeśli oba adresy wskazują na ten sam komputer. Możliwe jest użycie jednego certyfikatu obejmującego kilka nazw, ale każda używana nazwa musi być ujęta w jego zakresie.

Klucz prywatny, łańcuch i ostrzeżenia TLS

Certyfikat zawiera klucz publiczny, natomiast serwer korzysta także z odpowiadającego mu klucza prywatnego. Klucz prywatny powinien pozostać dostępny wyłącznie dla procesu, który obsługuje szyfrowane połączenia. Jeżeli do serwera wgrano certyfikat bez właściwego klucza prywatnego, usługa może nie uruchomić TLS albo nie będzie w stanie przedstawić certyfikatu podczas połączenia. Certyfikat i klucz muszą tworzyć zgodną parę kryptograficzną.

Częstym źródłem ostrzeżeń jest niepełny łańcuch certyfikatów. Serwer może posiadać prawidłowy certyfikat końcowy, ale nie wysyłać certyfikatu pośredniego potrzebnego klientowi do zbudowania ścieżki zaufania. Innym problemem jest certyfikat samopodpisany, którego urząd wystawiający nie znajduje się w zaufanym magazynie systemu. Ostrzeżenie może również wynikać z przekroczenia daty ważności, nieprawidłowej nazwy hosta, wycofania certyfikatu lub niezgodnego czasu systemowego. Z tego powodu samo odnowienie pliku certyfikatu nie zawsze usuwa problem.

Diagnostyka błędu certyfikatu serwera

Diagnostykę należy rozpocząć od ustalenia dokładnego hosta, portu i trybu szyfrowania skonfigurowanego w kliencie pocztowym. Trzeba porównać tę nazwę z wpisami SAN, sprawdzić daty obowiązywania certyfikatu oraz ustalić, czy serwer zwraca pełny łańcuch. Warto także zweryfikować, czy połączenie nie jest kierowane przez inny rekord DNS, urządzenie pośredniczące albo lokalny program filtrujący ruch TLS. Różnica między nazwą używaną przez klienta a nazwą znajdującą się w certyfikacie jest konkretnym błędem konfiguracji, a nie problemem samego programu pocztowego.

Przy analizie trzeba rozdzielić błąd certyfikatu od błędu negocjacji protokołu. Prawidłowy certyfikat nie naprawi wyłączonej obsługi STARTTLS, niezgodnego portu ani ustawienia wymagającego szyfrowania, którego serwer nie oferuje. Należy sprawdzić także certyfikat prezentowany na konkretnym porcie, ponieważ różne usługi mogą korzystać z odmiennych konfiguracji. W środowisku lokalnym można użyć narzędzi diagnostycznych TLS, na przykład klienta OpenSSL, ale wynik trzeba interpretować razem z ustawieniami aplikacji, DNS i magazynu zaufanych certyfikatów. Przy sprzętowej awarii komputera używanego do obsługi klienta pocztowego możliwa jest również diagnostyka systemu, magazynu certyfikatów i konfiguracji sieciowej komputera PC.