Once the garage door uses TLS with a server certificate, which of the private, authentic and secure channels does it provide? Can an attacker still open the door?

Only the private direction plus server authentication: the client knows it is talking to the real server and that only the server reads the request. The server does not know who the client is. Anyone who can reach the server and knows the endpoint can open a TLS connection and send POST /opengaragedoor; the fix is client authentication (mutual TLS or a per-device credential).

* TLS as usually deployed authenticates one end: the server. *

Recall the three channel types: a private channel guarantees only the receiver can read; an authentic channel guarantees the receiver knows who sent the message; a secure channel does both.

The attack that remains needs no cryptography. The server's certificate is public (it is sent in every handshake), and curl -k does not even need it. What the attacker lacks is only the path, and with physical access to the device the firmware can be dumped and searched for it. Then curl -X POST https://<server>:8080/opengaragedoor opens the door.

Ways to authenticate the client:

• Mutual TLS: the server asks for a client certificate (requestCert: true, rejectUnauthorized: true, and ca set to the device CA in Node.js), and the ESP32 presents its own (client_cert_pem, client_key_pem).
• A secret inside the TLS channel: a per-device token or an HMAC over each command, which TLS keeps confidential.

Either way the client's secret now sits in the device's flash, which is why flash encryption matters once an attacker has physical access.

Go deeper:

• Wikipedia — Mutual authentication — mTLS and certificate-based device authentication in IoT.
• Node.js — TLS — the server options requestCert, rejectUnauthorized and ca that turn on client-certificate checking.