Limitaciones de AWS Certificate Manager: Dónde se queda corto ACM para la infraestructura de clave pública empresarial

AWS Certificate Manager (ACM) es un servicio administrado que aprovisiona, implementa y renueva certificados. Certificados TLS / SSL Para los servicios integrados en AWS, se ha convertido en el punto de partida predeterminado para los certificados TLS en el ecosistema de AWS, y con razón: es gratuito para los servicios integrados, está totalmente administrado y, una vez configurado, es prácticamente invisible. Sin embargo, la administración de certificados rara vez se mantiene dentro del entorno de AWS.

A medida que las empresas distribuyen sus cargas de trabajo entre múltiples nubes, infraestructura local y una creciente variedad de autoridades de certificación, la pregunta deja de ser "¿Es ACM bueno?" y se convierte en "¿Cuándo deja de ser suficiente ACM?". Este blog responde a esa pregunta. Describe dónde encaja realmente ACM y sus limitaciones prácticas. PKI Los equipos se topan con los problemas que surgen al ir más allá de los servicios nativos de AWS, los factores económicos que impulsan esos límites y cómo una plataforma CLM independiente del proveedor puede llenar esos vacíos, especialmente a medida que la reducción de los períodos de validez de los certificados y la transición posterior a la era cuántica aumentan los riesgos.

Dónde encaja ACM y dónde no.

Si toda su carga de trabajo reside detrás de un Application Load Balancer, con Amazon CloudFront como interfaz y accesible a través de Amazon API Gateway, AWS Certificate Manager (ACM) es una opción prácticamente imbatible. Emite certificados TLS públicos sin costo alguno para estos servicios integrados, se encarga de la renovación y su costo operativo es mínimo. Para equipos que trabajan exclusivamente con AWS y operan en una infraestructura controlada, es uno de los mejores servicios administrados que ofrece AWS.

El problema comienza en el momento en que la seguridad de los certificados se extiende más allá de los límites de AWS. La mayoría de las empresas con las que trabajamos en Encryption Consulting no utilizan exclusivamente AWS. Utilizan una combinación de Microsoft AD CS local, autoridades de certificación de terceros como DigiCert o Entrust para certificados de confianza pública, HashiCorp Vault PKI para mallas de servicios y cargas de trabajo de DevOps, y una larga lista de cargas de trabajo en F5 BIG-IP, NGINX, Apache Tomcat e IIS que no tienen nada que ver con AWS.

Según el informe "Estado de la nube 2024" de Flexera, alrededor del 89 % de las empresas han adoptado la multinube, y Gartner proyecta que más del 90 % de las organizaciones utilizarán la nube híbrida para 2027. En ese contexto, una herramienta CLM que solo puede administrar un proveedor de nube, en una sola región, es, en el mejor de los casos, una solución parcial.

Este blog analiza las limitaciones prácticas de ACM con las que se topan los equipos de PKI durante las implementaciones empresariales, la economía que hay detrás de ellas y cómo una plataforma CLM neutral respecto al proveedor como la de Encryption Consulting Administrador de CertSecure Cierra las lagunas que deja abiertas ACM.

ACM vs. Autoridad de Certificación Privada de AWS: Un breve repaso

Antes de continuar, conviene diferenciar dos servicios de AWS que a menudo se confunden. AWS cambió el nombre de "ACM Private CA" a "AWS Private CA" en septiembre de 2022, y esta distinción es importante al consultar las páginas de precios o diseñar los flujos de inscripción.

AWS Certificate Manager (ACM) es el servicio de gestión del ciclo de vida. Emite, implementa y renueva certificados TLS públicos de la CA pública de Amazon, y también actúa como capa de administración para los certificados privados emitidos por AWS Private CA. Los certificados públicos emitidos por ACM que se utilizan exclusivamente con servicios integrados de AWS (ELB, CloudFront, API Gateway, App Runner y similares) son gratuitos.

AWS Private CA es la infraestructura de CA privada administrada. Ejecuta su jerarquía de CA en FIPS 140-2 Las claves están protegidas por hardware, pero se paga una cuota mensual por cada CA, además de los cargos por certificado emitido.

Las limitaciones que se detallan a continuación se aplican a ambos, ya que se ofrecen como una única experiencia para la mayoría de los equipos.

Limitaciones en el mundo real de AWS Certificate Manager

1. El certificado público gratuito nunca fue realmente tuyo.

La principal característica de ACM es el certificado TLS público gratuito, pero la clave privada de un certificado público ACM "estándar" no se puede exportar. El certificado solo se puede vincular a servicios de AWS integrados con ACM. Si su punto final de terminación TLS es cualquier otro (una instancia EC2 con NGINX, un F5 local, un Azure App Service, un balanceador de carga de GCP, una CDN de terceros o un dispositivo de hardware), el certificado ACM gratuito simplemente no se puede implementar allí. Terminará ejecutando flujos de trabajo paralelos: un flujo administrado por ACM para los servicios integrados con AWS y un proceso completamente separado para todo lo demás. Esto genera una deuda operativa que se acumula.

AWS Esto se abordó parcialmente En junio de 2025, con certificados públicos exportables, que permiten descargar la clave privada e implementar el certificado en cualquier lugar. La flexibilidad es real, pero la economía cambia drásticamente:

• 7 dólares por nombre de dominio completamente cualificado (FQDN), que se cobran en el momento de la emisión y de nuevo en cada renovación.
• 79 dólares por nombre comodín (por ejemplo, *.tudominio.com), tanto en el momento de la emisión como en cada renovación.
• Los certificados ACM tienen una validez máxima de 13 meses, con renovación a los 11 meses, por lo que las renovaciones se producen aproximadamente una vez al año en la actualidad.

Eso parece modesto hasta que haces los cálculos a escala empresarial. Con el Foro de CA/Browser Reducción gradual de la validez (200 días a partir de marzo de 2026, 100 días a partir de marzo de 2027, 47 días a partir de marzo de 2029), las renovaciones pasarán de ser anuales a aproximadamente cada seis semanas en un plazo de tres años. Multiplique esto por 500 o 5,000 FQDN y el "administrador de certificados gratuito" se convierte en un costo recurrente por certificado que aumenta linealmente con la cantidad de certificados.

La conclusión no es que los certificados exportables sean descabellados, sino que el modelo de precios de ACM se diseñó para uso interno de AWS. En el momento en que se utiliza fuera de ese ámbito, el modelo de costes cambia radicalmente y se empiezan a pagar tarifas por certificado, además de la infraestructura de automatización necesaria para la implementación.

2. La automatización se detiene en el límite de AWS.

Dentro de AWS, ACM es excelente. Las renovaciones en ELB, CloudFront, API Gateway y servicios similares se gestionan automáticamente. El certificado rota, el servicio integrado detecta el nuevo certificado y el operador no tiene que hacer nada.

Fuera de AWS, ACM no implementa nada. Para un certificado exportable destinado a un F5 local, un servidor NGINX, un Citrix ADC, un ingress de Kubernetes que no esté en EKS o cualquier otro punto final que no sea de AWS, la responsabilidad de ACM termina con la llamada a la API. Puede suscribirse a Amazon EventBridge para recibir notificaciones de renovación, pero el aprovisionamiento, la rotación de claves en el dispositivo, la vinculación del servidor virtual en el balanceador de carga, el reinicio del servicio de escucha y la validación del nuevo certificado son responsabilidad exclusiva del usuario.

Esto implica scripts personalizados, políticas de IAM personalizadas, manejo de errores personalizado y un registro de auditoría personalizado. Todos los equipos a los que hemos ayudado a desarrollar esto terminan reinventando el mismo plano de control: una cola de eventos de certificados, un proceso que obtiene el nuevo certificado, una biblioteca de conectores para cada tipo de punto final de destino, un mecanismo de reintento para fallos parciales y un plan de reversión cuando el nuevo certificado interrumpe el funcionamiento de la aplicación. Esto es precisamente lo que se supone que debe hacer una plataforma CLM diseñada específicamente para este fin, y es precisamente lo que ACM no hace una vez que se sale del perímetro de AWS.

3. El inventario está fragmentado por cuenta y región.

El inventario de ACM está limitado a una sola cuenta de AWS y una sola región. Si opera con 12 cuentas y 4 regiones, tendrá que realizar un seguimiento de 48 inventarios de certificados lógicos, y no existe una vista unificada nativa para todos ellos.

La restricción de CloudFront empeora esto. Incluso si su aplicación se ejecuta completamente en ap-south-1 o eu-west-1, CloudFront requiere que el certificado esté en us-east-1.Por lo tanto, una implementación típica en varias regiones termina manteniendo el mismo certificado lógico en dos regiones: una en us-east-1 para la CDN y otra en la región de la aplicación para el balanceador de carga. No hay sincronización automática, ni inventario compartido, ni vista nativa entre regiones. En la práctica, los dominios idénticos obtienen certificados separados que se emiten y renuevan de forma independiente, sin que exista un inventario que los vincule.

Para los equipos de seguridad y auditoría, esta fragmentación es un problema real. No se puede aplicar una política a nivel de toda la organización ("no se permiten certificados RSA-2048 después del 1 de enero de 2027" o "todos los certificados deben tener un propietario registrado") si no hay un inventario único contra el cual aplicarla. No se puede realizar una evaluación de la postura criptográfica antes de la migración postcuántica Si no puedes ver lo que tienes. Y los certificados en la sombra, esos que un desarrollador solicitó hace dos años en una región que ya nadie supervisa, son precisamente los que provocan las interrupciones del servicio los sábados por la noche.

4. Los precios de AWS Private CA aumentan rápidamente.

Precios publicados de AWS Private CA Es sencillo, pero las cifras se acumulan más rápido de lo que la mayoría de los equipos esperan:

• $400 por cuenta corriente privada al mes para uso general (cualquier período de validez)
• 50 dólares por CA privada al mes para el modo de certificado de corta duración (validez máxima de 7 días).
• Tarifas de emisión por certificado de una CA de propósito general: $0.75 para los primeros 1,000, $0.35 para los siguientes 9,000 y $0.001 por encima de 10,000.
• 0.06 dólares por certificado al mes para respuestas OCSP (solo se facturan los certificados que realmente reciben consultas OCSP).

Para una jerarquía típica de dos niveles (una raíz sin conexión y una CA emisora ​​en línea), el costo mensual asciende a $800 antes de emitir un solo certificado. Si se añade alta disponibilidad entre regiones, el costo puede alcanzar fácilmente entre $1,600 y $2,400 mensuales. Para un caso de uso de fabricación o IoT que emita 50 000 certificados de dispositivos al mes, los cargos por certificado son razonables gracias al plan de volumen, pero la tarifa mensual por CA no se reduce: cada CA regional, cada jerarquía de confianza independiente y cada entorno de prueba tienen un costo fijo de $400 al mes.

Compárelo con un alojamiento propio. Jerarquía de Microsoft AD CSdonde el costo marginal por certificado después del despliegue inicial es prácticamente cero, o una oferta de PKI administrada donde el costo se amortiza de manera diferente. AWS Private CA es conveniente, pero no es la opción más económica, y el modelo de costos incentiva la consolidación en una única CA en lugar de la separación de funciones que muchos equipos de seguridad realmente desean.

5. La presentación de informes de cumplimiento es un asunto que uno mismo debe desarrollar.

ACM no produce informes de cumplimiento de nivel de certificado listos para usar PCI DSS, HIPAA, SOC 2, DORAo cualquier otro marco. AWS proporciona capacidades adyacentes (las reglas de AWS Config pueden detectar certificados ACM que no cumplen con las normas, Security Hub tiene asignaciones estándar que señalan los hallazgos, AWS Artifact le proporciona los informes de cumplimiento a nivel de servicio de AWS), pero ninguna de ellas es una solución integral que le permita "mostrarme, por departamento, el estado de auditoría de cada certificado, quién lo posee, qué algoritmo utiliza, cuándo vence y si se desvió de la política al momento de su emisión".

Para una empresa regulada, esta brecha se hace evidente en el momento de la auditoría. El equipo de cumplimiento solicita: «Genere un informe de cada certificado TLS incluido en el alcance, con la longitud de la clave, las entradas SAN, la propiedad, la CA emisora, la fecha de vencimiento y el cumplimiento de las políticas». Solo con ACM, este informe se genera a partir de una combinación de llamadas a describe-certificate, funciones Lambda personalizadas, exportaciones de AWS Config y una hoja de cálculo editada manualmente. El flujo de trabajo CLM maduro consiste en hacer clic en un botón y recibir el informe semanalmente programado en la bandeja de entrada del auditor.

6. La dependencia de un proveedor limita la agilidad en el ámbito de las criptomonedas.

En los próximos años convergerán dos cambios en la industria, y ambos requieren agilidad en el ámbito de las criptomonedas:

• El CA / Browser Forum Boleta electoral SC-081v3La ley, aprobada en abril de 2025, reduce la validez máxima pública de TLS de 398 días a 200 días (marzo de 2026), 100 días (marzo de 2027) y 47 días (marzo de 2029). El período de reutilización de la validación de dominio se reduce a 10 días para marzo de 2028.
• NIST criptografía post-cuántica El cronograma de transición exige que las organizaciones dejen de usar RSA y ECC heredados para 2030 y los reemplacen por completo para 2035. ML-DSA y ML-KEM (FIPS 204 y 203) son los nuevos estándares. AWS ha comenzado a agregar compatibilidad con ML-DSA a AWS KMS y AWS Private CA, pero el panorama operativo general del intercambio de algoritmos en toda la infraestructura es más complejo que el de una sola CA.

Criptoagilidad es la capacidad de intercambiar CA, algoritmos, tamaños de clave, períodos de validez y destinos de implementación sin rediseñar su plano de control. Si su administración de certificados está arquitectónicamente vinculada a un proveedor, no tiene agilidad criptográfica, tiene una dependencia. En el momento en que AWS cambia un modelo de precios, modifica un contrato de servicio, descontinúa una función o su caso de negocio cambia y necesita trasladar cargas de trabajo a Azure o GCP, el costo de deshacer esa dependencia es el costo de reconstruir su pila CLM. Esa es una mala posición en la que estar de cara a ambos 47-días de mandato y la migración de PQC.

El mandato de 47 días agudiza cada brecha

Todo lo anterior se complica a medida que disminuye la validez de los certificados. Actualmente, un certificado TLS típico se renueva una vez al año. En marzo de 2026, la renovación pasará a ser aproximadamente cada seis meses y medio. Para marzo de 2027, cada tres meses y medio. Y para marzo de 2029, cada seis semanas y media.

Esto representa un aumento de ocho veces en la frecuencia de renovación en menos de tres años. Cada deficiencia en la automatización de ACM, cada región que se debe verificar por separado, cada punto final fuera del perímetro de AWS que requiere un script de implementación manual, cada informe de cumplimiento que se elabora manualmente, todo esto aumenta linealmente con la frecuencia de renovación. Un flujo de trabajo que resulta molesto con una validez de 12 meses se vuelve operativamente insostenible a los 47 días.

Precisamente por eso, el debate en el sector ha dado un giro tan drástico hacia la gestión del ciclo de vida del cliente (CLM) de circuito cerrado e independiente del proveedor. No es que la gestión de la configuración de aplicaciones (ACM) sea mala, sino que la automatización parcial simplemente no es viable ante tal volumen de trabajo.

Cómo CertSecure Manager aborda estas deficiencias

Administrador de CertSecureLa plataforma CLM de Encryption Consulting fue desarrollada por profesionales de PKI que se enfrentan a estos mismos escenarios en sus proyectos con clientes a diario. Donde ACM se detiene en el límite de AWS, CertSecure Manager va más allá:

• CertSecure Manager, diseñado para funcionar con múltiples CA y sin depender de proveedores específicos, se conecta a Microsoft AD CS, AWS Private CA, HashiCorp Vault PKI, DigiCert, Entrust y otras CA públicas y privadas a través de una única consola. Obtendrá un inventario, un plano de políticas y una cola de renovación unificados, independientemente de la CA que emitió el certificado o de la nube donde se ejecute la carga de trabajo.
• Automatización de ciclo cerrado más allá de AWS. Los agentes de renovación para Apache, Tomcat, IIS, F5 BIG-IP, NGINX y aplicaciones internas personalizadas gestionan el paso de implementación que ACM no realiza. El nuevo Orquestador de CertSecure Manager para F5Esta solución, desarrollada a través de nuestra colaboración en el Programa de Socios de la Plataforma de Seguridad y Entrega de Aplicaciones de F5, asigna automáticamente cada certificado al perfil SSL del servidor virtual de F5 correcto, eliminando el paso de vinculación manual que causa la mayoría de las interrupciones de F5 relacionadas con los certificados.
• Protocolos de registro estándar. La API REST y los puntos finales ACME permiten que las cargas de trabajo nativas de la nube y de DevOps se registren automáticamente, del mismo modo que lo harían con Let's Encrypt o cualquier punto final ACME estándar. Esto significa que cert-manager en Kubernetes, certbot en un host Linux o una canalización de CI/CD personalizada pueden registrarse mediante el mismo protocolo.
• Visibilidad centralizada en la nube y en las instalaciones. El descubrimiento automatizado de certificados analiza su entorno, crea un inventario unificado en cuentas y regiones de AWS, Azure, GCP, instalaciones locales y clústeres de Kubernetes, y muestra la propiedad, el algoritmo, la validez y el cumplimiento de las políticas de cada certificado en un único panel.
• Aplicación y aprobación de políticas. Las políticas globales y departamentales abarcan el tamaño mínimo de clave, los algoritmos permitidos, las restricciones aprobadas por FIPS, las reglas de uso de comodines, las reglas de reutilización de CSR, la inclusión en listas blancas de DNS para la validación de dominios y los flujos de trabajo de aprobación M-of-N para plantillas de certificados de alta seguridad. Estas políticas se aplican en el momento de la emisión, no posteriormente.
• Informes de cumplimiento listos para auditoría. Informes programados entregados semanal o mensualmente a la bandeja de entrada de cumplimiento, con el nivel de detalle de certificado que PCI DSS, HIPAALas auditorías SOC 2 y DORA realmente lo solicitan. Sin exportación manual, sin unión de hojas de cálculo.
• Agilidad criptográfica integrada. Dado que CertSecure Manager es independiente de la CA, cambiar la CA subyacente, rotar a un nuevo algoritmo de clave o migrar de un proveedor a otro es un cambio de política, no una reestructuración completa. Esto es importante tanto para el plazo de 47 días como para la migración a PQC.

Cuándo ACM es suficiente y cuándo no lo es.

No todos los equipos necesitan una plataforma CLM completa. A continuación, se presenta una perspectiva práctica sobre cuándo ACM por sí solo es suficiente y cuándo deja de serlo:

Escenario	ACM por sí solo	Gestión del ciclo de vida (CLM) independiente del proveedor
Una sola cuenta de AWS, una sola región, cargas de trabajo totalmente nativas de AWS.	Sí:	No
Menos de 100 certificados, todos en servicios integrados de ACM.	Sí:	No
Multicloud (AWS + Azure y/o GCP)	No	Sí:
Nube híbrida con infraestructura local (AD CS, F5, NGINX, Apache, IIS)	No	Sí:
Más de 1,000 certificados en múltiples CA y entornos.	No	Sí:
Estricto cumplimiento normativo (PCI DSS, HIPAA, SOC 2, DORA, industrias reguladas)	No	Sí:
Kubernetes y cargas de trabajo en contenedores que abarcan la nube.	No	Sí:
Preparación para una validez de 47 días con cualquier punto final que no sea de AWS.	No	Sí:
Abordando la migración de PQC con un conjunto heterogéneo de CA	No	Sí:

El patrón es sencillo. ACM es suficiente cuando la gestión de certificados es controlada, nativa de AWS y de tamaño reducido. En el momento en que falla cualquiera de estas tres condiciones, el coste de seguir utilizando solo ACM se traduce en complejidad operativa, dificultades en las auditorías y riesgo de interrupciones del servicio.

Conclusión

ACM es un servicio realmente bueno dentro de su ámbito de diseño. El error radica en suponer que dicho ámbito se ajusta a la realidad empresarial. La mayoría de las organizaciones operan en múltiples nubes, múltiples autoridades de certificación y una larga lista de puntos finales locales a los que ACM no puede acceder. El plazo de validez de 47 días para TLS y la migración a PQC están a punto de agravar significativamente cualquier deficiencia en la automatización, la visibilidad y la aplicación de políticas de ACM.

La estrategia adecuada consiste en usar ACM donde mejor funciona (certificados públicos gratuitos en servicios integrados con AWS, renovaciones sencillas dentro del entorno de AWS) y añadir una plataforma CLM independiente del proveedor para gestionar todo aquello para lo que ACM no fue diseñado. Esto proporciona la simplicidad operativa de ACM donde funciona y la automatización, la gobernanza y la agilidad criptográfica necesarias en todos los demás entornos.