Description
What is TLS?
Transport Layer Security (TLS) is the standard protocol for securing a connection between two machines on a network. It does three jobs: it authenticates the server (and optionally the client) with an X.509 certificate, it agrees fresh session keys, and it encrypts and integrity-protects everything sent over the connection. HTTPS is simply HTTP carried inside TLS. TLS replaced the older SSL protocol, which is why people still say "SSL certificate".
Two versions matter today. TLS 1.2 (2008) is still widely deployed; TLS 1.3 (RFC 8446, 2018) removed legacy ciphers, makes every key exchange forward-secret and completes a full handshake in one round trip. TLS 1.0 and 1.1 were deprecated by RFC 8996 in 2021. In a TLS 1.3 handshake the client sends its supported cipher suites and a key share, the server answers with its own key share and certificate chain, both derive the same keys, and the client checks that the certificate chains to a trusted certificate authority (CA) and matches the hostname.
In a WhatsApp integration TLS protects every hop: your servers calling graph.facebook.com, Meta POSTing webhooks to your endpoint, and your own internal calls. Meta requires the webhook URL to use HTTPS with a valid certificate that is correctly installed — self-signed certificates are not supported — and always verifies your server's certificate. TLS ends wherever it is terminated, usually a load balancer, and that machine sees plaintext. That is the difference from end-to-end encryption, which keeps content unreadable to every server in between, and from webhook mTLS, which adds a certificate check in the other direction.
Key takeaways
- TLS encrypts and authenticates a single connection between two machines; HTTPS is HTTP running inside TLS.
- Use TLS 1.2 or 1.3 only: TLS 1.0 and 1.1 were formally deprecated in 2021.
- Meta delivers webhooks only to HTTPS URLs with a valid, correctly installed certificate; self-signed certificates are not supported.
- Public certificates issued since 15 March 2026 last at most 200 days, falling to 100 days in 2027 and 47 days in 2029.
- TLS protects each hop, and whoever terminates it can read the data — unlike end-to-end encryption.
Usage
TLS in code
# Which certificate does the webhook endpoint present, and when does it expire?openssl s_client -connect webhooks.example.com:443 -servername webhooks.example.com </dev/null 2>/dev/null \| openssl x509 -noout -subject -issuer -dates# Is the full chain served and trusted? Expect "Verify return code: 0 (ok)"openssl s_client -connect webhooks.example.com:443 -servername webhooks.example.com </dev/null 2>/dev/null \| grep "Verify return code"# Does it negotiate TLS 1.3?openssl s_client -connect webhooks.example.com:443 -servername webhooks.example.com -tls1_3 </dev/null 2>/dev/null \| grep -E "^ *Protocol"
Mechanics
How does TLS work?
step 1 — Client hello
The client opens a TCP connection and proposes TLS versions, cipher suites and a key share, plus the hostname it wants to reach (Server Name Indication).
step 2 — Server hello and certificate
The server picks the version and cipher, sends its own key share and certificate chain, and proves it holds the private key by signing the handshake.
step 3 — Certificate verification
The client checks the chain up to a trusted root CA, the validity dates and that the hostname matches. Meta does this to your webhook endpoint; your HTTP client must do it to Meta.
step 4 — Keys derived, data flows
Both sides derive the same session keys from the key exchange. Every request and response is then encrypted with an AEAD cipher such as AES-GCM or ChaCha20-Poly1305.
step 5 — Termination
At the far end, whatever terminates TLS — a load balancer, reverse proxy or the app itself — decrypts the traffic. Anything beyond that point needs its own TLS hop to stay encrypted.
Properties
TLS: key facts and limits
- Current versions
- TLS 1.3 (RFC 8446, 2018) and TLS 1.2 (2008)
- Deprecated
- TLS 1.0 and 1.1 (RFC 8996, 2021)
- TLS 1.3 handshake
- One round trip
- Webhook URL
- HTTPS, valid CA-signed certificate, no self-signed
- Max public certificate life
- 200 days since 15 Mar 2026; 100 days from 2027; 47 from 2029
- Default port
- 443
Example
Example: The Friday the webhooks went quiet
A Kochi travel agency's webhook certificate expired on a Friday evening. Meta's TLS checks against its endpoint began failing, so inbound customer messages and delivery statuses stopped reaching the inbox — while outbound sends, which use the agency's own TLS connection to the Graph API, kept working and hid the problem. By Saturday morning agents noticed silent chats; renewing the certificate let Meta's retries deliver the backlog. The fix that stuck: automated certificate renewal, a full-chain check in CI and an expiry alert at 14 days.
Caveats
Common mistakes with TLS
Serving the leaf certificate without its chain
Browsers often fill in missing intermediates; Meta's servers and many HTTP clients do not. Serve the full chain (leaf plus intermediates) and test with
openssl s_clientbefore saving the callback URL.Disabling certificate verification to silence an error
Settings like
NODE_TLS_REJECT_UNAUTHORIZED=0orverify=Falselet anyone in the network path impersonate the Graph API and capture your access token. Fix the trust store instead.Renewing certificates by hand
With public certificate lifetimes capped at 200 days and shrinking, a manual renewal will eventually be missed and webhooks will stop. Automate issuance and renewal and alert two weeks before expiry.
Calling TLS end-to-end encryption
TLS ends at your load balancer or CDN, which can read everything. Encrypt internal hops that cross networks, and describe the design accurately in security reviews.
Why it matters
Why does TLS matter?
A webhook endpoint with an expired certificate, a missing intermediate or a self-signed certificate simply stops receiving events: Meta's TLS check fails and notifications pile up in retries. On the outbound side, a client that skips certificate verification can be fooled into sending its access token to an impostor. Getting TLS right — modern versions, a complete chain from a public CA and automated renewal — is the quiet foundation every other control in the integration relies on.
Notes
Best practices for TLS
- Disable TLS 1.0 and 1.1 everywhere; allow TLS 1.2 and 1.3.
- Treat certificate expiry on the webhook hostname as a production alert, not a calendar reminder.
- If a CDN or load balancer terminates TLS, re-encrypt to the origin whenever the hop leaves your private network.
- Keep private keys in a secret store or the load balancer's certificate manager, never in the repository.
Questions
TLS FAQs
- Is SSL the same as TLS?
- In practice, yes: TLS is the modern successor to SSL. Every SSL version is long obsolete, and what people call an "SSL certificate" is a certificate used with TLS.
- Can I use a self-signed certificate for my WhatsApp webhook?
- No. Meta does not support self-signed certificates for webhook callback URLs; the endpoint needs a valid certificate from a public certificate authority, correctly installed with its intermediate chain.
- Does TLS mean my WhatsApp messages are end-to-end encrypted?
- No. TLS protects each connection, such as Meta's webhook POST to your server, but whoever terminates TLS can read the content. WhatsApp's end-to-end layer is the Signal Protocol between the user's device and the Cloud API.
- Which TLS versions should my webhook endpoint support?
- Support TLS 1.3 and TLS 1.2, and disable TLS 1.0 and 1.1. That covers modern clients while removing the protocol versions deprecated in 2021.