What does this part of a curl -v log tell you about the connection?

* successfully set certificate verify locations:
*   CAfile: garagedoor.cert
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* Server certificate:
*  subject: C=CH; ST=Luzern; L=Luzern; O=HSLU; OU=IOTLab; CN=192.168.16.33
*  start date: Oct 21 18:01:51 2020 GMT
*  expire date: Nov 20 18:01:51 2020 GMT
*  common name: 192.168.16.33 (matched)
*  issuer: C=CH; ST=Luzern; L=Luzern; O=HSLU; OU=IOTLab; CN=192.168.16.33
*  SSL certificate verify ok.
> POST /opengaragedoor HTTP/1.1

curl trusted only garagedoor.cert, negotiated TLS 1.2 with an ECDHE-RSA AES-GCM suite, received a self-signed certificate (issuer equals subject) for the IP it connected to, verified it, and only then sent the POST inside the encrypted channel.

Reading it line by line:

• CAfile: garagedoor.cert: the trust store for this call is just that one file (--cacert). curl will accept the server only if its certificate chains to it, and a self-signed certificate chains to itself.
• TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256: the negotiated protocol version and cipher suite (decoded in the next card).
• subject = issuer: the tell-tale of a self-signed certificate.
• Start and expire date 30 days apart: OpenSSL's default validity.
• common name: 192.168.16.33 (matched): the name in the certificate equals the address in the URL. Without this check, any certificate the client trusts could be used to pose as any server.
• SSL certificate verify ok: signature, trust and name checks all passed.
• > POST /opengaragedoor: only now is the request sent, encrypted. curl prints it because it is the endpoint; on the wire it is unreadable.

The earlier lines in the same log (Client hello (1), Server hello (2), Certificate (11), Server key exchange (12), …) are the handshake messages with their type numbers from the TLS specification.

Go deeper:

• curl — SSL certificate verification — how curl verifies peers, --cacert, and why -k must not be used in production.