Server — ServerKeyExchange

ten komunikat zawiera parametry algorytmu wymiany kluczy, których klient potrzebuje od serwera, aby uzyskać intermiate secrets, które będą wykorzystywane podczas konstruowania kluczy sesji końcowych do szyfrowania symetrycznego przez obie strony. Jest to opcjonalne, ponieważ niektóre algorytmy wymiany kluczy, takie jak wymiana kluczy RSA, nie wymagają tych parametrów, ponieważ sam certyfikat serwera wystarczy, aby Klient skonstruował i bezpiecznie komunikował tajny pre-master z serwerem.

jeśli metoda wymiany kluczy wybrana przez serwer w poprzednim kroku jest Diffie-Hellman (DH), serwer zawiera ten Komunikat po certyfikacie, który będzie zawierał publiczne komponenty wymagane do wygenerowania master secret.

Server — CertificateRequest

ten komunikat zostanie wysłany, jeśli na serwerze jest włączone uwierzytelnianie klienta SSL. Zwykle nie jest to wymagane na większości serwerów internetowych, ale w przypadku wysokich wymagań bezpieczeństwa serwer może wymagać certyfikatu klienta do uwierzytelnienia. Wraz z żądaniem certyfikatu, serwer wysyła typy klientów, które są akceptowalne, a także wskazuje listę wyróżnionych nazw organów certyfikujących, którym serwer zaufał. Ta lista zawiera władze urzędu certyfikacji dostępne w truststore serwera.

Server — ServerHelloDone

na koniec serwer wysyła wiadomość ServerHelloDone informującą klienta, że serwer zakończył przekazywanie parametrów bezpieczeństwa. Ten komunikat Kończy część negocjacji z serwerem. Ta wiadomość nie będzie zawierała żadnych innych informacji.

Client — Certificate

Klient odpowiada certyfikatem klienta, jeśli serwer żąda uwierzytelnienia klienta Komunikatem żądania certyfikatu. Jednak przed wysłaniem certyfikatu klient sprawdzi DN wystawcy certyfikatu klienta, który znajduje się na liście wyróżnionych nazw zaufanych certyfikatów wysyłanych przez serwer. Jeśli DN wystawcy nie zostanie znaleziony, klient nie wyśle swojego certyfikatu na serwer. Po stronie serwera jeśli uwierzytelnianie certyfikatu klienta jest obowiązkowe, uścisk dłoni TLS nie powiedzie się tutaj. W przeciwnym razie klient wyśle swój certyfikat i wszelkie potrzebne certyfikaty pośrednie do dopasowanego DN wymienionego w komunikacie żądania certyfikatu.

Client — ClientKeyExchange

wiadomość ClientKeyExchange zawiera tajemnicę Pre-master, która jest generowana przez Klienta. Odbywa się to zgodnie z pakietem szyfrów opracowanym przez obie strony w poprzednim kroku. Zarówno klient, jak i serwer użyją tego do wygenerowania głównej tajemnicy, z której obaj uzyskają ostateczne klucze kryptograficzne wymagane do ustanowienia zaszyfrowanego kanału. Klient szyfruje tajemnicę Pre-master kluczem publicznym serwera w taki sposób, że jeśli podsłuchujący przechwyci ten bit danych, nie będzie w stanie go odszyfrować, ponieważ nie ma dostępu do klucza prywatnego serwera. Klucz główny zapewnia serwerowi dane wymagane do wygenerowania kluczy szyfrowania symetrycznego. Jeśli jednak zestaw szyfrów wybrany do tej sesji był DH, wówczas ClientKeyExchange zawiera publiczne parametry Dh klienta zamiast tajnego klucza wstępnego.

Client — Certificateeverify

ta wiadomość jest używana przez Klienta do udowodnienia serwerowi, że posiada klucz prywatny odpowiadający jego certyfikatowi klucza publicznego. Wiadomość zawiera zaszyfrowane informacje (Skrót wszystkich wiadomości wymienianych do tej pory podczas procesu uzgadniania), które są podpisane cyfrowo przez Klienta. Jest to wymagane, jeśli serwer wydał Klientowi certyfikat CertificateRequest, aby Klient wysłał certyfikat w odpowiedzi, który musi zostać zweryfikowany po stronie serwera.

Client — ChangeCipherSpec

wiadomość ChangeCipherSpec jest tylko wiadomością od klienta informującą Serwer, że wszystkie dane wysyłane przez Klienta będą szyfrowane przy użyciu uzgodnionych parametrów bezpieczeństwa. W tym momencie zarówno klient, jak i serwer mają wszystkie składniki niezbędne do wygenerowania master secret, a następnie uzyskania kluczy sesji kryptograficznej.
obie strony sprawdzają, czy uścisk dłoni przebiegł zgodnie z planem i czy obie wygenerowały identyczne klucze, wysyłając ostateczną zaszyfrowaną wiadomość informującą o aktywacji szyfru.

Client — Finished

najpierw klient wysyła zaszyfrowaną gotową wiadomość do serwera. Ta wiadomość jest kryptograficznym skrótem (message digest) wszystkich poprzednich wiadomości uzgadniania łącznie, a następnie specjalnym numerem identyfikującym rolę klienta, tajemnicę główną i wypełnienie. Jest to szyfrowane nowo wygenerowanym kluczem sesji i wysyłane na serwer.

Server — ChangeCipherSpec

teraz serwer wysyła wiadomość ChangeCipherSpec z powrotem do klienta, aby poinformować klienta, że wszystkie dane po tej wiadomości zostaną zaszyfrowane.

Server — Finished

Po wiadomości ChangeCipherSpec następuje zaszyfrowana wiadomość Finished z serwera do klienta. Jest to kryptograficzny hash generowany przez serwer, wszystkich komponentów używanych podczas procesu hanshake wraz ze specjalnym numerem identyfikującym rolę serwera.