🛠 HTTPS avec validation de certificat racine

Objetivos

Pasar de HTTP sin cifrar a HTTPS con WiFiSSLClient: el módulo NINA ejecuta el handshake TLS, que verifica el certificado del servidor contra su almacén interno de autoridades de certificación (CA) raíz (bundle reconstruido desde la lista de Android, incluido en el firmware nina-fw). Aprenderás a diagnosticar los fallos de validación y a convivir con los errores TLS conocidos del firmware.

Material

• 1 × Arduino MKR WiFi 1010 (WiFi operativo, ver tutorial STA)
• Firmware NINA actualizado (requisito imprescindible para TLS)
• Un host HTTPS de prueba público (p. ej. www.howsmyssl.com)
• El chip criptográfico integrado ATECC508 existe en la placa, pero la ruta TLS estándar de WiFiNINA se realiza dentro del NINA

Código completo

#include <WiFiNINA.h>

const char* SSID = "votre-ssid";
const char* PASS = "votre-mot-de-passe";
WiFiSSLClient secure;   // TLS + validation CA embarquee dans le NINA

void setup {
  Serial.begin(115200);
  WiFi.begin(SSID, PASS);
  while (WiFi.status != WL_CONNECTED) { delay(500); Serial.print("."); }

  if (secure.connect("www.howsmyssl.com", 443)) {
    secure.println("GET /a/check HTTP/1.1");
    secure.println("Host: www.howsmyssl.com");
    secure.println("Connection: close");
    secure.println;
    while (secure.available) Serial.write(secure.read);
    secure.stop;                       // libere la session TLS
  } else {
    Serial.println("Handshake TLS KO - firmware/CA a verifier");
  }
}

void loop {}

Verificación esperada

Se muestra la respuesta JSON de howsmyssl, lo que demuestra que el canal está cifrado y el certificado validado. secure.connect devuelve 0 mientras la CA emisora no esté en el bundle del módulo: actualiza primero el firmware antes de sospechar de tu código. Llama siempre a stop: cada sesión TLS consume la valiosa RAM del NINA.

Errores frecuentes

• Fuga de memoria en conexiones TLS repetidas: los problemas nina-fw #135/#136 describen que downloadAndSaveFile declara éxito tras un fallo de inicialización de los certificados y fuga memoria del heap en cada operación TLS (idéntico en 3.0.1 y master en el momento de los informes; corrección en la PR #149). En producción, espacia las reconexiones, llama a stop y prevé un watchdog de reinicio.
• Nuevo sitio «rechazado» aunque sea válido: CA reciente ausente del bundle del firmware — apuesta por actualizar el firmware en lugar de usar un setCertificate propio.
• Confundir fallo de DNS, fallo de TCP y fallo de TLS: prueba primero WiFiClient en el puerto 443 para aislar la capa de red.
• Certificados autofirmados: hay que extraer la CA raíz en PEM y declararla explícitamente; el simple certificado de servidor intermedio no es suficiente.