Cifrado, TLS y certificados

01 · Un control del sistema completo

Qué protege el canal

En el tema 40 distinguimos identidad, autorización, validación y disponibilidad. TLS protege una parte específica: la comunicación entre sus extremos. Para un dispositivo que habla con una API o un broker, permite establecer un canal con cifrado, integridad y autenticación según el modo configurado.

La protección termina donde termina TLS. Si un gateway descifra y reenvía hacia otro servicio, ese segundo tramo requiere su propia protección. Un broker autorizado puede leer el contenido que recibe; TLS de transporte no oculta por sí solo los mensajes a sus extremos.

También pueden seguir siendo observables direcciones, volúmenes y tiempos de tráfico, según la arquitectura. «Cifrado» no significa que desaparezca toda información sobre la comunicación.

El laboratorio trabaja con metadatos ficticios. No implementa algoritmos criptográficos, no procesa certificados reales y no abre conexiones. Los fragmentos de integración usan bibliotecas TLS mantenidas.

02 · Funciones con propósitos distintos

Claves, firmas y certificados

El cifrado simétrico usa claves compartidas para proteger datos con un costo apropiado para el tráfico continuo. La criptografía de clave pública trabaja con un par: clave pública y privada. Una firma permite comprobar autenticidad e integridad de un mensaje bajo las condiciones del esquema; no oculta su contenido por sí sola.

TLS combina mecanismos: negocia parámetros, establece secretos de sesión, autentica cuando corresponde y protege los registros de aplicación. No se cifra cada lectura simplemente «con el certificado del servidor». La biblioteca ejecuta el protocolo completo y administra sus claves de sesión.

Copiar el certificado público de un servidor no permite completar su autenticación: falta la prueba de posesión de la clave privada correspondiente. Tampoco se distribuye la clave privada de la CA a los dispositivos para que «confíen»; se aprovisiona el material público de confianza que necesita el cliente.

Representación no es cifrado

DER es una representación binaria de un certificado; PEM suele envolver ese contenido codificado en Base64 con delimitadores de texto. Convertir un secreto a Base64 no lo protege. Una huella es un resumen de un contenido, no una validación automática de su identidad o procedencia.

El formato X.509 y la validación de rutas se desarrollan en RFC 5280. La aplicación utiliza bibliotecas que implementan esas reglas, en lugar de intentar comprobar una firma comparando nombres de archivos o textos del emisor.

03 · Establecer el canal

Qué hace TLS al conectar

En una conexión con autenticación por certificados, el intercambio inicial negocia parámetros, establece secretos, presenta y valida identidades y comprueba la integridad del handshake antes de tratar la conexión como establecida. Los mensajes y su protección concreta dependen de la versión y modo.

RFC 8446 define TLS 1.3. TLS 1.2 también existe en entornos embebidos y requiere una configuración criptográfica adecuada. La selección de versiones y parámetros se revisa con la plataforma y referencias como RFC 9325; no se habilitan SSL o versiones TLS antiguas para resolver una incompatibilidad sin diagnóstico.

El modelo ofrece políticas de TLS 1.2 o superior y TLS 1.3. Una implementación o build que solo soporte 1.2 no negocia 1.3 por cambiar el puerto o un texto de configuración. Se comprueba lo que realmente negoció y las capacidades del cliente y servidor.

Aplicación sobre el transporte

HTTPS usa HTTP sobre TLS; MQTT también puede usar un transporte TLS. Los puertos 443 y 8883 son convenciones habituales, no pruebas de protección: un número de puerto no establece confianza ni verifica nombres.

TLS tampoco sustituye el protocolo de comandos del tema 38. La aplicación puede repetir una solicitud al reconectar. Además, los datos tempranos 0-RTT de TLS 1.3 tienen consideraciones de repetición propias: no se usan para acciones con efectos sin un diseño compatible. Reanudar una sesión no equivale a garantizar ejecución física una sola vez.

04 · De la hoja a una autoridad aceptada

La cadena de confianza

El certificado final o hoja identifica al servicio. Puede estar firmado por una CA intermedia, que a su vez se relaciona con un ancla de confianza del cliente. El servidor suele presentar las intermedias necesarias; el cliente ya debe conocer qué anclas acepta.

La cadena no se valida solo porque el texto «issuer» de un certificado coincida con «subject» de otro. La biblioteca verifica firmas, restricciones de CA, usos y condiciones de la ruta según su política. Un certificado firmado correctamente por una autoridad ajena al almacén del cliente no se vuelve confiable por sí solo.

El ancla se aprovisiona por un camino confiable

La primera conexión no debería descargar una raíz de cualquier servidor y aceptarla como prueba de ese mismo servidor. La confianza inicial forma parte del firmware o del proceso de aprovisionamiento autorizado. Un atacante que cambie el almacén puede alterar qué servicios acepta el equipo, aunque los certificados sean públicos.

Una raíz autofirmada no demuestra por su propia firma que deba ser aceptada. Puede ser una ancla privada válida para tu instalación si se distribuyó y administró con el procedimiento previsto. CA pública y CA privada son decisiones de arquitectura y operación, no etiquetas que reemplazan la verificación.

Intermedias y almacenes pequeños

Un microcontrolador no necesariamente dispone del almacén de un navegador ni descarga intermedias faltantes. Se prueba la cadena que presenta el servicio con el cliente real. «Funciona en mi PC» no demuestra que la placa tenga las mismas anclas, algoritmos, memoria o reglas.

Un almacén acotado reduce material y alcance de confianza, pero necesita renovación y compatibilidad. Un bundle más amplio facilita algunos cambios y también amplía las autoridades aceptadas. El producto elige y mantiene esa política.

05 · La cadena correcta para el servicio correcto

Nombre del servicio y reloj

Una cadena válida puede pertenecer a otro servicio. El cliente conoce de antemano la identidad de referencia, por ejemplo broker.curso.example, y la compara con los identificadores adecuados del certificado. No obtiene el nombre esperado del propio certificado y luego declara que coincide.

Las reglas actuales de identidad de servicio se especifican en RFC 9525. Se usan identificadores de la extensión Subject Alternative Name, SAN. No se toma el nombre visible de la organización ni el Common Name heredado como sustituto de esa verificación.

DNS, IP y SNI

Si el cliente usa un nombre DNS de referencia, se verifica un identificador DNS apropiado. Si usa una IP como identidad, necesita la entrada IP correspondiente; una entrada DNS cuyo texto parezca una IP no es lo mismo. Resolver DNS a una dirección no obliga a abandonar el nombre de referencia.

SNI permite indicar al servidor qué nombre se solicita para seleccionar el certificado cuando comparte dirección con otros servicios. SNI no autentica por sí solo: después se valida el certificado presentado contra la identidad esperada. Pasar solo una IP a una API puede cambiar cómo se realiza ese proceso; se revisa la API concreta.

El laboratorio solo compara identificadores exactos de una lista cerrada. No implementa comodines, nombres internacionalizados ni las reglas completas de identidad TLS. Esas tareas pertenecen a la biblioteca y a las pruebas de la política.

Fechas y arranque

La hoja tiene un intervalo de validez, y la ruta también tiene condiciones temporales según las reglas aplicables. Un reloj que volvió a 1970 puede considerar que el certificado aún no es válido; uno adelantado puede verlo vencido. Cambiar arbitrariamente la fecha para que pase ocultaría el problema.

El producto define cómo obtiene una referencia temporal aceptable al arrancar: RTC, información persistida, límites conocidos y fuentes de sincronización adecuadas a su riesgo. Una hora recibida de una fuente cualquiera no se vuelve confiable por ser reciente. Conservar el último tiempo conocido puede ayudar con algunos retrocesos, sin demostrar por sí solo la hora actual.

Si no se puede establecer la referencia requerida, se informa el estado y se aplica la política de operación local prevista. El flag del ejemplo representa el resultado de ese proceso, no una opción que un mensaje remoto pueda declarar verdadera.

06 · Dos direcciones de autenticación

Autenticación mutua y permisos

En TLS con autenticación de servidor, el dispositivo verifica al servicio. El servicio puede identificar al dispositivo mediante otra credencial sobre ese canal, como un token validado. El certificado del servidor no demuestra por sí solo quién es el cliente.

En mTLS, el servidor también exige y valida la identidad TLS del cliente y su prueba de clave. El dispositivo necesita su certificado y acceso protegido a su clave privada; el servidor define qué emisores e identidades acepta.

Son políticas y materiales diferentes. La CA que acepta el dispositivo para servidores no tiene que ser la misma que acepta el broker para clientes. En mTLS tampoco se envía la clave privada al servidor: se utiliza para la prueba que requiere el protocolo.

Identidad conocida, operación denegada

Tras establecer el canal, la plataforma aplica la ACL del tema 40. Un certificado cliente válido para equipo07 no autoriza publicar órdenes de equipo08. El rechazo de una operación puede ser correcto aunque TLS se haya establecido sin errores.

La renovación, la revocación y el retiro de identidades necesitan soporte de ambos extremos. Comprobar fechas no demuestra ausencia de revocación. CRL, OCSP u otros mecanismos dependen de la pila y de una política implementada; no se presume que cualquier cliente embebido los consulta automáticamente.

El laboratorio no modela revocación ni emisión de certificados. El perfil de cliente «válido» resume verificaciones que el servidor ya habría realizado. El tema 42 desarrolla cómo aprovisionar y mantener esa identidad por dispositivo.

07 · Integración con bibliotecas mantenidas

Integración en ESP32 y Python

En Arduino-ESP32, NetworkClientSecure ofrece un cliente TLS utilizable por protocolos de aplicación. Este fragmento abre una conexión nueva por nombre, con una CA pública de confianza proporcionada por el producto:

#include <WiFi.h>
#include <NetworkClientSecure.h>

bool abrirCanal(NetworkClientSecure& tls, const char* caPem,
                bool relojAdmitidoPorLaPolitica) {
  tls.stop();  // esta función inicia una conexión nueva
  if (WiFi.status() != WL_CONNECTED || !relojAdmitidoPorLaPolitica) {
    return false;
  }
  if (caPem == nullptr || caPem[0] == '\0') return false;

  // caPem contiene el ancla pública aprovisionada, con vida útil suficiente.
  tls.setCACert(caPem);
  tls.setHandshakeTimeout(10); // segundos en esta API

  const char* host = "broker.curso.example"; // reemplazar por el servicio propio
  if (!tls.connect(host, 8883)) {
    tls.stop();
    return false;
  }
  return true;
}

// Una única tarea es dueña del cliente.
// Si abrirCanal(...) devuelve true, el cliente MQTT puede usar este transporte.
// La credencial y los permisos de aplicación se gestionan por separado.

El nombre broker.curso.example es ilustrativo y no un servicio del curso. El fragmento requiere Wi-Fi configurado, material CA íntegro y reloj aceptado. No incluye la conexión MQTT, credenciales ni un sketch de aprovisionamiento.

La API y sus tiempos se revisaron en el encabezado oficial NetworkClientSecure. El componente ESP-TLS documenta opciones de confianza, SNI y conexión en ESP-IDF. Las capacidades y reglas concretas dependen de la versión, configuración y variante.

La aplicación mantiene la verificación habilitada y trata los errores como errores. Omitir la validación para conseguir que «conecte» cambia la propiedad de seguridad que se quería obtener. Tampoco se reintenta por texto plano después de un fallo TLS.

Pasar un nombre a la API permite usar la identidad del servicio; se prueba el comportamiento real con certificados de nombre incorrecto y sin SAN, además de los casos positivos. Si una pila conserva compatibilidad heredada que no cumple la política elegida, hay que ajustar o actualizar la integración.

Un cliente Python para un entorno local

Este segundo fragmento se ejecuta en una instalación local con sockets y un archivo CA correcto. Su función es mostrar configuración de biblioteca; no tiene botón en el navegador, donde este acceso de ssl y sockets no está disponible como en CPython local.

import socket
import ssl

HOST = "broker.curso.example"  # servicio propio
contexto = ssl.create_default_context(cafile="ca_del_servicio.pem")
contexto.minimum_version = ssl.TLSVersion.TLSv1_2

with socket.create_connection((HOST, 8883), timeout=5) as tcp:
    with contexto.wrap_socket(tcp, server_hostname=HOST) as canal:
        print("Versión negociada:", canal.version())
        # A partir de aquí, el protocolo y los permisos son de la aplicación.

create_default_context configura verificación de certificados para este uso, y server_hostname conserva el nombre de referencia. La documentación de ssl de Python detalla las políticas y dependencias de OpenSSL. El programa propaga una falla de conexión o verificación; no la convierte en una sesión aceptada.

08 · La confianza tiene mantenimiento

Renovar sin perder la flota

Una hoja se renueva antes de vencer. Si conserva una ruta aceptada, identidad correcta y demás condiciones, el cliente no necesita confiar en los bytes exactos de la hoja anterior. Eso permite renovar sin actualizar todas las unidades por cada certificado nuevo.

Un cambio de CA puede exigir otro procedimiento. Los dispositivos deben aceptar el material nuevo antes de que el servicio abandone el antiguo. Durante una migración planificada puede existir un período de solapamiento con ambas anclas, limitado y controlado.

El 15 de diciembre de 2026, un cliente con CA-A acepta la hoja original y la renovada bajo A, sujeto al resto de comprobaciones. Para la hoja bajo B necesita CA-B. Un almacén A+B permite el solapamiento del ejemplo; no elimina la revisión de identidad, firmas y fechas.

Pinning y alcance

Fijar una huella de hoja o una clave puede reducir el conjunto de identidades aceptadas bajo una política específica. También crea una dependencia de ese material: una renovación o rotación de clave puede dejar unidades sin acceso. El pinning necesita material de respaldo, actualización autenticada y recuperación definidos; no se aplica copiando una huella vista en una conexión no verificada.

La confianza en una CA tampoco autoriza todos los nombres que esa CA pueda certificar para otros titulares. Se mantiene la identidad de servicio esperada. El almacén y los pins tienen una política de integridad y actualización aunque su parte pública no sea secreta.

Equipos que pasan tiempo desconectados

El plan contempla la unidad que vuelve después de meses. Debe poder alcanzar una ruta de recuperación autorizada y obtener las actualizaciones requeridas sin depender exclusivamente de un canal cuya confianza ya venció. Esa estrategia se diseña antes de retirar la CA o clave vieja, con pruebas de flota y fechas simuladas.

09 · Localizar la etapa que falló

Diagnóstico y costo de conexión

Los registros pueden incluir etapa, código de error, versión negociada cuando existe, destino y estado del reloj. No incluyen claves privadas, tokens completos ni secretos de sesión. Una comprobación que no se alcanzó todavía no se registra como superada.

Recursos del microcontrolador

El handshake consume tiempo, memoria y energía, y puede requerir más recursos que la conexión ya establecida. Se mide con la cadena y biblioteca reales, bajo presión de memoria y con otras tareas activas. Los valores de una placa o versión no se extrapolan sin verificar.

El fragmento ESP32 usa una llamada bloqueante para mostrar la configuración. En un firmware de control se integra en una tarea y con plazos que no bloqueen el límite local de salida. Reintentos acotados, esperas y limpieza de recursos evitan que un fallo repetido impida adquirir datos y mantener el control local.

Reutilizar conexiones o reanudar sesiones puede reducir trabajo; no elimina mantenimiento, autenticación ni límites de vida de sesión. Tampoco convierte TLS 1.3 en permiso para enviar órdenes como datos tempranos sin revisar las garantías del producto.

10 · Decisiones reproducibles

Un modelo ejecutable en Python

El programa siguiente evalúa condiciones lógicas sobre una hoja ficticia. Las firmas, la ruta y la prueba de clave son resultados supuestos de la biblioteca, no cálculos criptográficos del ejemplo. Solo se admite el conjunto cerrado de perfiles del laboratorio y coincidencias exactas de nombres.

La fecha de la hoja se comprueba explícitamente; las demás condiciones de ruta se resumen en banderas. No se modelan revocación, restricciones completas de PKIX, elección de algoritmos, DNS, TCP ni ataques reales. La secuencia de pasos es una explicación de decisiones, no el orden literal de mensajes TLS.

from datetime import datetime


def certificado(perfil):
    c = dict(raiz="CA-A", dns=["broker.curso.example"], ips=[],
             desde="2026-01-01T00:00:00Z", hasta="2026-12-31T23:59:59Z",
             intermedias=True, firmas=True, usoServidor=True, pruebaClave=True)
    if perfil in ("renovado", "ca_nueva"):
        c.update(desde="2026-12-01T00:00:00Z", hasta="2027-12-01T00:00:00Z")
        if perfil == "ca_nueva":
            c["raiz"] = "CA-B"
    if perfil == "otro_nombre": c["dns"] = ["otro.curso.example"]
    if perfil == "sin_intermedia": c["intermedias"] = False
    if perfil == "firma_invalida": c["firmas"] = False
    if perfil == "uso_incorrecto": c["usoServidor"] = False
    if perfil == "sin_clave": c["pruebaClave"] = False
    if perfil == "con_ip": c["ips"] = ["192.0.2.10"]
    return c


def evaluar(perfil="vigente", almacen="A", objetivo="broker.curso.example",
            fecha="2026-06-15T12:00:00Z", relojConfiable=True, servidor="13", minimo=12,
            mutuo=False, cliente="valido", credencialApp=True, permiso=True):
    cert = certificado(perfil)
    raices = ["CA-A", "CA-B"] if almacen == "AB" else [f"CA-{almacen}"]
    r = dict(certificado=cert, raices=raices, pasos=[], version=None,
             servidorAutenticado=False, canal=False, clienteAutenticado=False,
             permitida=False, fase="", motivo="")
    def paso(nombre, ok, detalle):
        r["pasos"].append(dict(nombre=nombre, ok=ok, detalle=detalle))
        if not ok: r.update(fase=nombre, motivo=detalle)
        return ok
    if not paso("Reloj", relojConfiable, "Referencia temporal admitida por la política" if relojConfiable else "Sin referencia confiable para evaluar vigencia"): return r
    ofrecidas = [13, 12] if servidor == "13" else [12] if servidor == "12" else [10]
    comun = [v for v in (13, 12) if v >= minimo and v in ofrecidas]
    if not paso("Versión TLS", bool(comun), f"Se acuerda TLS {comun[0]/10:.1f}" if comun else "No hay versión compatible con la política"): return r
    r["version"] = comun[0]
    confiable = cert["raiz"] in raices
    if not paso("Ancla de confianza", confiable, f'{cert["raiz"]} está aprovisionada' if confiable else f'{cert["raiz"]} no está en el almacén confiable'): return r
    if not paso("Cadena", cert["intermedias"], "Intermedias necesarias disponibles en el modelo" if cert["intermedias"] else "No se puede construir la ruta con las intermedias disponibles"): return r
    firmas_uso = cert["firmas"] and cert["usoServidor"]
    if not paso("Firmas y uso", firmas_uso, "Resultados simulados de verificación de firmas y uso servidor" if firmas_uso else "Falla una firma o el uso no permite autenticar este servidor"): return r
    instante = datetime.fromisoformat(fecha)
    vigente = datetime.fromisoformat(cert["desde"]) <= instante <= datetime.fromisoformat(cert["hasta"])
    if not paso("Vigencia", vigente, "La fecha está dentro del intervalo de la hoja" if vigente else "Hoja aún no válida o ya vencida según este reloj"): return r
    coincide = objetivo in cert["ips"] if objetivo == "192.0.2.10" else objetivo.lower() in cert["dns"]
    if not paso("Identidad del servicio", coincide, "El SAN apropiado coincide con la identidad de referencia" if coincide else "El SAN no identifica el nombre o IP solicitados"): return r
    if not paso("Posesión de clave del servidor", cert["pruebaClave"], "Se supone verificada por el handshake" if cert["pruebaClave"] else "Presentar el certificado no basta sin probar la clave correspondiente"): return r
    r["servidorAutenticado"] = True
    if mutuo:
        if not paso("Certificado de cliente", cliente == "valido", "El servidor valida cliente y prueba de clave en el modelo" if cliente == "valido" else "Falta una identidad cliente TLS válida o su prueba de clave"): return r
        r["clienteAutenticado"] = True
    r["canal"] = True
    if not mutuo:
        if not paso("Identidad de aplicación", credencialApp, "El servicio verifica otra credencial sobre el canal" if credencialApp else "TLS de servidor no identifica por sí solo al dispositivo"): return r
        r["clienteAutenticado"] = True
    if not paso("Autorización", permiso, "La identidad tiene permiso sobre el recurso" if permiso else "Canal válido e identidad conocida, pero operación no autorizada"): return r
    r.update(permitida=True, fase="Completa", motivo="Canal y permiso satisfacen las condiciones del ejercicio")
    return r


casos = [
    ("Caso correcto", {}, "Completa"),
    ("TLS 1.2 permitido", dict(servidor="12"), "Completa"),
    ("Exige 1.3", dict(servidor="12", minimo=13), "Versión TLS"),
    ("Servidor antiguo", dict(servidor="10"), "Versión TLS"),
    ("Reloj no confiable", dict(relojConfiable=False), "Reloj"),
    ("Hoja vencida", dict(fecha="2027-06-15T12:00:00Z"), "Vigencia"),
    ("Hoja futura", dict(perfil="renovado"), "Vigencia"),
    ("Otra CA", dict(perfil="ca_nueva", fecha="2026-12-15T12:00:00Z"), "Ancla de confianza"),
    ("Solapamiento A+B", dict(perfil="ca_nueva", almacen="AB", fecha="2026-12-15T12:00:00Z"), "Completa"),
    ("Renovar bajo A", dict(perfil="renovado", fecha="2027-06-15T12:00:00Z"), "Completa"),
    ("Otro nombre", dict(perfil="otro_nombre"), "Identidad del servicio"),
    ("IP sin SAN IP", dict(objetivo="192.0.2.10"), "Identidad del servicio"),
    ("IP con SAN IP", dict(perfil="con_ip", objetivo="192.0.2.10"), "Completa"),
    ("Sin intermedia", dict(perfil="sin_intermedia"), "Cadena"),
    ("Firma incorrecta", dict(perfil="firma_invalida"), "Firmas y uso"),
    ("Uso incorrecto", dict(perfil="uso_incorrecto"), "Firmas y uso"),
    ("Sin prueba de clave", dict(perfil="sin_clave"), "Posesión de clave del servidor"),
    ("mTLS sin cliente", dict(mutuo=True, cliente="ausente"), "Certificado de cliente"),
    ("mTLS válido", dict(mutuo=True, credencialApp=False), "Completa"),
    ("Canal sin credencial", dict(credencialApp=False), "Identidad de aplicación"),
    ("Identidad sin permiso", dict(permiso=False), "Autorización")
]
for nombre, cfg, fase in casos:
    r = evaluar(**cfg)
    assert r["fase"] == fase, nombre
    print(f'{nombre:24} {r["fase"]}')
assert evaluar(fecha="2026-12-31T23:59:59Z")["permitida"]
assert not evaluar(fecha="2027-01-01T00:00:00Z")["permitida"]
assert evaluar(permiso=False)["canal"] and not evaluar(permiso=False)["permitida"]
print(f"\n{len(casos)+3} comprobaciones superadas.")

Se comprueban veintiún casos y tres propiedades adicionales: límites de vigencia y canal válido con permiso denegado. Las veinticuatro comprobaciones terminan sin errores. Esto verifica el modelo de decisiones, no una implementación criptográfica.

11 · Exploración interactiva

Confianza, autenticación y permiso

Elegí un perfil ficticio y evaluá. Se muestra la primera condición que detiene el recorrido y las etapas que llegaron a comprobarse. Cambiar CA o fecha no omite el resto de verificaciones.

Recorrido guiado

1. Con los valores iniciales se acuerda TLS 1.3, el servidor se autentica, se establece canal y la identidad de aplicación tiene permiso.
2. Quitá el permiso. El canal sigue establecido y el cliente identificado, pero la operación se deniega. Quitá también la credencial: el canal puede existir sin identidad cliente de aplicación.
3. Restaurá credencial y permiso y activá mTLS. La identidad de aplicación deja de ser necesaria en este modelo. Elegí cliente ausente: el servidor ya se validó, pero el handshake mutuo no termina.
4. Con mTLS desactivado, elegí el perfil de otro nombre. La ruta y fecha pueden ser correctas y aun así falla la identidad solicitada. Si cambiás el objetivo a otro.curso.example, esa condición cambia porque ahora se pidió otro servicio.
5. Solicitá la IP con el perfil original: falla por no tener SAN IP. El perfil que incluye 192.0.2.10 sí satisface ese caso. No se convierte una entrada DNS en IP por parecido textual.
6. Con objetivo broker, elegí fecha 15/12/2026 y perfil renovado bajo B. Solo CA-A no alcanza; A+B admite la nueva ruta. Volver a la hoja original con solo CA-B también falla.
7. Elegí el 15/06/2027. La hoja original está vencida; la renovada bajo A puede seguir siendo válida con CA-A. Tener una raíz aceptada no impide que venza una hoja.
8. Probá intermedia faltante, firma incorrecta, uso incorrecto y falta de prueba de clave. Son causas distintas y el diagnóstico las distingue, sin omitir verificaciones.
9. Probá reloj perdido y referencia no confiable. En el primer caso puede fallar la fecha; en el segundo la política detiene la evaluación antes de confiar en esa hora.
10. Con los demás valores iniciales, ofrecé solo TLS 1.2 y exigí mínimo 1.3. La negociación falla por incompatibilidad. Con mínimo 1.2 el modelo encuentra una versión común; eso no reemplaza revisar el resto de parámetros de una conexión real.

El laboratorio presupone verificación criptográfica externa y usa un conjunto acotado de identidades. No ofrece un botón para «aceptar cualquier certificado». La solución de una falla depende de su causa y de una actualización autorizada del material o configuración apropiados.

12 · Configurar y probar de extremo a extremo

Método y confusiones frecuentes

1. Definí el extremo: nombre de referencia, transporte y dónde termina TLS.
2. Elegí la política: versiones, biblioteca mantenida y autenticación requerida en cada dirección.
3. Aprovisioná confianza íntegra: anclas y material cliente por caminos autorizados.
4. Resolvé el tiempo de arranque: fuente, límites y comportamiento cuando no se puede validar.
5. Probá casos negativos: nombre, fechas, ruta, uso, clave y cliente incorrectos.
6. Separá el permiso: un canal válido no habilita cualquier tópico u operación.
7. Planificá renovación: solapamiento, equipos desconectados y recuperación.
8. Medí recursos: memoria, demora, energía, reintentos y efecto sobre el control local.
9. Registrá etapa y causa: sin secretos ni falsos éxitos de comprobaciones no realizadas.

13 · Práctica guiada

Predecí antes de comprobar

1. Una cadena para otro servicio

La ruta llega a una CA aceptada y la fecha es válida, pero el SAN solo contiene otro.curso.example. El cliente pidió broker. ¿Se acepta?

2. IP frente a DNS

El dispositivo usa 192.0.2.10 como identidad y la hoja solo tiene el SAN DNS de broker. ¿La resolución a esa IP reemplaza la entrada IP?

3. Material para el cliente

¿Qué debe distribuirse para que el equipo acepte una CA: su certificado público o la clave privada de esa CA?

4. Reloj de arranque

La hoja comienza en enero de 2026 y el reloj volvió a 1970. ¿Qué explica el rechazo y qué se revisa?

5. Cambio de CA

El servicio pasa de CA-A a CA-B y hay equipos que solo aceptan A. ¿Qué preparación permite un cambio gradual en el ejemplo?

6. Canal sin permiso

mTLS termina bien, pero equipo07 intenta una operación de equipo08. ¿Qué control falta superar?

7. Vigencia y renovación

El 15/06/2027, el cliente acepta CA-A. La hoja original terminó en diciembre de 2026 y la renovada bajo A termina en diciembre de 2027. ¿Cuál puede pasar la fecha?

8. Resultado de la conexión

El servicio validó el certificado del servidor, pero exige mTLS y el dispositivo no presenta identidad cliente válida. ¿Se envía la orden como si ya hubiera terminado TLS?

14 · Síntesis

Ideas para recordar

¿Listo para el tema 42?

Antes de avanzar, anotá el nombre de referencia de tu servicio, qué anclas acepta cada extremo, de dónde obtiene el equipo la hora y cómo se renovará el material antes de vencer. Prepará pruebas de nombre, fecha y cadena incorrectos.

En el próximo tema, Credenciales y aprovisionamiento, desarrollamos identidad por dispositivo, claves protegidas y alta de equipos nuevos, incluyendo su mantenimiento y retiro.