Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # AWS Certificate Manager características y limitaciones de los certificados públicos Los certificados públicos proporcionados por ACM tienen las siguientes características y limitaciones. Estas se aplican solo a los certificados proporcionados por ACM. Es posible que no sean de aplicación a los [certificados importados](import-certificate.md). **Confianza en el navegador y la aplicación** Los certificados de ACM son de confianza para la mayoría de los principales navegadores, como Google Chrome, Microsoft Edge, Mozilla Firefox y Apple Safari. Los navegadores muestran un icono de candado cuando se conectan mediante TLS a sitios que utilizan certificados de ACM. Java también confía en los certificados de ACM. **Autoridad de certificación y jerarquía** Los certificados públicos que se solicitan a través de ACM se obtienen de [Amazon Trust Services](https://www.amazontrust.com/repository/), una [autoridad de certificación (CA)](https://docs.aws.amazon.com/acm/latest/userguide/acm-concepts.html#concept-ca) pública administrada por Amazon. La autoridad certificadora raíz G2 de Starfield (G2) firma de forma cruzada entre Amazon Root CAs 1 y 4. La raíz Starfield es de confianza en Android (versiones posteriores a Gingerbread) e iOS (versión 4.1\$1). Las raíces de Amazon son de confianza en iOS 11\$1. Los navegadores, las aplicaciones o las raíces OSes de Amazon o Starfield confiarán en los certificados públicos de ACM. ACM emite certificados guía o de entidad final a los clientes mediante certificados intermedios CAs, que se asignan aleatoriamente en función del tipo de certificado (RSA o ECDSA). ACM no proporciona información de CA intermedia debido a esta selección aleatoria. **Validación de dominio (DV)** Los certificados de ACM son validados por dominio e identifican solo un nombre de dominio. Al solicitar un certificado ACM, debe demostrar la propiedad o el control de todos los dominios especificados. Puede validar la titularidad a través del correo electrónico o DNS. Para obtener más información, consulte [AWS Certificate Manager validación del correo electrónico](email-validation.md) y [AWS Certificate Manager Validación de DNSValidación por DNS](dns-validation.md). **Validación HTTP** ACM admite la validación HTTP para verificar la propiedad del dominio al emitir certificados TLS públicos para su uso con. CloudFront Este método utiliza redirecciones HTTP para demostrar la propiedad del dominio y ofrece una renovación automática similar a la validación por DNS. Actualmente, la validación HTTP solo está disponible a través de la función CloudFront Distribution Tenants. **Redirección HTTP** Para la validación de HTTP, ACM proporciona una URL `RedirectFrom` y una URL `RedirectTo`. Debe configurar una redirección desde `RedirectFrom` a `RedirectTo` para demostrar el control del dominio. La `RedirectFrom` URL incluye el dominio validado y `RedirectTo` apunta a una ubicación controlada por ACM en la CloudFront infraestructura que contiene un token de validación único. **Administrado por** Certificados de ACM administrados por otro servicio que muestran la identidad de ese servicio en el campo `ManagedBy`. En el caso de los certificados que utilizan la validación HTTP con CloudFront, este campo muestra «CLOUDFRONT». Estos certificados solo se pueden utilizar a través de CloudFront. El `ManagedBy` campo aparece en las páginas **DescribeCertificate** y y **ListCertificates** APIs en las páginas de inventario y detalles de los certificados de la consola ACM. El campo `ManagedBy` se excluye mutuamente con el atributo “Se puede usar con”. En el CloudFront caso de los certificados gestionados, no puede añadir nuevos usos a través de otros servicios. AWS Solo puedes usar estos certificados con más recursos a través de la CloudFront API. **Rotación de CA intermedia y raíz** A fin de mantener una infraestructura de certificados resiliente, Amazon puede suspender una CA intermedia sin previo aviso. Estos cambios no afectarán a los clientes. Para obtener más información, consulte [“Amazon presenta las entidades de certificación intermedias dinámicas”](https://aws.amazon.com/blogs/security/amazon-introduces-dynamic-intermediate-certificate-authorities/). Si Amazon suspende una CA raíz, el cambio se producirá tan pronto como sea necesario. Amazon utilizará todos los métodos disponibles para notificar a AWS los clientes, incluidos el Panel de estado correo electrónico y la comunicación con los administradores técnicos de cuentas. **Acceso al firewall para la revocación** Los certificados de entidad final revocados utilizan el OCSP CRLs para verificar y publicar la información de revocación. Es posible que los firewalls de algunos clientes necesiten reglas adicionales para permitir el funcionamiento de estos mecanismos. Utilice estos patrones de URL con caracteres comodín para identificar el tráfico de revocación: + **OCSP** `http://ocsp.?????.amazontrust.com` `http://ocsp.*.amazontrust.com` + **CRL** `http://crl.?????.amazontrust.com/?????.crl` `http://crl.*.amazontrust.com/*.crl` Un asterisco (\$1) representa uno o varios caracteres alfanuméricos, un signo de interrogación de cierre (?) representa un único carácter alfanumérico, y una almohadilla (\$1) representa un número. **Algoritmos de clave** Los certificados deben especificar un algoritmo y un tamaño de clave. ACM es compatible con los siguientes algoritmos de clave pública de RSA y ECDSA: + RSA de 1024 bits (`RSA_1024`) + RSA de 2048 bits (`RSA_2048`)\$1 + RSA de 3072 bits (`RSA_3072`) + RSA de 4096 bits (`RSA_4096`) + ECDSA de 256 bits (`EC_prime256v1`)\$1 + ECDSA de 384 bits (`EC_secp384r1`)\$1 + ECDSA de 521 bits (`EC_secp521r1`) ACM puede solicitar nuevos certificados a través de algoritmos marcados con un asterisco (\$1). Los algoritmos solo son compatibles con los certificados [importados](import-certificate.md). En el caso de los certificados PKI privados firmados por una AWS Private CA CA, la familia de algoritmos de firma (RSA o ECDSA) debe coincidir con la familia de algoritmos de clave secreta de la CA. Las claves ECDSA son más pequeñas y eficientes desde el punto de vista computacional que las claves RSA de seguridad comparable, pero no todos los clientes de red admiten ECDSA. En esta tabla, adaptada del [NIST](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf), se comparan los tamaños de las claves RSA y ECDSA (en bits) para determinar los niveles de seguridad equivalentes: **Comparación de la seguridad de algoritmos y claves** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/acm/latest/userguide/acm-certificate-characteristics.html) El nivel de seguridad, como una potencia de 2, está relacionado con la cantidad de intentos necesarios para romper el cifrado. Por ejemplo, se pueden recuperar tanto una clave RSA de 3072 bits como una clave ECDSA de 256 bits sin más de 2128 intentos. Si necesita ayuda para elegir un algoritmo, consulte la entrada del AWS blog [Cómo evaluar y utilizar los certificados ECDSA en](https://aws.amazon.com/blogs/security/how-to-evaluate-and-use-ecdsa-certificates-in-aws-certificate-manager/). AWS Certificate Manager Los [servicios integrados](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html) solo permiten los algoritmos y tamaños de clave compatibles para sus recursos. La compatibilidad varía según si el certificado se importa a IAM o ACM. Para conocer detalles, consulte la documentación de cada servicio: + Para Elastic Load Balancing, consulte [Agentes de escucha de HTTPS para su Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html). + Para ver CloudFront, consulte [ SSL/TLS Protocolos y cifrados compatibles](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/secure-connections-supported-viewer-protocols-ciphers.html). **Renovación e implementación gestionadas** ACM administra la renovación y el aprovisionamiento de certificados de ACM. La renovación automática permite evitar el tiempo de inactividad debido a certificados configurados incorrectamente, revocados o expirados. Para obtener más información, consulte [Renovación de certificados gestionada en AWS Certificate Manager](managed-renewal.md). **Múltiples nombres de dominio** Cada certificado de ACM debe incluir al menos un nombre de dominio completo (FQDN), al igual que nombres adicionales. Por ejemplo, un certificado para `www.example.com` también puede incluir `www.example.net`. Esto también se aplica a los dominios raíz (dominios de vértice de zona o sin prefijo). Puede solicitar un certificado para www.example.com e incluir example.com. Para obtener más información, consulte [AWS Certificate Manager certificados públicos](gs-acm-request-public.md). **Punycode** Se deben cumplir los siguientes requisitos de [Punycode](https://datatracker.ietf.org/doc/html/rfc3492) de los [Nombres de dominio internacionalizados](https://www.icann.org/resources/pages/idn-2012-02-25-en): 1. Los nombres de dominio que empiecen con el patrón “--” deben coincidir con “xn--”. 1. Los nombres de dominio que empiecen con “xn--” también deben ser nombres de dominio internacionalizados válidos. **Ejemplos de Punycode** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/acm/latest/userguide/acm-certificate-characteristics.html) **Periodo de validez** Los certificados ACM tienen una validez de 198 días. **Nombres comodín** ACM permite utilizar un asterisco (\$1) en el nombre de dominio para crear un certificado de comodín que pueda proteger varios sitios en el mismo dominio. Por ejemplo, `*.example.com` protege `www.example.com` e `images.example.com`. En un certificado de comodín, el asterisco (`*`) debe estar en la posición más a la izquierda del nombre de dominio y proteger un nivel de subdominio. Por ejemplo, `*.example.com` protege a `login.example.com` y `test.example.com`, pero no a `test.login.example.com`. Además, `*.example.com` *solo* protege los subdominios, pero no al dominio raíz o ápex (`example.com`). Puede solicitar un certificado para un dominio raíz o para sus subdominios especificando varios nombres de dominio, como `example.com` y `*.example.com`. Si los usa CloudFront, tenga en cuenta que la validación HTTP no admite los certificados comodín. En el caso de los certificados comodín, debe utilizar la validación por DNS o correo electrónico. Recomendamos la validación por DNS, ya que admite la renovación automática de los certificados.