Security & TLS
How can ESP-TLS skip server certificate verification?
In ESP-TLS on ESP32, server certificate verification can be skipped for quickly establishing HTTPS / WSS connections during testing.
Enable the following options in menuconfig:
CONFIG_ESP_TLS_INSECURECONFIG_ESP_TLS_SKIP_SERVER_CERT_VERIFY

After these options are enabled, if esp_tls_cfg_t does not configure any of the following server verification methods, ESP-TLS skips server certificate verification:
cacert_bufuse_global_ca_storecrt_bundle_attach
Example:
esp_tls_cfg_t cfg = {
.cacert_buf = NULL,
.use_global_ca_store = false,
.crt_bundle_attach = NULL,
.timeout_ms = 10000,
};
Security risks:
- The server identity cannot be verified.
- The connection is vulnerable to man-in-the-middle attacks.
- The device may connect to a forged server.
- Data may be intercepted or modified.
Notes:
- Use this only in test environments.
- Do not use it in production.
- Do not use it on public or untrusted networks.
- In production, prefer CA certificates or a certificate bundle for verification.
How can I identify the cause and recover an ESP32-S3 that fails to boot after Flash encryption is interrupted?
Cause:
This issue is usually related to one of the following situations:
- Abnormal flashing: factors such as an unstable power supply may cause the firmware to be written incorrectly, leading to Flash encryption verification failure. Abnormal flashing can also prevent the device from booting even when encryption is not enabled.
- Power loss during encryption: after firmware flashing completes, the chip still needs to perform Flash encryption. If power is removed immediately, the encryption process may be interrupted and the firmware may be corrupted, preventing normal startup when power is restored.
If the eFuse flag described as “Enables flash encryption when 1 or 3 bits are set” has been changed to “Enable R/W 0b001”, the device will no longer accept plaintext firmware.
Solution:
Whether recovery is possible depends on whether DIS_DOWNLOAD_MANUAL_ENCRYPT has disabled download-mode encryption:
- In development mode, this disabling bit has not been programmed. Use the --encrypt option of esptool to flash the firmware again. The chip encrypts data written to Flash during downloading using its internal key; the host does not need access to that key.
- In release mode, this bit permanently disables download-mode encryption, and the device accepts only ciphertext firmware. If the host has not retained the key, the device cannot be flashed again and cannot be recovered.
Use the following flashing command:
esptool.exe --port COMx --baud 921600 --before default_reset --after hard_reset write_flash --flash_mode dio --flash_freq 80m --flash_size detect --encrypt 0x0 <固件路径>
Additional notes:
A DIS_DOWNLOAD_MANUAL_ENCRYPT value of 0 means download-mode encryption has not been disabled; 1 means it has been disabled. Do not confuse the DIS prefix with the bit itself being disabled. Recovery as described above also requires ROM download mode and the relevant download features to remain available. The source statement that recovery is impossible applies to interrupted encryption when the device no longer boots and the host has not retained the key. An encrypted device that still runs can update firmware through a supported OTA flow. See the official ESP32-S3 Flash encryption guide.