What is TLS? The handshake, TLS 1.3 and certificates, explained

TLS and SSL: one job, two names

TLS (Transport Layer Security) sits between TCP and HTTP and turns a plain connection into a private one. When an address starts with https://, TLS is what makes it secure; the same protocol protects mail, DNS over TLS and most APIs.

SSL (Secure Sockets Layer) is where it started. Netscape shipped SSL 2.0 in 1995 and SSL 3.0 in 1996. When the IETF took the protocol over, it renamed it: TLS 1.0 (1999) is essentially SSL 3.1. TLS 1.1 followed in 2006, TLS 1.2 in 2008 and TLS 1.3 in 2018.

Every SSL version is now forbidden. SSL 3.0 fell to the POODLE attack in 2014 and was formally prohibited in 2015; TLS 1.0 and 1.1 were deprecated in 2021, after browsers had already dropped them. What is in use today is TLS 1.2 and TLS 1.3.

The old name survives in everyday language. People say "SSL certificate" and mean the certificate a TLS server presents; there is no separate SSL certificate and TLS certificate. It is the same X.509 file, and it works with whichever protocol version the two sides agree on. If you came for the certificate itself, start with free SSL certificates.

What TLS guarantees, and what it does not

TLS gives a connection three properties.

Confidentiality. Everything after the handshake is encrypted with keys only the two ends know. Someone on the same Wi-Fi, at the ISP or on a transit link sees encrypted bytes and nothing else.

Integrity. Every record carries an authentication tag. A byte changed on the way is detected, and the connection is closed instead of handing altered data to the application.

Authentication. The server proves it holds the private key of a certificate issued for the name the browser asked for. This is what stops an attacker from simply answering in your place. The client can be authenticated too, with mutual TLS, but on the public web it rarely is.

What TLS does not do is just as useful to know. It does not hide which server you talk to: IP addresses are visible, and so is the hostname in SNI (more on that below). It does not make the content safe: an SQL injection arrives just as encrypted as a login form, which is a job for a WAF. And it protects data in transit only; once the server has decrypted it, TLS is out of the picture.

The TLS 1.2 handshake: two round trips

Before a single byte of HTTP is sent, browser and server have to agree on a version and a cipher, check the certificate and derive shared keys. That negotiation is the TLS handshake, and in TLS 1.2 it takes two full round trips on top of the TCP connection.

Round trip 1. The browser sends ClientHello: the versions and cipher suites it supports, a random value, and extensions such as SNI and ALPN (which HTTP version it wants). The server answers with ServerHello (the chosen version and cipher), its certificate chain and, with an ECDHE suite, its key-exchange share signed with the certificate's key.

Round trip 2. The browser checks the certificate, sends its own key share, and both sides compute the same session keys. Each then sends Finished, a checksum over everything exchanged so far, so a handshake someone tampered with fails right here.

Only now can the first request go out. Count the TCP handshake as well and a new HTTPS connection over TLS 1.2 spends three round trips before the browser can even ask for the page. At 20 ms per round trip nobody notices; on a mobile link with 150 ms between visitor and server it is close to half a second. That is one reason CDNs terminate TLS at the edge rather than at a distant origin: the round trips the handshake needs become short ones.

TLS 1.3: one round trip, and less to get wrong

TLS 1.3 (RFC 8446, 2018) is built on one observation: the browser can guess. Nearly every server supports the same few key-exchange groups, so the browser sends its key share inside the ClientHello instead of waiting to be asked.

The server picks a cipher and answers with its own key share, and from that moment both sides have the keys. Everything after ServerHello, the certificate included, is already encrypted. The browser checks the certificate, sends Finished and puts its first request right behind it: one round trip for TLS, two in total with TCP. Over HTTP/3, where QUIC carries TLS 1.3 inside its own handshake, transport and encryption together take one.

If the guess is wrong, because the server wants a group the browser sent no share for, the server replies with a HelloRetryRequest and the handshake costs one extra round trip. With X25519 offered by practically every browser, that is rare.

The other half of TLS 1.3 is what it removed.

RSA key exchange is gone. Every handshake uses ephemeral (EC)DHE, so every connection has forward secrecy: a private key stolen next year cannot decrypt traffic recorded today.

Only AEAD ciphers remain: AES-GCM and ChaCha20-Poly1305. CBC mode, RC4, 3DES, SHA-1 and MD5 are not part of the protocol at all.

Renegotiation and compression are gone, and with them whole families of attacks.

TLS 1.3 also carries downgrade protection: a TLS 1.3 server pushed to an older version marks its reply, and a TLS 1.3 client that sees the mark aborts. When both sides speak 1.3, they use it; there is no "prefer 1.3" switch to remember.

0-RTT and resumption: the fast path and its catch

A visitor who has connected before does not need the full handshake. At the end of a TLS 1.3 handshake the server can hand the browser a session ticket; next time the browser presents it, and both sides skip the certificate and the expensive key agreement. That is session resumption, and it still takes one round trip.

0-RTT (early data) goes one step further. With the ticket, the browser encrypts its first request using keys from the previous session and sends it in the same flight as the ClientHello. The server can answer at once, so the request waits for no handshake at all.

The catch is replay. Early data is sent before the server has said anything on this connection, so it contains nothing fresh from the server. An attacker who records that first flight can send it again, and the server sees a valid request twice. For a GET of a stylesheet that is harmless; for a POST that places an order, moves money or changes a password it is not. Early data is also not forward-secret: whoever later obtains the ticket key can decrypt it.

The rules follow from that. Accept 0-RTT only for idempotent requests (GET and HEAD without side effects). Let the server or proxy mark early-data requests, with the Early-Data: 1 header and the 425 Too Early status from RFC 8470, so the application can refuse to act on them. And never treat 0-RTT as a free speed-up to switch on everywhere.

The CDN.com.tr edge does not accept 0-RTT early data, so the replay question never reaches your application. A returning visitor resumes the session with a one-round-trip TLS handshake instead.

Certificates and the chain of trust

The certificate is how the server proves who it is. It binds a public key to one or more hostnames, listed in its Subject Alternative Name field, carries a validity period, and is signed by a certificate authority (CA).

Browsers do not trust your certificate directly. They trust a few dozen root certificates in their trust store, and roots do not sign website certificates themselves: they sign intermediates, and an intermediate signs yours. The browser has to build a path from your certificate up to a root it knows: leaf (your certificate, for www.example.com) → intermediate (the CA's issuing certificate) → root (in the trust store).

The server is expected to send the leaf and the intermediates. Leaving out the intermediate is the classic broken setup: desktop browsers often still work, because they have cached the missing certificate or can fetch it, while curl, Android apps, payment callbacks and API clients fail with "unable to get local issuer certificate". When something works in your browser but not from a server, check the chain first.

A real example: on 7 October 2026, cdn.com.tr served a Let's Encrypt certificate signed by the intermediate YR1, which chains to ISRG Root YR, and the server also sent Root YR cross-signed by ISRG Root X1, the root browsers have trusted for years. The cross-signature is what lets a brand-new root work on devices that have never heard of it.

Validity. Let's Encrypt certificates last 90 days, and the whole industry is heading the same way: under the CA/Browser Forum rules adopted in 2025, the maximum lifetime of a public certificate fell to 200 days in March 2026 and will be 47 days by 2029. Renewal is no longer a yearly chore; it is a process that has to run by itself.

DV, OV, EV. The validation level decides what the CA checked (control of the domain only, or the organisation as well), not how strong the encryption is. A free domain-validated certificate and an expensive EV certificate produce exactly the same TLS connection.

SNI: many HTTPS sites on one IP address

Early HTTPS had a chicken-and-egg problem. The server must present a certificate during the handshake, but the hostname the visitor wants arrives in the HTTP Host header, after the handshake. So every HTTPS site needed an IP address of its own.

SNI (Server Name Indication) solves this by putting the hostname into the ClientHello. The server reads it before choosing a certificate, which is how one address can host thousands of HTTPS sites, each with its own certificate. Every CDN and every shared host depends on it, and every browser of the past decade sends it.

Two consequences are worth knowing.

A client without SNI gets the default certificate. Very old clients, some embedded devices, and scripts that connect to an IP address without naming a server receive whatever certificate the server falls back to, and then fail with a name mismatch. When you test with openssl, always pass -servername.

SNI is not encrypted. The hostname travels in plain text inside the ClientHello, so a network can see, and filter by, which site you are opening, even though it cannot see the page. This is how SNI-based blocking works. Encrypted Client Hello (ECH) is the extension that hides it, and browsers have begun to ship it; until it is everywhere, assume the hostname is visible.

Cipher suites: how to read the names

A cipher suite names the algorithms a connection uses. TLS 1.2 packs four choices into one name.

ECDHE-RSA-AES128-GCM-SHA256 means: key exchange ECDHE (ephemeral elliptic-curve Diffie-Hellman, which gives forward secrecy), authentication RSA (the key type of the certificate), bulk encryption AES-128 in GCM mode (an AEAD cipher: encryption and integrity in one step), and SHA-256 for deriving the keys.

TLS 1.3 names are shorter, because key exchange and signature are negotiated separately, and only five suites exist, three of them in real use: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256. All are AEAD and all come with forward secrecy, so there is nothing left to tune.

A good TLS 1.2 list has ECDHE key exchange and AEAD ciphers at the top, nothing with RC4, 3DES, MD5, NULL or EXPORT in it, and the server choosing from its own order instead of following the client's. Older CBC suites are often kept at the bottom for very old clients; when the server chooses, a modern browser never lands on them. A scanner lists everything a server offers; to see what a real connection uses, look at the negotiated suite with the commands at the end of this guide.

ChaCha20-Poly1305 exists for devices without hardware AES, mostly older phones, where it runs faster than AES-GCM in software.

Common TLS errors and what they really mean

ERR_SSL_PROTOCOL_ERROR (Chrome): the handshake broke in a way the browser could not classify. The usual causes are something other than TLS answering on port 443 (plain HTTP, a captive portal), antivirus software or a middlebox intercepting the connection, or a server with no certificate for that hostname. Try another network first; if it fails on one network only, the server is not the problem.

ERR_SSL_VERSION_OR_CIPHER_MISMATCH, in Firefox SSL_ERROR_NO_CYPHER_OVERLAP: client and server share no version or cipher suite. Today that almost always means one side is very old, such as an embedded device that only speaks TLS 1.0 or a server still configured for it.

ERR_CERT_COMMON_NAME_INVALID: the certificate does not list the hostname you opened. Typical when DNS already points a new subdomain at a server that has no certificate for it yet, or when www is missing from the certificate.

ERR_CERT_DATE_INVALID: the certificate has expired, or the visitor's clock is wrong. If one person sees it, check their clock; if everyone does, renewal has stopped.

unable to get local issuer certificate (curl, OpenSSL and many SDKs): the server did not send its intermediate certificate. Fix the chain on the server, not the trust store on the client.

A 502 from a proxy or CDN while the browser shows a valid padlock: the visitor's TLS was fine, but the proxy's own connection to your origin failed. That is a separate handshake with its own certificate and versions; the 502 Bad Gateway guide walks through it.

How CDN.com.tr terminates TLS at the edge

With your site behind CDN.com.tr, the visitor's TLS connection ends at a CDN.com.tr edge server, not at your origin: the edge holds your certificate and runs the handshake. This is what it does for every hostname, with no per-site setting to forget.

TLS 1.2 and TLS 1.3 only. TLS 1.0 and 1.1 are refused at the handshake, not downgraded. The edge chooses the cipher from its own list, with ECDHE key exchange and AEAD ciphers first; in our test on 7 October 2026, TLS 1.3 negotiated TLS_AES_256_GCM_SHA384 over X25519. The policy is identical for every account, and the TLS policy page has the details security questionnaires ask for.

HTTP/3 for every site. HTTP/3 runs over QUIC, which has TLS 1.3 built in. Browsers learn about it from the Alt-Svc header and switch on their next connection; there is nothing to enable. More in HTTP/3 and IPv6.

A certificate per hostname, chosen by SNI. Each of your hostnames is served with its own certificate.

Let's Encrypt, issued and renewed for you. With Auto SSL, a certificate is requested once your domain is verified and its DNS points to us, and it is renewed automatically 30 days before it expires. When your domain's DNS is on CDN.com.tr, the certificate can be a wildcard covering the root domain and every first-level subdomain, validated with a DNS record. Moving a live site? The zero-downtime wizard issues that wildcard through a TXT record at your current DNS provider before you switch, so HTTPS works from the first second.

Your own certificate when you need one. An OV or EV certificate bought elsewhere can be uploaded and attached to a hostname, and it gets exactly the same TLS policy.

A separate TLS connection to your origin. By default an HTTPS request is fetched from your origin over HTTPS as well, through the edge's own connection to your origin's HTTPS port. Visitors never see that handshake; if it fails, they get a 502, not a certificate warning.

HSTS when you are ready. Once everything works over HTTPS, the HSTS security preset tells browsers never to try plain HTTP on your hostname again.

Check any site's TLS in a minute

Five commands answer most TLS questions: which version and cipher a real connection uses, which chain the server sends, when the certificate expires, whether old versions are refused, and how long the handshake takes. Replace www.example.com with your hostname and keep -servername; without it you test the server's default certificate instead of yours.

Version, cipher, chain, expiry and handshake time from the command line

# Negotiated version and cipher
openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null | grep -E "Protocol|Cipher is"

# The chain the server sends: subject (s:) and issuer (i:) of each certificate
openssl s_client -connect www.example.com:443 -servername www.example.com -showcerts </dev/null 2>/dev/null | grep -E "^ *[0-9]+ s:|^ *i:"

# When the certificate expires
openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null | openssl x509 -noout -enddate

# TLS 1.1 must be refused (SECLEVEL=0 stops your own OpenSSL from refusing first)
openssl s_client -connect www.example.com:443 -servername www.example.com -tls1_1 -cipher 'DEFAULT:@SECLEVEL=0' </dev/null

# Seconds spent on TCP and on TCP + TLS
curl -so /dev/null -w 'tcp %{time_connect}  tls %{time_appconnect}\n' https://www.example.com/