Certificados privados y criptografía poscuántica

Cada vez que un navegador muestra el candado, confía en una cadena de firmas que termina en una autoridad que viene instalada en el sistema operativo. Tus servicios internos también necesitan probar quiénes son entre ellos, pero no tiene sentido pedirle a una autoridad pública un certificado para pagos.interno. Para eso montas tu propia infraestructura de llave pública.

Qué es una PKI

Una infraestructura de llave pública (PKI) es el conjunto de CA, políticas y procesos que emiten y administran certificados. Un certificado X.509 une una identidad (un nombre DNS, un servicio, un dispositivo) con una llave pública, y lleva la firma de la CA que lo emitió.

1. 1

   Solicitar

   El servicio genera un par de llaves y envía una solicitud de firma (CSR) con su llave pública. La llave privada no sale de donde nació.
2. 2

   Emitir

   La CA verifica la solicitud según su política y firma el certificado.
3. 3

   Distribuir y usar

   El servicio presenta el certificado en TLS; el otro extremo valida la cadena hasta una raíz confiable.
4. 4

   Renovar

   Antes de vencer se emite uno nuevo. Automatizar esto evita las caídas por certificado vencido.
5. 5

   Revocar

   Si la llave privada se filtra, la CA publica la revocación en una lista (CRL) o responde por OCSP.

AWS Private CA

AWS Private CA es una CA privada administrada: AWS guarda las llaves de tus CA en HSM y tú defines la jerarquía, las plantillas y quién puede emitir. Se comparte con otras cuentas por AWS RAM, así que una cuenta de seguridad mantiene la CA y las cuentas de aplicación emiten.

• Servicios internos y mTLS: en TLS mutuo, cliente y servidor presentan certificado. Un Application Load Balancer puede verificar certificados de cliente contra un almacén de confianza con tu CA (ver Comunicación entre servicios).
• Certificados privados en ACM: ACM emite certificados firmados por tu Private CA y los renueva solo en servicios integrados, como ELB y API Gateway.
• Kubernetes, IoT y Active Directory: un emisor para cert-manager en EKS, identidad para millones de dispositivos y un Connector for AD para emitir a equipos Windows.
• IAM Roles Anywhere: tu CA como trust anchor para cargas fuera de AWS (ver Permisos avanzados).

Una CA se crea en uno de dos modos. En propósito general emite certificados de cualquier vigencia y normalmente publica revocaciones. En certificados de corta duración solo emite certificados de hasta siete días: vencen tan rápido que puedes operar sin revocación. Ese modo debe ser la última CA de la jerarquía, y ACM no puede emitir con una CA de ese modo.

ACM, Private CA o CloudHSM

Criterio	ACM	AWS Private CA	AWS CloudHSM
Para qué	Certificados TLS públicos (y privados vía Private CA) en servicios integrados	Tu propia jerarquía de CA para identidades internas	HSM dedicados de un solo inquilino en tu VPC
Quién confía	Navegadores y clientes de internet	Solo los sistemas que instalan tu raíz	Lo que tú construyas encima
Renovación	Automática en servicios integrados	Automática si emites por ACM; si no, la automatizas tú	No aplica: es hardware para llaves
Elígelo cuando	Un sitio público detrás de CloudFront o un ALB	mTLS, IoT, contenedores, dispositivos, código interno	Una norma exige control exclusivo del HSM, o necesitas PKCS#11 o una CA propia en software

TLS 1.3

TLS 1.3 hace el apretón de manos en una ida y vuelta en vez de dos, elimina cifrados viejos y exige secreto hacia adelante (forward secrecy): robar la llave del servidor mañana no descifra el tráfico grabado hoy. En AWS lo activas eligiendo políticas de seguridad que lo incluyen en tus listeners de ALB y NLB (las que empiezan con ELBSecurityPolicy-TLS13) y en CloudFront. Deja TLS 1.2 solo si tienes clientes que no pueden actualizarse.

Criptografía poscuántica

Un computador cuántico grande podría romper RSA y la criptografía de curva elíptica, que protegen hoy casi todo el intercambio de llaves y las firmas. Nadie sabe cuándo existirá. El riesgo inmediato es «cosechar ahora, descifrar después» (harvest now, decrypt later): alguien graba tráfico cifrado hoy y lo descifra en diez años. Si tus datos deben seguir siendo secretos ese tiempo (historias clínicas, secretos industriales), el problema ya empezó. Las firmas son menos urgentes, salvo las de larga vida, como raíces de confianza y firmware.

En agosto de 2024, NIST publicó los primeros estándares: ML-KEM (FIPS 203) para establecer llaves y ML-DSA (FIPS 204) para firmas. La transición se hace en modo híbrido: se combina un intercambio clásico con ML-KEM, y la sesión es segura mientras cualquiera de los dos resista.

• 

  TLS híbrido en endpoints de AWS

  Los endpoints de KMS, ACM y Secrets Manager aceptan intercambio híbrido con ML-KEM en los endpoints no FIPS (abril de 2025), y AWS lo extiende a más endpoints públicos. Se usa si tu cliente o SDK lo negocia.
• 

  ALB y NLB

  Desde noviembre de 2025 hay políticas TLS con intercambio híbrido ML-KEM. Es opcional: cambias la política del listener.
• 

  Llaves ML-DSA en KMS

  Llaves de firma ML_DSA_44, ML_DSA_65 y ML_DSA_87 con las API de siempre (CreateKey, Sign, Verify), disponibles desde junio de 2025.
• 

  Private CA con ML-DSA

  Desde noviembre de 2025 puedes crear CA, emitir certificados y publicar CRL y OCSP con ML-DSA. IAM Roles Anywhere acepta esas PKI como trust anchor.

1. 1

   Inventario

   Dónde usas RSA y curvas elípticas: TLS externo e interno, VPN, firmas de código, certificados de dispositivos, llaves en KMS y CloudHSM.
2. 2

   Prioriza por vida útil del secreto

   Primero el tráfico que transporta datos que deben seguir secretos por años. Ahí el TLS híbrido da el mayor beneficio.
3. 3

   Actualiza clientes y bordes

   SDK y bibliotecas TLS al día, y políticas poscuánticas en ALB y NLB. La negociación híbrida solo ocurre si ambos extremos la admiten.
4. 4

   Agilidad criptográfica

   No fijes algoritmos en el código; centraliza llaves en KMS y certificados en Private CA; usa vigencias cortas para poder rotar de algoritmo rápido.
5. 5

   Prueba tamaños

   Las llaves ML-KEM y las firmas ML-DSA son más grandes que las clásicas. Revisa límites de encabezados, MTU y dispositivos con poca memoria.