14.4.6. Operaciones: claves, caducidad y resolución de problemas

Tres aspectos del trabajo con certificados abarcan cada dispositivo desplegado: proteger la clave privada una vez que está en la cámara, planificar el día en que el certificado caduque y la breve lista de modos de error que aparecen en la práctica.

14.4.6.1. Protección de la clave privada

Siempre que la cámara presenta un certificado –como servidor TLS o como cliente en mTLS– su clave privada tiene que residir en el dispositivo, en DER en texto plano, en el sistema de archivos o en ROMFS. Almacenada de esa forma, es legible por cualquier código que se ejecute en la cámara y por cualquiera con acceso físico a ella: la unidad de almacenamiento masivo USB, un símbolo del sistema REPL o la memoria flash en bruto. ROMFS y las marcas de solo lectura impiden la modificación, no la extracción. Trate cualquier clave privada distribuida en un dispositivo como recuperable por un atacante decidido con acceso físico o de código.

Esto no hace que TLS sea inútil; más bien condiciona cómo lo despliega:

  • Use una clave y un certificado únicos por dispositivo. Nunca grabe en flash una única clave compartida en toda la flota: extraerla de una sola unidad permitiría entonces a un atacante suplantar a todas las cámaras. Las claves por dispositivo limitan un compromiso a ese único dispositivo, que puede revocar o deshabilitar del lado del servidor.

  • Mantenga los certificados de corta duración. Una clave robada solo es útil mientras su certificado sea válido; los periodos de vida cortos junto con una rotación rutinaria acotan el daño (consulte Caducidad y rotación de certificados más abajo).

  • Evite poner un secreto en el dispositivo siempre que pueda. Si solo necesita verificar el servidor (autenticación del servidor, no mTLS), la cámara como cliente almacena únicamente el certificado de la CA –que es público– y no contiene ninguna clave privada que valga la pena robar.

  • Nunca distribuya una clave en una imagen de firmware pública. Una clave incrustada en ROMFS en una compilación de firmware que usted distribuye no es secreta; cualquiera que descargue el firmware la tiene. El aprovisionamiento por dispositivo significa programar la clave después del firmware genérico, no dentro de él.

  • Limite el radio de impacto. Acote lo que el certificado autentica (mínimo privilegio) y asegúrese de que una única identidad de dispositivo filtrada pueda revocarse o deshabilitarse sin afectar al resto.

Si su modelo de amenazas incluye atacantes con acceso físico, diseñe partiendo de la suposición de que la clave del dispositivo se filtrará tarde o temprano y haga que eso sea sobrevivible, en lugar de asumir que puede mantenerse en secreto en hardware que no dispone de medios para ello.

14.4.6.2. Caducidad y rotación de certificados

Cada certificado lleva una ventana de validez. Una vez que esta pasa, un par con ssl.CERT_REQUIRED rechaza la conexión, por lo que la caducidad es una interrupción real y programada, no un riesgo teórico. El reloj de la cámara también debe ser correcto para que la comprobación de validez se evalúe con honestidad.

  • Autofirmado. Usted eligió el periodo de vida con -days. Cuando expira, debe regenerar la clave/certificado y volver a desplegarlo: volver a copiar los archivos DER, o reconstruir y reflashear la imagen ROMFS si el certificado está incrustado. Elija un valor de -days sobre el que realmente vaya a recordar actuar.

  • CA pública. Estos son deliberadamente de corta duración. Let’s Encrypt emite certificados de 90 días y espera una renovación automatizada aproximadamente cada 60 días; no existe la opción de «instalar una vez y olvidarse».

La tendencia general es unidireccional: la validez máxima de los certificados TLS de confianza pública sigue reduciéndose. Fue de 825 días, actualmente está limitada a 398 días, y el CA/Browser Forum ha adoptado un calendario que la reduce progresivamente hasta aproximadamente 47 días para 2029. La conclusión para el diseño de un dispositivo es asumir que los certificados son de corta duración y que la rotación debe automatizarse o, al menos, ser rutinaria; no distribuya un producto que dependa de que una persona reemplace un certificado de diez años.

En la práctica, en la cámara: prefiera diseños en los que el certificado pueda reemplazarse sin reflashear (un sistema de archivos con permisos de escritura más una vía de actualización remota, o ejecutar la cámara como cliente que confía en una CA que usted rota de forma centralizada). Si un certificado debe residir en ROMFS, programe las actualizaciones de firmware en torno a su periodo de vida.

14.4.6.3. Resolución de problemas

  • El reloj debe estar configurado. Una cámara que no ha configurado su reloj desde el encendido falla la comprobación de validez del certificado; llame primero a ntptime.settime().

  • El nombre de host debe coincidir. Cuando el cliente pasa server_hostname, este debe coincidir con el subjectAltName del certificado (o el CN en pilas más antiguas), o la verificación falla.

  • Formato incorrecto. Un archivo PEM copiado a la cámara no se cargará; conviértalo primero a DER.

  • Certificado caducado. Una conexión que antes funcionaba y ahora falla con OSError puede simplemente tener un certificado caducado; compruebe las fechas de validez y regenere/vuelva a desplegar según sea necesario.

  • Las claves Ed25519 fallan. Use ECDSA P-256/P-384 o RSA, no Ed25519.

  • Los errores son OSError. MicroPython no implementa ssl.SSLError; los fallos de TLS (certificado incorrecto, caducado, CA desconocida, error de formato, fallo de handshake) se lanzan como OSError.