Open this lesson in your favourite AI. It'll walk you through the why, explain the demo, and quiz you on the try-it list.
Every TLS misconfiguration becomes a customer-facing outage that bypasses your monitoring — browsers fail closed and your APMs see nothing. Knowing the handshake means you can read a openssl s_client dump and find the broken intermediate cert in under a minute, instead of paginating through CloudWatch.
Inspect a live TLS handshake and the certificate chain a cloud load balancer presents.
openssl s_client -connect <your-domain>:443 and identify the leaf, intermediate, and root certs by their Subject lines.-tls1_2 and TLS 1.3 with -tls1_3 — note which cipher suites each version negotiates.-reconnect and confirm whether your server issued a session ticket (look for New, vs Reused, lines).Use these three in order. Each builds on the one before.
In one paragraph, explain the TLS handshake like I'm new to it — what does the client and server actually exchange to agree on a key?
Walk me through a TLS 1.3 handshake step by step, including ClientHello, ServerHello, key share, and the difference from TLS 1.2.
Given a customer reporting `SEC_ERROR_UNKNOWN_ISSUER` for your domain on Android 7, but everything works on macOS, diagnose and propose a fix involving the chain you serve.
# ACM certificates and their SAN coverage
aws acm list-certificates --query 'CertificateSummaryList[*].[DomainName,Status]'
# Full handshake details — version, cipher, chain
openssl s_client -connect example.com:443 -servername example.com -showcerts < /dev/null
# Check supported TLS versions on an ALB
nmap --script ssl-enum-ciphers -p 443 example.com
# Verify session resumption (ticket vs ID)
openssl s_client -connect example.com:443 -reconnect < /dev/null 2>&1 | grep -i "reused\|new"