What are the main steps of a TLS handshake and the role of certificates?

• A. Client sends hello; server presents certificate; certificate chain is validated; key exchange occurs (DHE/ECDHE); session keys are derived; secure symmetric encryption starts; certificate chain validation must succeed.
• B. TLS handshake only negotiates cipher; certificates are not involved.
• C. Server sends data first; client responds with cookies; no certificates needed.
• D. Client and server exchange passwords; certificate is optional.

Answer: (A)

TLS handshakes are about establishing trust and a fresh, secret connection between client and server. The client first proposes what it can support, including the protocol version and cipher suites. The server then picks a version and a cipher and sends its certificate chain to prove it is who it says it is. The client must validate that chain against trusted roots, check that the certificate is valid for the server’s hostname, and ensure it hasn’t expired or been revoked. This step ensures the client can trust the server before any secrets are shared.

Once trust is established, the client and server perform a key exchange. If they use ephemeral Diffie-Hellman (DHE or ECDHE), the server’s certificate is used to sign the exchange parameters, providing server authentication while enabling a forward-secure secret: a shared premaster secret that both sides combine with their random values to derive the actual session keys. From that premaster secret and the random values exchanged during the handshake, they derive symmetric encryption keys and MAC keys for protecting all subsequent data. After they verify the handshake with Finished messages, they switch to the negotiated symmetric encryption, and application data is exchanged securely.

The role of certificates here is to authenticate the server’s identity and to enable the secure key exchange. The certificate chain ties the server’s public key to a trusted authority, ensuring the client can trust the server. Depending on the method, the certificate’s public key either helps encrypt the exchange material or signs the exchange parameters, but in all cases it anchors trust before any sensitive data is transmitted.

Other options don’t fit because TLS isn’t just about negotiating a cipher; it always involves certificate-based authentication and a cryptographic exchange to derive session keys. Data isn’t sent before the handshake completes, and TLS typically doesn’t rely on passwords for session key establishment (unless using a very specific, nonstandard configuration). While client certificates can be used, they are not mandatory for standard server authentication, and certificates are not optional in the normal TLS handshake focused on trust and key establishment.