Walk through what happens in a TLS handshake.

The client opens with a ClientHello advertising its supported protocol versions, cipher suites, and a random value. The server replies with a ServerHello selecting the cipher suite and its own random, and sends its certificate (and any intermediate certificates). The client validates that certificate chain, that it chains up to a CA in the client's trust store, is within its validity dates, matches the expected hostname/identity, and isn't revoked, aborting if any check fails. Then the two perform a key exchange, typically ephemeral Elliptic Curve Diffie-Hellman (ECDHE), which lets both sides derive the same shared secret without ever sending it on the wire, and from that they derive the symmetric session keys. They confirm the handshake (verifying nothing was tampered with), switch to symmetric encryption, and only then exchange application data. The key conceptual split is that the expensive asymmetric cryptography is used once, at the handshake, to authenticate the server and agree on keys, while the cheap symmetric cryptography protects all the actual traffic, and using ephemeral key exchange (ECDHE) gives forward secrecy, so capturing today's traffic doesn't let an attacker decrypt it later even if the server's long-term private key is later compromised. (TLS 1.3 streamlines this into fewer round-trips, but the authenticate-then-key-then-encrypt shape holds.)