The server gets a private key and a certificate and serves HTTPS. Every client (the ESP32 firmware and the laptop's curl) gets a copy of that certificate as its trust anchor and refuses any server that cannot prove it holds the matching key.

* The certificate is public and goes to every client; the key never leaves the server. *

"End to end" means the protection runs from the device's program to the server's program, so nothing between them (the open Wi-Fi, the access point, anyone who has joined the network) can read or change the commands. The work, in order:

1. Make an identity for the server. openssl generates a key pair and a self-signed certificate that binds the public key to the server's address.
2. Server: load the key and the certificate and listen with TLS. In Node.js that is https.createServer({ key, cert }, app) instead of http.createServer(app). The routes, such as POST /opengaragedoor, stay the same.
3. ESP32 client: embed the certificate in the firmware, switch the URL from http:// to https://, and hand the certificate to the HTTP client so it can verify the server. Then rebuild and flash, because the certificate is now part of the image.
4. Laptop client: tell curl to trust that same certificate: curl --cacert garagedoor.cert -X POST https://<server>:8080/opengaragedoor.
5. Check with Wireshark that the captured packets now show a TLS handshake and encrypted records instead of readable HTTP.

Nothing about the buttons, the FreeRTOS tasks or the door logic changes. TLS sits between TCP and HTTP, so the application keeps sending the same requests and the library underneath encrypts them.

Go deeper:

• Node.js — HTTPS — https.createServer() with a key and certificate read from files.
• ESP-IDF — ESP HTTP Client — HTTPS requests from the ESP32 and the cert_pem field for verifying the server.

SSL is the old Netscape protocol; TLS is its standardised successor. Every SSL version and TLS 1.0/1.1 are deprecated. Use TLS 1.2 or TLS 1.3. "SSL certificate" is just the everyday name for the X.509 certificate TLS uses.

The name SSL survives everywhere: "SSL certificate", the library OpenSSL, curl's SSL connection using … line. None of that means the old protocol is in use. A certificate is not tied to a protocol version at all; the same certificate works for TLS 1.2 and 1.3.

For an ESP32, both TLS 1.2 and 1.3 are available through mbedTLS in ESP-IDF. TLS 1.2 is the more widely supported default; TLS 1.3 saves a round trip on every new connection, which matters on battery.

Go deeper:

• Wikipedia — Transport Layer Security — history from SSL to TLS 1.3 and the attacks that retired each old version.
• RFC 8996 — Deprecating TLS 1.0 and TLS 1.1 — why the two old TLS versions must no longer be negotiated.