How does a certificate file get "embedded on the client side" of an ESP-IDF project, and how does the HTTP client use it?

List the PEM file under EMBED_TXTFILES in the component's CMakeLists.txt; the build links it into the firmware as a null-terminated string reachable through _binary_<name>_start. Pass that string as cert_pem in esp_http_client_config_t, and the client verifies the server against it.

The build system can link any file into the image:

idf_component_register(SRCS "main.c"
                       INCLUDE_DIRS "."
                       EMBED_TXTFILES garagedoor.cert)

The file's name becomes a symbol, with . and / turned into _:

extern const char garagedoor_cert_start[] asm("_binary_garagedoor_cert_start");

esp_http_client_config_t cfg = {
    .url      = "https://192.168.16.33:8080/opengaragedoor",
    .method   = HTTP_METHOD_POST,
    .cert_pem = garagedoor_cert_start,   /* trust exactly this certificate */
};

Why each choice:

• EMBED_TXTFILES, not EMBED_FILES: the text variant adds a terminating zero byte, and cert_pem is read as a C string. A PEM file (the Base64 text between -----BEGIN CERTIFICATE----- lines, which openssl req writes by default) is text.
• Compiled in, not downloaded: the certificate is the client's trust anchor. Fetching it over the same network it is meant to protect would let an attacker supply their own.
• A rebuild is needed for every certificate change, since the certificate lives in the binary.

If no verification option is set at all, ESP-TLS aborts the connection with a fatal error by default. Skipping verification requires deliberately enabling an "insecure" option meant only for testing.

Go deeper:

• ESP-IDF — Build system: embedding binary data — EMBED_FILES, EMBED_TXTFILES and the generated symbol names.
• ESP-IDF — ESP-TLS — the server-verification options and what happens when none is chosen.