La lección anterior terminó con una pregunta aplazada cuatro veces: toda la seguridad de TLS descansa en la validación de un certificado, ¿y quién responde de ese certificado? Esta lección abre esa caja y, con ella, lo que el módulo 2 anunció como el problema realmente difícil. Su tesis se puede enunciar en una frase: los algoritmos casi nunca fallan; la gestión de claves sí. AES no se ha roto, RSA no se ha roto, SHA-256 no se ha roto —pero se filtran claves en repositorios, caducan certificados que nadie vigilaba, se pierden claves que hacían falta para restaurar una copia y se dejan credenciales activas años después de que su dueño se marchara. Vas a ver el ciclo de vida completo de una clave, dónde debe vivir, cómo se rota sin cortar el servicio, qué contiene un certificado X.509, cómo funciona la cadena de confianza y qué hace realmente una autoridad de certificación.

1. La tesis: los algoritmos no fallan, la gestión sí
2. Ciclo de vida de una clave
3. Dónde vive una clave: del .env al HSM
4. El secreto en el repositorio: por qué borrar el commit no basta
5. Rotación sin cortar el servicio
6. Certificados X.509: qué contienen exactamente
7. La cadena de confianza y qué valida el navegador
8. Autoridades de certificación y tipos de validación
9. ACME y Let's Encrypt: emisión y renovación automática
10. Revocación: CRL, OCSP, grapado y sus límites
11. Transparencia de certificados
12. PKI interna: cuándo montar una CA propia
13. Cifrado de sobre
14. Custodia, copia de claves y el dilema de perderlas

Repasa mentalmente los incidentes que has estudiado en el curso. En Equifax (02-06) la brecha entró por un parche pendiente, pero lo que la convirtió en histórica fue que un certificado caducado dejó ciego durante diez meses al sistema que inspeccionaba el tráfico. En el ransomware de Nimbus (02-06) el atacante no rompió nada: encontró un secreto olvidado en un .env y con él escaló. En la fuga por bucket mal configurado ni siquiera hubo criptografía implicada.

De ahí que este módulo, que ha dedicado cinco lecciones a las primitivas, dedique la más operativa a la gestión. La pregunta profesional no es «¿qué algoritmo uso?», sino «¿dónde vive esta clave, quién la puede leer, cuándo se rota y qué pasa si la pierdo?».

Una clave no es un valor: es un objeto con estados, y cada transición tiene preguntas que hay que responder por escrito.

La fase que casi nadie documenta es la última, y es la que produce el hallazgo clásico: una clave que se dio de baja «hace años» y sigue funcionando en un sistema olvidado.

La diferencia conceptual entre gestor de secretos y KMS merece precisión, porque se confunden: un gestor de secretos te entrega el secreto de forma controlada y auditada (la aplicación acaba teniendo el valor en memoria); un KMS o un HSM no te entregan nada, sino que operan por ti —«cifra esto», «firma esto»— y la clave maestra no sale nunca. Por eso el KMS es la pieza correcta para la clave maestra del cifrado de sobre (apartado 13).

Recomendación concreta para Nimbus, coherente con su tamaño y presupuesto: gestor de secretos para credenciales de base de datos, claves de API, secreto del webhook y clave de firma de tokens, con inyección en el arranque de los contenedores y cero secretos en el repositorio; KMS del proveedor cloud para la clave maestra que protege las claves de datos de adjuntos, notas clínicas y copias; módulo seguro del dispositivo para las passkeys de la plantilla, que ya lo usan sin que nadie lo configure; y HSM no, salvo que un cliente o una norma sectorial lo exija, porque su coste no se justifica frente al riesgo real de Nimbus.

Este es el escenario que abrió la escalada en el caso de ransomware de 02-06: un fichero .env antiguo, con un token de API sin caducidad, versionado por error.

Cómo se detecta:

Además del escaneo en el CI (02-04), conviene una alerta que vigile los repositorios públicos de la organización y los forks.

Por qué borrar el commit no basta. Es el punto que casi todo el mundo entiende mal:

Qué significa realmente rotar. No es «cambiar el valor en el .env». Es: (1) emitir una credencial nueva; (2) desplegarla en todos los consumidores; (3) revocar la antigua de forma efectiva, comprobando que ya no funciona; (4) revisar los registros de uso de la antigua desde la fecha en que se expuso, buscando accesos no reconocidos; (5) documentar el incidente. Mientras no se ejecute el paso 3, la credencial sigue siendo válida por mucho que la hayas borrado del código.

Y el orden correcto: primero rotar, después limpiar el historial. Limpiar el historial es higiene; rotar es la contención. Invertir el orden deja la ventana abierta mientras se hace el trabajo largo.

Rotar da miedo porque parece que obliga a un corte: si cambias la clave, todo lo firmado con la anterior deja de validar. La solución es el periodo de solapamiento con dos claves activas y un identificador de clave, el kid, que ya viste funcionando en la validación de JWT con JWKS de 02-05.

La idea: cada objeto firmado o cifrado lleva escrito con qué clave se hizo, así que el verificador puede tener varias claves cargadas y elegir la correcta.

Las cuatro fases de una rotación limpia:

Puntos importantes: el kid viene de un mensaje no confiable, así que sirve solo para seleccionar la clave, nunca para decidir si validar; si el kid no está en tu lista, se rechaza el token, sin excepciones. Y una rotación que solo se ejecuta manualmente «cuando toca» no se ejecuta: automatiza el proceso y ensáyalo al menos una vez con calma antes de necesitarlo con prisa.

Cadencias razonables para Nimbus:

Un certificado digital es un documento que une una clave pública a una identidad, firmado por una autoridad en la que el verificador confía. Es la respuesta a la pregunta que quedó abierta en 03-03: ¿de quién es esta clave pública?

Campo a campo, con lo que hay que mirar en una revisión:

El error de comprensión más frecuente es creer que el navegador compara el dominio con el CN. No lo hace desde hace años: compara con el SAN. Un certificado sin el dominio en el SAN produce un error de nombre por muy correcto que sea el CN.

Por qué existe la intermedia. La clave de la raíz es demasiado valiosa para usarla a diario: vive desconectada, en un HSM, y solo se saca en ceremonias auditadas. La intermedia hace el trabajo diario y, si se compromete, se revoca y se sustituye sin invalidar la raíz —que está instalada en miles de millones de dispositivos y no se puede cambiar fácilmente—.

Qué comprueba exactamente el cliente al validar, en orden:

1. Firma de cada eslabón: la hoja está firmada por la intermedia, la intermedia por la raíz.
2. La raíz está en el almacén de confianza del sistema o del navegador.
3. Vigencia: la fecha actual cae dentro del Validity de todos los certificados de la cadena.
4. Nombre: el dominio solicitado coincide con alguna entrada del SAN de la hoja.
5. Usos: Key Usage y Extended Key Usage permiten autenticación de servidor TLS.
6. Basic Constraints: los intermedios son CA:TRUE y la hoja CA:FALSE.
7. Revocación: consulta OCSP o grapado (apartado 10).
8. Transparencia: los navegadores exigen SCTs válidos (apartado 11).
9. Firma del handshake: el CertificateVerify de 03-05 demuestra que el servidor posee la clave privada. Sin este paso, presentar un certificado ajeno bastaría.

El error operativo más común es enviar solo la hoja y olvidar la intermedia. Los navegadores de escritorio suelen recuperarla y disimulan el fallo; muchos clientes de API, la app móvil y las librerías HTTP no, y el resultado es la incidencia clásica de «funciona en el navegador pero falla en la app». Por eso se sirve fullchain.pem, no cert.pem.

Una CA es una organización en la que los fabricantes de sistemas operativos y navegadores han decidido confiar, tras auditorías periódicas. Su negocio es verificar identidades antes de firmar.

La conclusión, que sorprende a mucha gente: desde el punto de vista técnico y de la experiencia del usuario, DV, OV y EV son equivalentes. Los navegadores dejaron de destacar visualmente el EV precisamente porque los estudios mostraron que los usuarios no percibían la diferencia, mientras que el coste y la fricción sí eran reales.

Para Nimbus: certificados DV emitidos con ACME. Solo cabe plantearse OV si un cliente corporativo lo exige por contrato, y conviene saber argumentar que esa exigencia rara vez aporta seguridad técnica.

Y una limitación honesta del modelo: cualquiera de las CA del almacén puede emitir un certificado para cualquier dominio. Ha ocurrido, por compromiso o por error de una CA. Las respuestas a ese riesgo son la transparencia de certificados (apartado 11), el registro CAA en el DNS —que declara qué CA pueden emitir para tu dominio— y, en casos concretos, el pinning con sus riesgos (03-05).

ACME es el protocolo que automatiza la emisión: el cliente demuestra el control del dominio superando un reto y recibe el certificado sin intervención humana.

Dos retos y cuándo usar cada uno: HTTP-01 sirve un fichero bajo /.well-known/acme-challenge/ y es el más simple, pero exige el puerto 80 accesible y no permite comodines; DNS-01 publica un registro TXT, funciona sin exponer nada y sí permite comodines, a cambio de necesitar credenciales de tu proveedor de DNS —que a su vez son un secreto que hay que gestionar—.

Un certificado caducado es una incidencia de disponibilidad. El servicio no se degrada: se cae, con un aviso de seguridad a pantalla completa que además destruye la confianza del usuario. Y recuerda Equifax (02-06): allí el certificado caducado no tumbó una web, sino que cegó el sistema de inspección de tráfico durante diez meses, lo que permitió que la exfiltración pasara desapercibida. De ahí la regla transferible de aquella lección: todo control necesita un control que verifique que sigue funcionando.

Aplicado a Nimbus: la renovación automática no es el control suficiente; el control es la monitorización externa de la fecha de caducidad, que alerta a 30 y a 7 días y funciona aunque el proceso de renovación se haya roto en silencio. Los tres motivos habituales de rotura: el temporizador se desactivó tras una migración, el reto HTTP-01 dejó de resolver por un cambio de configuración, o el certificado se renueva pero nadie recarga el servicio que lo sirve.

Si una clave privada se filtra, el certificado sigue siendo criptográficamente válido hasta su caducidad. Hace falta un mecanismo para decir «este ya no vale».

La consecuencia incómoda hay que decirla claramente: la revocación funciona peor de lo que parece. Como los clientes fallan en abierto para no romper la navegación cuando la CA no responde, un atacante que controla la red puede simplemente bloquear la consulta OCSP. Por eso la industria se ha movido hacia certificados de vida corta —60 o 90 días, y bajando— como sustituto práctico de la revocación: si el certificado caduca pronto, la ventana de daño es corta por construcción.

Qué debe hacer Nimbus si se filtra la clave privada de su certificado: (1) emitir un certificado nuevo con una clave nueva —nunca reutilizar la clave comprometida—; (2) desplegarlo; (3) revocar el anterior, sabiendo que la revocación es una medida parcial; (4) revisar registros en busca de uso indebido; (5) analizar cómo se filtró la clave.

La transparencia de certificados (CT) responde al riesgo del apartado 8: que una CA emita un certificado para tu dominio sin tu conocimiento. Toda CA pública debe publicar cada certificado que emite en registros públicos, append-only y auditables —la misma idea que la tabla de auditoría de Nimbus, con INSERT pero sin UPDATE (01-04)—, y el navegador exige pruebas de esa publicación (los SCTs que viste en el certificado del apartado 6).

Esto no impide una emisión indebida, pero la hace imposible de ocultar. Y ahí está su valor para Nimbus: convierte un ataque invisible en uno detectable.

Cómo lo usa Nimbus, en concreto: (1) suscribirse a la monitorización de CT para nimbusreservas.example y todos sus subdominios, con notificación a Lucía y a Marta; (2) revisar cada alerta, porque un certificado que Nimbus no ha solicitado es un incidente que se activa de inmediato; (3) publicar un registro CAA en el DNS declarando la única CA autorizada, lo que además reduce el ruido de la monitorización; y (4) usar CT también como inventario, porque la lista de certificados emitidos revela subdominios olvidados que nadie recordaba, algunos con servicios expuestos —es decir, es una herramienta de reducción de superficie de ataque (01-04) además de detección—.

Para el mTLS entre servicios internos (03-05) no sirven las CA públicas, porque no emiten certificados para nombres internos ni para identidades de servicio. La alternativa es una CA privada cuya raíz se instala en los sistemas propios.

Los riesgos de hacerlo mal, que son serios: una raíz interna instalada en los portátiles puede emitir certificados válidos para cualquier dominio, incluidos los de la banca del empleado; si su clave se filtra, el atacante puede suplantar cualquier sitio ante esos equipos. Además, una CA sin revocación operativa, sin renovación automatizada o sin inventario se convierte en una fuente de caídas, y una raíz con veinte años de validez y sin plan de sustitución es una deuda que hereda quien venga después.

Reglas mínimas si Nimbus la monta: raíz fuera de línea con la clave protegida y respaldada; intermedia para la emisión diaria; vidas cortas y emisión automatizada (por ejemplo, con la PKI de un gestor de secretos, que hace este trabajo bien); ámbito acotado a nombres internos, nunca a dominios públicos; inventario de todos los certificados emitidos; y un plan escrito de rotación de la raíz.

El cifrado de sobre (envelope encryption) es el patrón estándar para cifrar muchos datos con pocas claves maestras, y es la aplicación del cifrado híbrido de 03-03 al almacenamiento.

Cómo funciona en Nimbus, paso a paso: (1) al subir un adjunto, la API pide al KMS una clave de datos y recibe dos versiones, una en claro para usar ahora y otra cifrada con la clave maestra; (2) cifra el adjunto con la clave en claro usando AES-256-GCM con nonce único y AAD con el tenant_id (03-02); (3) descarta la clave en claro de memoria y guarda junto al objeto la clave de datos cifrada, el nonce y el identificador de la clave maestra; (4) para descifrar, pide al KMS que descifre la clave de datos, la usa y la vuelve a descartar.

Las cuatro ventajas que explican por qué es el patrón dominante:

Esa última fila es un control de detección infravalorado: si alguien intenta descifrar diez mil adjuntos en una hora, el registro del KMS lo muestra aunque la aplicación esté comprometida.

Aquí está la tensión más incómoda de toda la gestión de claves, y no tiene una solución elegante:

No existe un punto medio automático: es una decisión de negocio que hay que tomar explícitamente y por escrito, distinta para cada tipo de clave.

Buenas prácticas de custodia, cuando la respuesta es sí:

• Copia cifrada y en ubicación distinta de los datos que protege, con control de acceso independiente.
• Reparto entre varias personas cuando la clave es crítica: la reconstrucción exige, por ejemplo, dos de tres custodios. Evita el punto único de fallo y también el punto único de abuso.
• Ensayo de recuperación al menos una vez al año, documentado. Una custodia que nunca se ha probado es una suposición, exactamente igual que una copia de seguridad no restaurada (02-04).
• Procedimiento escrito de quién puede solicitar la recuperación, quién la aprueba y cómo se registra.

Nota de validación profesional. Cuando la clave protege datos que revelan información de salud —como las notas clínicas de las clínicas cliente de Nimbus—, el diseño de custodia tiene implicaciones legales: quién puede acceder al dato, con qué base jurídica, durante cuánto tiempo se conserva y qué ocurre con las claves al final del periodo de conservación. La destrucción de la clave puede ser, de hecho, un mecanismo válido de supresión de datos, pero eso debe validarse con el responsable de protección de datos y con asesoría legal antes de apoyarse en ello. El marco normativo se trata en 06-03.

1. Secretos en el repositorio. El más frecuente y el más caro. Escáner en el CI y ganchos de pre-commit.
2. Creer que borrar el commit resuelve algo. Solo la rotación efectiva resuelve; y primero se rota, después se limpia.
3. No saber cuántas claves hay. Sin inventario —clave, propósito, dueño, ubicación, fecha de rotación— no hay gestión posible.
4. No rotar nunca «porque funciona». Una clave sin rotación acumula exposición: cada persona que pasó por el equipo pudo verla.
5. Rotar sin kid ni solapamiento. Convierte una operación rutinaria en un corte de servicio, y por eso deja de hacerse.
6. Guardar la clave junto al dato cifrado. Cifrado decorativo. Especialmente grave con las copias.
7. Confiar solo en la renovación automática de certificados. Hace falta monitorización externa de la caducidad, con alerta a 30 y 7 días.
8. Servir solo la hoja sin la intermedia. Funciona en el navegador y falla en la app móvil.
9. Validar el CN en lugar del SAN.
10. Suponer que la revocación funciona. Falla en abierto. Vidas cortas y rotación son la defensa real.
11. Montar una CA interna sin mantenerla. Una raíz interna mal custodiada es una llave maestra para atacar a tus propios equipos.
12. No hacer copia de la clave maestra de datos, o hacerla y no probarla nunca. Ambas cosas acaban igual de mal.

Consejos

• Empieza por el inventario: lista todas las claves, secretos y certificados con dueño, propósito, ubicación y fecha de rotación. Es una tarde de trabajo y cambia por completo la conversación.
• Automatiza lo que puedas: emisión ACME, renovación, rotación con solapamiento, escaneo de secretos. Lo manual no se hace.
• Ensaya una rotación completa y una recuperación desde custodia antes de necesitarlas.
• Aplica el principio de propósito único: una clave, una función. Deriva con HKDF (03-02) en lugar de reutilizar.
• Y recuerda la tesis: si algún día tienes un incidente criptográfico, lo más probable es que la causa sea una clave mal gestionada, no un algoritmo roto.

Un escaneo detecta que hace catorce meses se subió al repositorio un fichero deploy/.env.produccion con la contraseña de PostgreSQL, la clave de la API de la pasarela y el secreto de firma de tokens. El repositorio es privado, con acceso de los cinco del equipo y de dos personas de la consultora (A-19).

Se pide: (a) ordena las acciones de las primeras cuatro horas y justifica el orden; (b) explica qué significa exactamente rotar cada uno de los tres secretos y qué riesgo de corte tiene cada rotación; (c) indica qué registros revisarías y con qué ventana temporal; (d) di si esto es un incidente de seguridad notificable y qué información necesitas para decidirlo; (e) propón las tres medidas preventivas que impiden que vuelva a ocurrir.

La app móvil de Nimbus falla con «certificado no válido» mientras la web funciona correctamente en el navegador. La salida de openssl s_client muestra:

Se pide: (a) diagnostica la causa exacta; (b) explica por qué el navegador funciona y la app no; (c) indica la corrección concreta en el servidor; (d) propón la comprobación automática que detectaría este fallo antes de que lo reporte un cliente; (e) enumera otros tres motivos distintos por los que un certificado válido puede fallar en un cliente.

Marta pide un documento de una página con el esquema de gestión de claves.

Se pide: construye una tabla con al menos seis claves o secretos de Nimbus (firma de tokens, cifrado de adjuntos, cifrado de copias, credenciales de base de datos, secreto del webhook, certificado TLS) indicando para cada uno: dónde vive, quién puede acceder, cadencia de rotación, si tiene copia de seguridad y dónde, y qué ocurre si se pierde. Justifica después las dos decisiones más discutibles de tu tabla.

Ejercicio 1

(a) Primeras cuatro horas, en orden:

1. Considerar los tres secretos comprometidos. Sin discusión: catorce meses y nueve personas con acceso, incluidas dos externas.
2. Rotar primero la clave de la pasarela de pago. Es la de mayor impacto económico directo y la rotación es la menos disruptiva (se coordina con el proveedor).
3. Rotar el secreto de firma de tokens con el mecanismo de solapamiento del apartado 5, para no expulsar a todos los usuarios.
4. Rotar la contraseña de PostgreSQL, coordinada con un despliegue, ya que afecta a todos los procesos que conectan.
5. En paralelo, revisar registros de uso de los tres secretos.
6. Después, limpiar el historial del repositorio y comunicarlo al equipo y a la consultora.

El orden responde a que rotar es contención y limpiar el historial es higiene: mientras la credencial siga siendo válida, borrar el commit no cambia nada.

(b) Qué significa rotar cada uno:

(c) Registros y ventana. Ventana: desde la fecha del commit (catorce meses) hasta hoy, no solo desde la detección. Registros: accesos y transacciones en el panel de la pasarela; conexiones a PostgreSQL por origen, usuario y horario inusual; emisión y uso de tokens con firmas anómalas; accesos al bucket A-05; y actividad del repositorio (clones, forks, accesos de las cuentas de la consultora). Se buscan orígenes desconocidos, horarios fuera de patrón y volúmenes anómalos, igual que en el análisis de 02-06.

(d) ¿Es notificable? Es un incidente de seguridad con certeza. Es notificable si hay indicios de acceso no autorizado a datos personales. Para decidirlo hacen falta: registros suficientes y con retención adecuada para cubrir catorce meses (si no los hay, eso ya es un hallazgo grave y empuja hacia la prudencia), evidencia de accesos anómalos, y el alcance de los datos alcanzables con esas credenciales —que aquí incluye datos que revelan indirectamente salud—. La decisión se toma con asesoría legal y con el responsable de protección de datos, dentro del plazo de 72 horas del RGPD (06-03).

(e) Tres medidas preventivas: (1) escáner de secretos en el CI y gancho de pre-commit que bloquee el commit, más un .gitignore correcto; (2) gestor de secretos con inyección en el arranque, de modo que no exista ningún .env con valores reales; (3) rotación automática programada con solapamiento, para que ninguna credencial acumule catorce meses de vida y para que rotar sea una operación rutinaria y no una emergencia.

Ejercicio 2

(a) Causa exacta. El servidor envía solo el certificado de hoja (0 s:), sin el certificado intermedio de Let's Encrypt. El código 20 significa literalmente que el cliente no puede obtener el emisor local: no puede construir la cadena hasta una raíz de confianza.

(b) Por qué el navegador sí funciona. Los navegadores de escritorio suelen tener el intermedio en caché de visitas anteriores o lo descargan mediante la extensión Authority Information Access del certificado. Esa recuperación es una cortesía, no parte de la validación estándar, y muchas librerías HTTP y clientes móviles no la implementan: exigen que el servidor envíe la cadena completa, como manda el estándar.

(c) Corrección. Configurar ssl_certificate apuntando a fullchain.pem (hoja + intermedia), no a cert.pem, y recargar Nginx. Verificar después con openssl s_client, donde deben aparecer los dos eslabones y Verify return code: 0 (ok).

(d) Comprobación automática. Una tarea programada externa que, para cada dominio, ejecute openssl s_client sin usar el almacén local de intermedios y verifique tres cosas: código de retorno 0, número de certificados en la cadena mayor que uno, y días restantes de validez por encima del umbral. Alerta a Lucía si falla cualquiera. Es el «control que verifica que el control funciona» de Equifax aplicado aquí.

(e) Otros tres motivos: (1) el dominio no está en el SAN (aunque el CN sea correcto); (2) fecha del cliente desajustada, que hace que un certificado vigente parezca caducado o no válido todavía —frecuente en móviles y en dispositivos recién instalados—; (3) pinning desactualizado en la app tras una renovación de certificado (03-05). Un cuarto habitual: la raíz correspondiente no está en el almacén de un sistema antiguo sin actualizar.

Ejercicio 3

Las dos decisiones más discutibles:

1. No hacer copia de la clave de firma de tokens. Discutible porque perderla expulsa a todos los usuarios a la vez. Se justifica porque el impacto es molestia, no pérdida de datos: los usuarios vuelven a entrar. Una copia, en cambio, sería una superficie permanente para un secreto que permite suplantar a cualquier usuario. El riesgo de la copia supera al del corte.
2. Guardar la clave de las copias en una cuenta distinta, con dos de tres custodios. Discutible por la fricción que añade a una restauración urgente: si Lucía está de baja y falta un custodio, la restauración se retrasa. Se justifica por la lección directa del ransomware de 02-06: la clave y las copias en el mismo entorno significa que quien compromete producción se lleva ambas. La mitigación de la fricción es tener tres custodios y ensayar la recuperación una vez al año, de modo que el procedimiento esté probado antes de necesitarlo.

Has entrado en el problema difícil y sales con su tesis interiorizada: los algoritmos casi nunca fallan; la gestión de claves sí. Lo has visto en los incidentes del curso —el certificado caducado de Equifax que cegó la detección diez meses, el .env de Nimbus que abrió la escalada— y en el contraste entre lo que la gente teme y lo que realmente ocurre. Tienes el ciclo de vida completo de una clave, con las preguntas que hay que responder en cada fase y la constatación de que la fase que nadie documenta —la destrucción— es la que produce credenciales activas años después. Sabes dónde puede vivir una clave, del código fuente al HSM, con la distinción precisa entre un gestor de secretos, que te entrega el valor, y un KMS o HSM, que operan por ti sin entregarte nada; y con la recomendación concreta para Nimbus: gestor de secretos para credenciales, KMS para la clave maestra de datos, módulo del dispositivo para las passkeys y HSM solo si alguien lo exige.

Has aprendido qué significa realmente rotar —emitir, desplegar, revocar de forma efectiva, revisar registros y documentar—, por qué borrar el commit no revoca nada y por qué se rota antes de limpiar el historial; y has visto cómo se rota sin cortar el servicio con solapamiento y kid, la misma pieza que sostenía la validación de JWT de 02-05. En la parte de PKI has abierto un certificado X.509 campo a campo y sabes que lo que valida el navegador es el SAN y no el CN; entiendes la cadena de confianza y por qué existe la intermedia, los nueve pasos que comprueba el cliente y el fallo clásico de servir la hoja sin la intermedia; sabes que DV, OV y EV son técnicamente equivalentes y que cualquier CA del almacén puede emitir para tu dominio; manejas ACME y sabes que la renovación automática no es el control suficiente —el control es la monitorización externa de la caducidad—; conoces los límites reales de la revocación, que falla en abierto y ha sido sustituida en la práctica por certificados de vida corta; y sabes usar la transparencia de certificados para detectar emisiones indebidas y, de paso, como inventario de subdominios olvidados. Añades cuándo tiene sentido una PKI interna y sus riesgos, el cifrado de sobre con clave de datos y clave maestra —que además deja auditoría por objeto en el KMS— y el dilema honesto de la custodia: copiar de más multiplica la superficie, copiar de menos convierte el cifrado en pérdida definitiva, y no hay punto medio automático, solo una decisión escrita por tipo de clave.

Ya tienes todas las piezas del módulo: las primitivas, los protocolos que las ensamblan y la gestión que las sostiene. En Aplicaciones de la Criptografía (03-07) cerramos recorriendo el sistema de Nimbus de punta a punta y señalando qué protege qué: el cifrado en reposo con sus tres niveles —disco, base de datos y aplicación— y el punto clave de que el cifrado de disco no protege frente a una API comprometida; el cifrado campo a campo de las notas clínicas con el problema práctico que introduce, que ya no se puede buscar ni indexar; las copias cifradas con la clave fuera del entorno; la firma de artefactos en el CI/CD y su conexión con SolarWinds; los tokens y las URL firmadas de 120 segundos explicadas por dentro; y la diferencia real entre seudonimización y anonimización, con el motivo por el que el hash de un DNI no es anonimización.