เข้ารหัสด้วย TLS และตรวจสอบใบรับรอง

Data crossing WiFi and the internet passes many hands. Encryption scrambles it so only the intended server can read your readings. 🔒

TLS is the layer that turns HTTP into HTTPS. It encrypts the channel between your device and a server so eavesdroppers see only noise.

Before any data flows, the two sides agree on keys in a handshake. This setup proves the server's identity and locks in a shared secret.

A server presents a certificate signed by a trusted authority. It proves the server really is who it claims to be, not an imposter.

Encrypting but skipping checks is dangerous. Without verification, an attacker can sit in the middle, hold the keys, and read everything.

A man-in-the-middle impersonates the server and relays your traffic. Verifying the certificate is exactly what stops this attack cold.

On the ESP32, WiFiClientSecure handles TLS connections. It is the secure cousin of the plain client you used for HTTP.

Give your device the server's root certificate so it can verify trust. This pinned CA is how the board knows the server is genuine.

Calling setInsecure turns off all verification. setInsecure is fine for a quick test but should never reach a shipped product.

Every certificate has an expiry date, so verification needs the right time. A device with the wrong clock may wrongly reject a valid server.

TLS is not just for HTTPS. Point your MQTT client at a TLS broker port like 8883 to protect your pub/sub messages the same way.

Encryption alone is not enough. What else matters?

TLS encrypts traffic and certificates prove identity. Use WiFiClientSecure, pin a trusted CA, keep the clock right, and never ship setInsecure. 🛡️