HTTPS-Requests am ESP32: Sicherer Datentransfer mit SSL-Zertifikaten

HTTPS-Requests am ESP32 sind der Standard, wenn Sensordaten, Steuerbefehle oder Konfigurationswerte sicher über das Internet oder ein internes Netz übertragen werden sollen. Im Gegensatz zu unverschlüsseltem HTTP schützt HTTPS die Verbindung durch TLS (früher „SSL“ genannt) vor Mitlesen und Manipulation. Das ist besonders wichtig, weil IoT-Geräte oft dauerhaft laufen, selten überwacht werden und im schlimmsten Fall ein Einfallstor ins Netzwerk darstellen können. Der ESP32 ist leistungsfähig genug, um TLS-Verbindungen aufzubauen, Zertifikate zu prüfen und Daten sicher zu senden – allerdings nur, wenn Sie Zertifikate korrekt handhaben und typische Fehlerquellen vermeiden. In der Praxis scheitern viele Projekte nicht am HTTPS-Request selbst, sondern an Details wie abgelaufenen Root-Zertifikaten, falscher Uhrzeit, zu knappem RAM, unpassenden TLS-Versionen oder „Quick-&-Dirty“-Workarounds wie deaktivierter Zertifikatsprüfung. Dieser Leitfaden zeigt, wie Sie HTTPS auf dem ESP32 sauber umsetzen: von CA-Zertifikaten und Fingerprints über Server Name Indication (SNI) bis hin zu robustem Error-Handling und Best Practices, die auch im Dauerbetrieb stabil bleiben.

HTTPS, TLS, SSL: Begriffe korrekt einordnen

Um Missverständnisse zu vermeiden, lohnt eine kurze Einordnung. HTTPS ist HTTP über TLS. „SSL“ ist historisch und wird umgangssprachlich noch häufig verwendet, technisch sprechen moderne Implementierungen jedoch von TLS. TLS sorgt für Vertraulichkeit (Verschlüsselung), Integrität (Schutz vor Manipulation) und Authentizität (Serveridentität über Zertifikate). Die zugrunde liegenden Standards sind öffentlich dokumentiert, z. B. für TLS 1.3 in RFC 8446 (TLS 1.3) und für Zertifikatsstrukturen in RFC 5280 (X.509).

• HTTP: unverschlüsselt, Inhalte sind im Netzwerk lesbar und veränderbar.
• HTTPS: HTTP über TLS, Daten sind verschlüsselt und gegen Manipulation geschützt.
• Zertifikate: bestätigen die Serveridentität über eine Vertrauenskette (CA → Zwischenzertifikat → Serverzertifikat).

Welche Optionen Sie am ESP32 haben: Arduino vs. ESP-IDF

Der ESP32 wird häufig in zwei Entwicklungswelten genutzt: Arduino-ESP32 und ESP-IDF. Beide ermöglichen HTTPS, unterscheiden sich aber in Kontrolle und Komfort. Arduino bietet schnellen Einstieg über Klassen wie „WiFiClientSecure“, während ESP-IDF tiefergehende Konfiguration und Diagnosemöglichkeiten bietet (z. B. für mbedTLS, HTTP-Client, Zertifikatsspeicher und Debug-Logs).

• Arduino-ESP32: gut für schnelle Prototypen, viele Beispiele, einfache HTTPS-Requests.
• ESP-IDF: produktnäher, bessere Kontrolle über TLS-Parameter, detailliertere Fehleranalyse.

Offizielle Einstiege: Arduino-ESP32 Dokumentation und ESP-IDF Programmierhandbuch.

Die wichtigste Entscheidung: Wie prüft der ESP32 das Serverzertifikat?

Ein HTTPS-Request ist nur dann wirklich sicher, wenn der ESP32 das Serverzertifikat korrekt verifiziert. Dabei gibt es mehrere Strategien, die sich in Sicherheit, Wartbarkeit und Aufwand unterscheiden. Für professionelle Systeme gilt: „Zertifikatsprüfung aus“ ist keine Option, weil damit Man-in-the-Middle-Angriffe trivial werden.

• CA-Zertifikat (Root/Intermediate) einbinden: Der ESP32 prüft die Zertifikatskette bis zur vertrauenswürdigen CA. Das ist meist die beste Balance aus Sicherheit und Wartbarkeit.
• Zertifikats-Pinning: Der ESP32 akzeptiert nur ein bestimmtes Zertifikat oder einen bestimmten Public Key. Sehr sicher gegen fremde CAs, aber wartungsintensiv bei Zertifikatserneuerung.
• Fingerprint-Pinning: Bindung an einen Hash-Fingerprint (z. B. SHA-256). Funktioniert, ist aber bei häufigen Zertifikatswechseln unpraktisch.

Wenn Sie öffentliche Zertifikate nutzen (z. B. Let’s Encrypt), ist CA-basierte Verifikation oft am sinnvollsten, weil Zertifikate regelmäßig erneuert werden und sich Fingerprints ändern. Für Let’s Encrypt als weit verbreitete CA ist die offizielle Informationsquelle: Let’s Encrypt.

CA-Zertifikate auf dem ESP32: Trust Store, Speicher und Update-Strategie

Auf Desktop-Systemen existiert ein großer Zertifikatsspeicher (Trust Store) mit vielen Root-CAs. Auf dem ESP32 müssen Sie bewusst entscheiden, welche CAs Sie mitnehmen. Ein kompletter CA-Store ist oft zu groß oder unnötig. In der Praxis hat sich bewährt, gezielt nur die Root-/Intermediate-CAs einzubinden, die Sie wirklich brauchen (z. B. für Ihre API-Domain). Das senkt Speicherverbrauch und reduziert Komplexität.

• Minimalprinzip: Nur die CA(s) einbinden, die Ihre Endpunkte signieren.
• Format: Üblich ist PEM (Base64 mit Header/Footern) oder DER (binär).
• Wartung: Root-Zertifikate können auslaufen; planen Sie Firmware-Updates oder ein Mechanismus zur Zertifikatserneuerung.

Base64-Overhead bei PEM grob abschätzen (MathML)

PEM ist Base64-kodiert. Base64 vergrößert Daten typischerweise um etwa 4/3 (plus Zeilenumbrüche/Headers). Eine grobe Abschätzung des Overheads für den kodierten Anteil ist:

$\mathrm{Size}\approx \frac{4}{3}·\mathrm{BinarySize}$

Das bedeutet: Ein binäres Zertifikat mit 1.200 Bytes kann als Base64-Anteil grob bei 1.600 Bytes landen, plus zusätzliche PEM-Header/Zeilenumbrüche. Für knappe Flash-/RAM-Budgets kann DER oder eine kompakte Einbettung vorteilhaft sein.

Warum die Uhrzeit entscheidend ist: Zertifikatsgültigkeit und NTP

Ein häufiger Stolperstein: Der ESP32 prüft die Gültigkeitsdauer von Zertifikaten (Not Before/Not After). Wenn die Systemzeit falsch ist (z. B. 1970-01-01 nach Boot), scheitert die Verifikation, obwohl Zertifikate „eigentlich“ korrekt sind. Deshalb ist eine zuverlässige Zeitsynchronisation essenziell, meist über NTP. In produktnahen Geräten sollte die Zeit möglichst früh nach dem WLAN-Verbindungsaufbau gesetzt werden, bevor HTTPS-Requests starten.

• Erst Zeit setzen, dann TLS: NTP-Sync vor dem ersten HTTPS-Request.
• Fallback: Wenn NTP nicht verfügbar ist, kann eine RTC oder eine gespeicherte „letzte bekannte Zeit“ helfen.
• Diagnose: Bei TLS-Fehlern immer Systemzeit mitloggen.

SNI und Hostname-Verifikation: Moderne Server korrekt ansprechen

Viele HTTPS-Server hosten mehrere Domains auf einer IP-Adresse (Virtual Hosting). Damit der Server das passende Zertifikat ausliefert, wird oft Server Name Indication (SNI) benötigt. Wenn SNI fehlt oder falsch ist, kann der Server ein Zertifikat für eine andere Domain senden, und die Prüfung schlägt fehl. Ebenso wichtig ist die Hostname-Verifikation: Das Zertifikat muss zum Domainnamen passen, den Sie ansprechen.

• Immer mit Hostname arbeiten: Nicht die IP direkt verwenden, wenn Sie Virtual Hosts erwarten.
• SNI aktiv lassen: In modernen TLS-Stacks ist SNI meist Standard, sollte aber nicht deaktiviert werden.
• CN/SAN prüfen: Der Domainname muss im Zertifikat (SAN) enthalten sein.

HTTPS-Client am ESP32: Typische Request-Patterns

In der Praxis haben sich wenige Muster etabliert. Entscheidend ist, dass Sie Timeouts, Wiederholungen und Ressourcen sauber managen.

• GET (Abruf): Konfiguration, Token, Statusinformationen.
• POST/PUT (Senden): Telemetrie, Events, Formulardaten, JSON-Objekte.
• Header-Handling: Content-Type, Authorization (Bearer Token), User-Agent (optional).
• Response-Parsing: Statuscode prüfen, Body ggf. als JSON parsen (sparsam puffern).

Für ESP-IDF ist der „HTTP Client“ eine zentrale Komponente, die auch TLS unterstützt: ESP-IDF esp_http_client. Für TLS nutzt ESP-IDF mbedTLS; der TLS-Teil ist ebenfalls dokumentiert: ESP-IDF mbedTLS.

WiFiClientSecure in Arduino: Sicherheit richtig konfigurieren

In Arduino-ESP32 wird HTTPS häufig über „WiFiClientSecure“ umgesetzt, oft in Kombination mit HTTPClient oder direkten TLS-Sockets. Der entscheidende Punkt ist die Zertifikatsprüfung. Seriöse Varianten nutzen ein CA-Zertifikat oder Pinning. Unsichere Varianten setzen „insecure“ oder verzichten auf Validierung – das sollte nur für kurzzeitige Tests in einem isolierten Labor passieren, nicht im echten Betrieb.

• CA-Zertifikat setzen: bevorzugt für APIs mit regelmäßig erneuerten Zertifikaten.
• Pinning nutzen: wenn Sie die Infrastruktur kontrollieren und Updates geplant sind.
• Timeouts definieren: verhindert Hänger bei schlechter Verbindung.

Die Arduino-ESP32-Dokumentation ist der beste Startpunkt für die jeweils aktuellen Klassen und Beispiele: Arduino-ESP32 Dokumentation.

Performance und RAM: Warum TLS schwerer ist als HTTP

TLS kostet Ressourcen: Handshake, Schlüsselmaterial, Zertifikatskette, Puffer für Ein-/Ausgabe und ggf. zusätzliche Kryptografie (z. B. ECDHE). Beim ESP32 ist das in vielen Projekten problemlos, solange Sie nicht gleichzeitig sehr große JSON-Payloads, einen Webserver, WebSockets und TLS in mehreren parallelen Verbindungen betreiben. Typische Symptome bei Ressourcenproblemen sind: Verbindungsabbrüche während des Handshakes, unerklärliche „connection reset“-Fehler oder sporadische Abstürze unter Last.

• Verbindungen wiederverwenden: Wenn möglich Keep-Alive nutzen, um Handshakes zu reduzieren.
• Payload klein halten: Weniger Bytes bedeuten weniger Puffer und kürzere Sendezeiten.
• Parallelität begrenzen: Nicht zu viele gleichzeitige TLS-Sessions aufbauen.
• Debug-Logs gezielt aktivieren: Nur bei Diagnose, da Logging selbst Ressourcen bindet.

Fehlerdiagnose: Typische TLS-Fehler und was sie bedeuten

Bei HTTPS-Problemen ist es wichtig, nicht „ins Blaue“ zu ändern, sondern die Ursache strukturiert zu finden. Häufige Kategorien sind Zertifikatsprüfung, Zeit, DNS/Hostname, Netzwerkqualität und inkompatible Cipher Suites/TLS-Versionen.

• Zertifikat ungültig/abgelaufen: Systemzeit falsch oder Zertifikat tatsächlich abgelaufen.
• „Unknown CA“: falsches oder fehlendes Root-/Intermediate-Zertifikat eingebunden.
• Hostname mismatch: Domainname passt nicht zum Zertifikat (SAN fehlt) oder IP statt Hostname genutzt.
• Handshake timeout: schwaches WLAN, DNS-Probleme, Server überlastet, zu knappe Timeouts.
• Connection reset: Netzwerk instabil oder Server lehnt wegen TLS-Parametern ab.

Ein praxisnaher Ansatz ist, bei Fehlern immer drei Dinge mitzuloggen: Systemzeit, Ziel-Hostname und den exakten TLS-Fehlercode bzw. die mbedTLS-Fehlermeldung (wenn verfügbar).

Zertifikats-Pinning: Wann es sinnvoll ist und wie Sie es wartbar halten

Pinning ist besonders interessant, wenn Sie eine eigene Infrastruktur betreiben (z. B. eigenes Backend) und sicherstellen möchten, dass nur Ihr Server akzeptiert wird – selbst dann, wenn eine fremde CA kompromittiert wäre. Der Preis ist Wartung: Zertifikate werden erneuert, Keys können rotieren, und dann müssen Geräte aktualisiert werden.

• Public-Key-Pinning bevorzugen: Stabiler als Zertifikats-Fingerprint, wenn der Key über Zertifikatserneuerungen hinweg gleich bleibt.
• Update-Plan: OTA-Update oder Wartungsfenster einplanen, wenn der Pin sich ändern muss.
• Backup-Pin: Optional mehrere Pins erlauben (aktueller + nächster), um Rotation zu erleichtern.

Eigener Server und Zertifikate: Best Practices für sichere IoT-APIs

Wenn Sie Ihre eigene API betreiben, entscheidet die Serverkonfiguration maßgeblich darüber, wie stabil ESP32-Clients arbeiten. Moderne Server sollten TLS sauber konfigurieren, korrekte Ketten ausliefern und gängige Cipher Suites anbieten. Für Zertifikate sind automatisierte Prozesse (z. B. ACME/Let’s Encrypt) üblich, aber Sie müssen die Auswirkungen auf IoT-Geräte berücksichtigen: Wenn Sie die CA wechseln oder nur unvollständige Zertifikatsketten ausliefern, scheitern Clients häufig.

• Vollständige Zertifikatskette ausliefern: Server sollte Intermediate-Zertifikate korrekt mitsenden.
• Stabile Domainnamen: Geräte sollten über Hostnames statt IPs arbeiten.
• API-Design: Kleine Responses, klare Statuscodes, Rate Limits, eindeutige Fehlermeldungen.
• Token statt Basic Auth: Kurzlebige Tokens sind oft besser als feste Passwörter im Firmware-Image.

Wenn Sie sich an etablierten Sicherheitskonfigurationen orientieren möchten, ist die Dokumentation von Let’s Encrypt ein guter Einstieg für Zertifikatsautomatisierung: Let’s Encrypt Dokumentation.

Sicherheitsfallen vermeiden: Was Sie niemals dauerhaft tun sollten

Manche „Lösungen“ sorgen zwar dafür, dass ein HTTPS-Request plötzlich funktioniert, zerstören aber den Sicherheitsnutzen von TLS. In produktiven Projekten sind diese Muster ein ernstes Risiko.

• Zertifikatsprüfung deaktivieren: Macht TLS praktisch wertlos, da jeder MITM akzeptiert wird.
• Hardcoded Passwörter/Keys ohne Schutz: Wenn möglich Secrets trennen, rotierbar machen, Zugriff begrenzen.
• Unbegrenzte Retries: Können Geräte in Endlosschleifen halten und Akku leeren oder Server überlasten.
• Keine Limits für Response-Größe: Kann RAM sprengen, wenn ein Server unerwartet viel sendet.

Praxis-Checkliste: So wird HTTPS am ESP32 zuverlässig

• CA-Verifikation implementieren: Root/Intermediate passend zu Ihren Endpunkten einbinden.
• Zeit synchronisieren: NTP vor dem ersten TLS-Handshake; Systemzeit loggen.
• Hostname + SNI nutzen: Keine IPs, wenn virtuelle Hosts möglich sind.
• Timeouts setzen: Connect-, Read- und Overall-Timeout definieren.
• Keep-Alive prüfen: Handshake-Kosten reduzieren, wenn es zum Server passt.
• Payload/Response begrenzen: JSON kompakt halten, Maximalgrößen definieren.
• Fehlercodes auswerten: TLS-Fehler nicht „wegdrücken“, sondern gezielt behandeln.

Outbound-Links zu relevanten Informationsquellen

• RFC 8446: TLS 1.3 (Standard)
• RFC 5280: X.509 Zertifikate und PKI (Standard)
• ESP-IDF: esp_http_client (HTTP/HTTPS-Client)
• ESP-IDF: mbedTLS (TLS/SSL-Stack)
• Arduino-ESP32 Dokumentation (Espressif)
• Let’s Encrypt: kostenlose TLS-Zertifikate
• Let’s Encrypt Dokumentation: ACME und Zertifikatsmanagement

IoT-PCB-Design, Mikrocontroller-Programmierung & Firmware-Entwicklung

PCB Design • Arduino • Embedded Systems • Firmware

Ich biete professionelle Entwicklung von IoT-Hardware, einschließlich PCB-Design, Arduino- und Mikrocontroller-Programmierung sowie Firmware-Entwicklung. Die Lösungen werden zuverlässig, effizient und anwendungsorientiert umgesetzt – von der Konzeptphase bis zum funktionsfähigen Prototyp.

Diese Dienstleistung richtet sich an Unternehmen, Start-ups, Entwickler und Produktteams, die maßgeschneiderte Embedded- und IoT-Lösungen benötigen. Finden Sie mich auf Fiverr.

Leistungsumfang:

• IoT-PCB-Design & Schaltplanerstellung

• Leiterplattenlayout (mehrlagig, produktionstauglich)

• Arduino- & Mikrocontroller-Programmierung (z. B. ESP32, STM32, ATmega)

• Firmware-Entwicklung für Embedded Systems

• Sensor- & Aktor-Integration

• Kommunikation: Wi-Fi, Bluetooth, MQTT, I²C, SPI, UART

• Optimierung für Leistung, Stabilität & Energieeffizienz

Lieferumfang:

• Schaltpläne & PCB-Layouts

• Gerber- & Produktionsdaten

• Quellcode & Firmware

• Dokumentation & Support zur Integration

Arbeitsweise:Strukturiert • Zuverlässig • Hardware-nah • Produktorientiert

CTA:
Planen Sie ein IoT- oder Embedded-System-Projekt?
Kontaktieren Sie mich gerne für eine technische Abstimmung oder ein unverbindliches Angebot. Finden Sie mich auf Fiverr.