# Configuración de acceso seguro y restricción de acceso a contenido
<a name="SecurityAndPrivateContent"></a>

CloudFront proporciona varias opciones para proteger el contenido que ofrece. A continuación, se muestran algunas formas de utilizar CloudFront para proteger y restringir el acceso al contenido:
+ Configure las conexiones HTTPS.
+ Impida que los usuarios de ubicaciones geográficas específicas accedan al contenido
+ Solicitar a los usuarios que accedan al contenido mediante URL o cookies firmadas de CloudFront
+ Configure el cifrado en el nivel de campo para campos de contenido específicos
+ Utilizar AWS WAF para controlar el acceso al contenido

También debe implementar una arquitectura resistente a ataques DDoS para la infraestructura y las aplicaciones. Para obtener información, consulte [Prácticas recomendadas de AWS para la resiliencia a ataques DDoS](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency/aws-best-practices-ddos-resiliency.html).

Para obtener más información, consulte los siguientes temas:
+ [Securing your content delivery with CloudFront](https://aws.amazon.com/cloudfront/security/)
+ [SIEM on Amazon OpenSearch Service](https://github.com/aws-samples/siem-on-amazon-opensearch-service/blob/main/README.md)

**Topics**
+ [Uso de HTTPS con CloudFront](using-https.md)
+ [Uso de nombres de dominio alternativos y HTTPS](using-https-alternate-domain-names.md)
+ [Autenticación TLS mutua con CloudFront (mTLS de espectador)](mtls-authentication.md)
+ [TLS mutua de origen con CloudFront](origin-mtls-authentication.md)
+ [Distribución de contenido privado con URL firmadas y cookies firmadas](PrivateContent.md)
+ [Restricción del acceso a un origen de AWS](private-content-restricting-access-to-origin.md)
+ [Restricción del acceso a Application Load Balancer](restrict-access-to-load-balancer.md)
+ [Restricción de la distribución geográfica de su contenido](georestrictions.md)
+ [Uso del cifrado en el nivel de campo para ayudar a proteger la información confidencial](field-level-encryption.md)

# Uso de HTTPS con CloudFront
<a name="using-https"></a>

Puede configurar CloudFront para exigir a los lectores que utilicen HTTPS al solicitar sus conexiones, de modo que las conexiones se cifren cuando CloudFront se comunique con los lectores. También puede configurar CloudFront para utilizar HTTPS con su origen, de modo que las conexiones se cifran cuando CloudFront se comunica con el origen.

Si configura CloudFront para exigir HTTPS al comunicarse con lectores y con su origen, esto es lo que ocurre cuando CloudFront recibe una solicitud:

1. Un lector envía una solicitud HTTPS a CloudFront. Hay una negociación SSL/TLS entre el lector y CloudFront. Al final, el espectador envía la solicitud en un formato cifrado.

1. Si la ubicación de borde de CloudFront contiene una respuesta almacenada en la caché, CloudFront cifra la respuesta y la devuelve al lector, quien la descifra.

1. Si la ubicación de borde de CloudFront no contiene una respuesta almacenada en la caché, CloudFront realiza la negociación SSL/TLS con su origen y, cuando se haya completado la negociación, reenvía la solicitud al origen en un formato cifrado.

1. Su origen descifra la solicitud, la procesa (genera una respuesta), cifra la respuesta y la devuelve a CloudFront.

1. CloudFront descifra la respuesta, vuelve a cifrarla y la reenvía al lector. CloudFront también guarda en caché la respuesta en la ubicación de borde para que esté disponible la próxima vez que se solicite.

1. El espectador descifra la respuesta.

El proceso es prácticamente el mismo tanto si el origen es un bucket de Amazon S3, MediaStore o un origen personalizado como si es un servidor HTTP/S:

**nota**  
Para ayudar a frustrar los ataques de tipo SSL renegociación, CloudFront no admite renegociación de lector y las solicitudes de origen.

Como opción alternativa, puede activar la autenticación mutua para la distribución de CloudFront. Para obtener más información, consulte [Autenticación TLS mutua con CloudFront (mTLS de espectador)TLS mutua de origen con CloudFront](mtls-authentication.md).

Para obtener información acerca de cómo solicitar HTTPS entre lectores y CloudFront, y entre CloudFront y su origen, consulte los siguientes temas.

**Topics**
+ [Exigencia de HTTPS entre lectores y CloudFront](using-https-viewers-to-cloudfront.md)
+ [Exigencia de HTTPS en un origen personalizado](using-https-cloudfront-to-custom-origin.md)
+ [Exigencia de HTTPS en un origen de Amazon S3](using-https-cloudfront-to-s3-origin.md)
+ [Protocolos y cifrados admitidos entre lectores y CloudFront](secure-connections-supported-viewer-protocols-ciphers.md)
+ [Protocolos y cifrados admitidos entre CloudFront y el origen](secure-connections-supported-ciphers-cloudfront-to-origin.md)

# Exigencia de HTTPS para la comunicación entre lectores y CloudFront
<a name="using-https-viewers-to-cloudfront"></a>

Puede configurar uno o varios comportamientos de la caché en la distribución de CloudFront para que requieran HTTPS en la comunicación entre los lectores y CloudFront. También puede configurar uno o varios comportamientos de la caché para permitir HTTP y HTTPS, de forma que CloudFront requiera HTTPS para algunos objetos, pero no para otros. Los pasos de configuración dependerán del nombre de dominio objeto que use en URL de objetos:
+ Si utiliza el nombre de dominio que CloudFront ha asignado a su distribución, como, por ejemplo, d111111abcdef8.cloudfront.net, cambie la configuración de **Viewer Protocol Policy )Política de protocolo del lector)** de uno o varios comportamientos de la caché para que exijan que la comunicación se realice mediante HTTPS. En dicha configuración, CloudFront ofrece el certificado SSL/TLS. 

  Para cambiar el valor de **Viewer Protocol Policy (Política de protocolo del lector)** desde la consola de CloudFront, consulte el procedimiento más adelante en esta sección.

  Para obtener información acerca de cómo utilizar la API de CloudFront para cambiar el valor del elemento `ViewerProtocolPolicy`, consulte [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) en la *Referencia de la API de Amazon CloudFront*.
+ Si utiliza su propio nombre de dominio, como example.com, necesita cambiar varias configuraciones de CloudFront. También tiene que utilizar un certificado SSL/TLS proporcionado por AWS Certificate Manager (ACM) o importar a ACM o el almacén de certificados de IAM un certificado de una entidad de certificación externa. Para obtener más información, consulte [Uso de nombres de dominio alternativos y HTTPS](using-https-alternate-domain-names.md).

**nota**  
Si desea asegurarse de que los objetos que los lectores obtienen de CloudFront se hayan cifrado cuando CloudFront los obtenga del origen, utilice siempre HTTPS entre CloudFront y el origen. Si ha cambiado recientemente de HTTP a HTTPS entre CloudFront y el origen, le recomendamos que invalide objetos en ubicaciones de borde de CloudFront. CloudFront devolverá un objeto a un lector independientemente de si el protocolo utilizado por dicho lector (HTTP o HTTPS) coincide con el protocolo que CloudFront utilizó para obtener el objeto. Para obtener más información acerca de la eliminación o la sustitución de objetos en una distribución, consulte [Agregación, eliminación o sustitución de contenido que distribuye CloudFront](AddRemoveReplaceObjects.md).

## Exigencia de HTTPS para lectores
<a name="configure-cloudfront-HTTPS-viewers"></a>

Para solicitar HTTPS entre los lectores y CloudFront para uno o varios comportamientos de la caché, siga el siguiente procedimiento.<a name="using-https-viewers-to-cloudfront-procedure"></a>

**Para configurar CloudFront para que requiera HTTPS entre lectores y CloudFront**

1. Inicie sesión en Consola de administración de AWS y abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. En el panel superior de la consola de CloudFront, elija el ID de la distribución que desea actualizar.

1. En la pestaña **Comportamientos**, elija el comportamiento de caché que desee actualizar y, a continuación, elija **Editar**.

1. Especifique uno de los siguientes valores en **Política de protocolo de lector**:  
**Redireccionamiento de HTTP a HTTPS**  
Los espectadores pueden utilizar ambos protocolos. Las solicitudes HTTP `GET` y `HEAD` se redirigen automáticamente a solicitudes HTTPS. CloudFront devuelve el código de estado HTTP 301 (Movido permanentemente) junto con la nueva URL HTTPS. A continuación, el lector vuelve a enviar la solicitud a CloudFront través de la URL HTTPS.  
Si envía `POST`, `PUT`, `DELETE`, `OPTIONS` o `PATCH` a través de HTTP a un comportamiento de la caché de HTTP a HTTPS y una versión de protocolo de solicitud HTTP 1.1 o superior, CloudFront redirige la solicitud a una ubicación HTTPS con un código de estado HTTP 307 (Redirección temporal). Esto garantiza que la solicitud se envía de nuevo a la nueva ubicación con el mismo método y carga de cuerpo.  
Si envía solicitudes `POST`, `PUT`, `DELETE`, `OPTIONS` o `PATCH` a través de HTTP a un comportamiento de la caché HTTPS con una protocolo de solicitud de versión inferior a HTTP 1.1, CloudFront devuelve un código de estado HTTP 403 (Prohibido).
Cuando un lector realiza una solicitud HTTP que se redirige a una solicitud HTTPS, se aplican cargos de CloudFront a ambas solicitudes. En el caso de la solicitud HTTP, el cargo es solo para la solicitud y para los encabezados que CloudFront devuelve al lector. En el caso de la solicitud HTTPS, el cargo es por la solicitud y por los encabezados y el objeto que devuelve el origen.  
**Solo HTTPS**  
Los espectadores pueden obtener acceso a su contenido solo si utilizan HTTPS. Si un lector envía una solicitud HTTP en lugar de una solicitud HTTPS, CloudFront devuelve código de estado HTTP 403 (Prohibido) y no devuelve el objeto.

1. Seleccione **Save changes (Guardar cambios)**.

1. Repita los pasos 3 a 5 para cada comportamiento de la caché adicional para el que desee solicitar HTTPS entre los lectores y CloudFront.

1. Confirme lo siguiente antes de utilizar la configuración actualizada en un entorno de producción:
   + El patrón de ruta de cada comportamiento de la caché es aplicable únicamente a las solicitudes en las que desea que los espectadores utilicen HTTPS.
   + Los comportamientos de la caché se muestran en el orden en que desee que CloudFront los evalúe. Para obtener más información, consulte [Patrón de ruta](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
   + Los comportamientos de la caché son solicitudes de redirección hacia los orígenes correctos. 

# Exigencia de HTTPS para la comunicación entre CloudFront y su origen personalizado
<a name="using-https-cloudfront-to-custom-origin"></a>

Puede exigir HTTPS para la comunicación entre CloudFront y su origen.

**nota**  
Si su origen es un bucket de Amazon S3 configurado como punto de enlace del sitio web, no puede configurar CloudFront para usar HTTPS con su origen porque Amazon S3 no admite HTTPS para los puntos de enlace del sitio web.

Para requerir HTTPS entre CloudFront y su origen, siga los procedimientos de este tema para completar lo siguiente:

1. En su distribución, cambiar la configuración de **Origin Protocol Policy (Política de protocolo de origen)** para el origen.

1. Instalar un certificado SSL/TLS en su servidor de origen (no es necesario cuando se utiliza un origen de Amazon S3 o u otros orígenes de AWS determinados).

**Topics**
+ [Exigencia de HTTPS para orígenes personalizados](#using-https-cloudfront-to-origin-distribution-setting)
+ [Instalación de un certificado SSL/TLS en su origen personalizado](#using-https-cloudfront-to-origin-certificate)

## Exigencia de HTTPS para orígenes personalizados
<a name="using-https-cloudfront-to-origin-distribution-setting"></a>

En el siguiente procedimiento se explica cómo configurar CloudFront para que utilice HTTPS para comunicarse con un balanceador de carga de Elastic Load Balancing, una instancia de Amazon EC2 u otro origen personalizado. Para obtener información sobre el uso de la API de CloudFront para actualizar una distribución, consulte [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) en la *Referencia de la API de Amazon CloudFront*. <a name="using-https-cloudfront-to-custom-origin-procedure"></a>

**Para configurar CloudFront para que requiera HTTPS entre CloudFront y su origen personalizado**

1. Inicie sesión en Consola de administración de AWS y abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. En el panel superior de la consola de CloudFront, elija el ID de la distribución que desea actualizar.

1. En la pestaña **Orígenes**, elija el origen que desee actualizar y, a continuación, elija **Editar**.

1. Actualice los siguientes valores de configuración:  
**Origin Protocol Policy**  
Cambie **Origin Protocol Policy (Política de protocolo de origen)** para los orígenes aplicables en su distribución:  
   + **HTTPS Only (Solo HTTPS)**: CloudFront solo utiliza HTTPS para comunicarse con su origen personalizado.
   + **Match Viewer (Coincidir con lector)**: CloudFront se comunica con su origen personalizado mediante HTTP o HTTPS, en función del protocolo de la solicitud del lector. Por ejemplo, si elige **Match Viewer (Coincidir con lector)** en **Origin Protocol Policy (Política de protocolo de origen)** y el lector usa HTTPS para solicitar un objeto de CloudFront, CloudFront también usa HTTPS para reenviar la solicitud al origen.

     Elija **Match Viewer (Coincidir con espectador)** solo si especifica **Redirect HTTP to HTTPS (Redireccionamiento de HTTP a HTTPS)** o **HTTPS Only (Solo HTTPS)** en **Viewer Protocol Policy (Política de protocolo del espectador)**.

     Tenga en cuenta que CloudFront almacena en caché el objeto solo una vez, incluso si los lectores realizan solicitudes a través de los protocolos HTTP y HTTPS.  
**Origin SSL Protocols**  
Elija **Origin SSL Protocols (Protocolos SSL de orige)** para los orígenes aplicables a su distribución. El protocolo SSLv3 es menos seguro, así que le recomendamos que lo seleccione únicamente si su origen no admite TLSv1 o una versión posterior. El protocolo de enlace TLSv1 es bidireccionalmente compatible con SSLv3, pero no con TLSv1.1 y posteriores. Cuando selecciona SSLv3, CloudFront *solo* envía solicitudes de protocolo de enlace SSLv3.

1. Seleccione **Save changes (Guardar cambios)**.

1. Repita los pasos 3 a 5 para cada origen adicional para el que desee solicitar HTTPS entre CloudFront y su origen personalizado.

1. Confirme lo siguiente antes de utilizar la configuración actualizada en un entorno de producción:
   + El patrón de ruta de cada comportamiento de la caché es aplicable únicamente a las solicitudes en las que desea que los espectadores utilicen HTTPS.
   + Los comportamientos de la caché se muestran en el orden en que desee que CloudFront los evalúe. Para obtener más información, consulte [Patrón de ruta](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
   + Los comportamientos de la caché son solicitudes de redirección a los orígenes cuyo valor de **Origin Protocol Policy (Política de protocolos de origen)** ha cambiado. 

## Instalación de un certificado SSL/TLS en su origen personalizado
<a name="using-https-cloudfront-to-origin-certificate"></a>

Puede utilizar un certificado SSL/TLS de las siguientes fuentes en su origen personalizado:
+ Si su origen es un equilibrador de carga de Elastic Load Balancing, puede utilizar un certificado proporcionado por AWS Certificate Manager (ACM). También puede utilizar un certificado firmado por una entidad de certificación de terceros de confianza e importado a ACM.
+ En el caso de orígenes diferentes a balanceadores de carga de Elastic Load Balancing, debe utilizar un certificado firmado por una entidad de certificación (CA) de terceros de confianza, como Comodo, DigiCert o Symantec.

El certificado devuelto del origen debe incluir uno de los siguientes nombres de dominio:
+ El nombre de dominio en el campo del origen **Origin domain** (Dominio de origen) (el campo `DomainName` en la API de CloudFront).
+ El nombre de dominio en el encabezado `Host`, si el comportamiento de la caché está configurado para reenviar el encabezado `Host` al origen.

Cuando CloudFront utiliza HTTPS para comunicarse con su origen, CloudFront verifica que el certificado haya sido emitido por una autoridad de certificados de confianza. CloudFront admite las mismas autoridades de certificados que Mozilla. Para consultar la lista actualizada, consulte [Mozilla Included CA Certificate List](https://wiki.mozilla.org/CA/Included_Certificates). No se puede utilizar un certificado autofirmado para comunicación HTTPS entre CloudFront y su origen.

**importante**  
En caso de que el servidor de origen devuelva un certificado expirado, no válido o autofirmado, o si el servidor de origen devuelve la cadena de certificados en el orden incorrecto, CloudFront interrumpe la conexión TCP, devuelve código de estado HTTP 502 (Puerta de enlace incorrecta) y establece el encabezado `X-Cache` como `Error from cloudfront`. Igualmente, si toda la cadena de certificados, incluidos los certificados intermedios, no está presente, CloudFront interrumpe la conexión TCP.

# Exigencia de HTTPS para la comunicación entre CloudFront y su origen de Amazon S3
<a name="using-https-cloudfront-to-s3-origin"></a>

Cuando el origen es un bucket de Amazon S3, las opciones para utilizar HTTPS en las comunicaciones con CloudFront dependerán de cómo se esté utilizando el bucket. Si su bucket de Amazon S3 se configura como un punto de enlace de sitio web, no puede configurar CloudFront para usar HTTPS para comunicarse con su origen porque Amazon S3 no admite conexiones HTTPS en dicha configuración.

Cuando el origen es un bucket de Amazon S3 que permite la comunicación HTTPS, CloudFront reenvía las solicitudes a S3 con el protocolo que los lectores utilizaron para enviar las solicitudes. El valor predeterminado para la configuración [Protocolo (solo orígenes personalizados)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy) es **Match Viewer (Coincidir con lector)** y no puede modificarse. Sin embargo, si habilita el control de acceso de origen (OAC) para el origen de Amazon S3, la comunicación utilizada entre CloudFront y Amazon S3 depende de la configuración. Para obtener más información, consulte [Creación de un nuevo control de acceso de origen](private-content-restricting-access-to-s3.md#create-oac-overview-s3).

Si desea solicitar HTTPS para la comunicación entre CloudFront y Amazon S3, deberá cambiar el valor de protocolo de **Viewer Protocol Policy (Política de protocolo del lector)** a **Redirect HTTP to HTTPS (Redirigir HTTP a HTTPS)** o **HTTPS Only (Solo HTTPS)**. En el procedimiento que se indica más adelante en esta sección se explica cómo usar la consola de CloudFront para cambiar **Viewer Protocol Policy (Política de protocolo del lector)**. Para obtener información sobre el uso de la API de CloudFront para actualizar el elemento `ViewerProtocolPolicy` de una distribución, consulte [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) en la *Referencia de la API de Amazon CloudFront*. 

Si utiliza HTTPS con un bucket de Amazon S3 que admite comunicaciones HTTPS, Amazon S3 proporciona el certificado SSL/TLS para que no tenga hacerlo usted.

## Exigencia de HTTPS para un origen de Amazon S3
<a name="configure-cloudfront-HTTPS-S3-origin"></a>

El siguiente procedimiento muestra cómo configurar CloudFront para que se exija HTTPS a su origen de Amazon S3.<a name="using-https-cloudfront-to-s3-origin-procedure"></a>

**Para configurar CloudFront para que requiera HTTPS a su origen de Amazon S3**

1. Inicie sesión en Consola de administración de AWS y abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. En el panel superior de la consola de CloudFront, elija el ID de la distribución que desea actualizar.

1. En la pestaña **Behaviors (Comportamientos)**, elija el comportamiento de la caché que desee actualizar y, a continuación, elija **Edit (Editar)**.

1. Especifique uno de los siguientes valores en **Viewer Protocol Policy (Política de protocolo del espectador)**:  
**Redireccionamiento de HTTP a HTTPS**  
Los espectadores pueden usar tanto el protocolo HTTP como el HTTPS, pero las solicitudes HTTP se redirigirán automáticamente a solicitudes HTTPS. CloudFront devuelve el código de estado HTTP 301 (Movido permanentemente) junto con la nueva URL HTTPS. A continuación, el lector vuelve a enviar la solicitud a CloudFront través de la URL HTTPS.  
CloudFront no redirige las solicitudes `DELETE`, `OPTIONS`, `PATCH`, `POST` ni `PUT` de HTTP a HTTPS. Si configura un comportamiento de la caché para que redirija a HTTPS, CloudFront responde a solicitudes HTTP `DELETE`, `OPTIONS`, `PATCH`, `POST` o `PUT` de ese comportamiento de la caché con el código de estado HTTP 403 (Prohibido).
Cuando un lector realiza una solicitud HTTP que se redirige a una solicitud HTTPS, se aplican cargos de CloudFront a ambas solicitudes. En el caso de la solicitud HTTP, el cargo es solo para la solicitud y para los encabezados que CloudFront devuelve al lector. En el caso de la solicitud HTTPS, el cargo es por la solicitud y por los encabezados y el objeto devueltos por el origen.  
**Solo HTTPS**  
Los espectadores pueden obtener acceso a su contenido solo si utilizan HTTPS. Si un lector envía una solicitud HTTP en lugar de una solicitud HTTPS, CloudFront devuelve código de estado HTTP 403 (Prohibido) y no devuelve el objeto.

1. Elija **Yes, Edit (Sí, editar)**.

1. Repita los pasos 3 a 5 para cada comportamiento de la caché adicional para el que desee solicitar HTTPS entre los lectores y CloudFront, y entre CloudFront y S3.

1. Confirme lo siguiente antes de utilizar la configuración actualizada en un entorno de producción:
   + El patrón de ruta de cada comportamiento de la caché es aplicable únicamente a las solicitudes en las que desea que los espectadores utilicen HTTPS.
   + Los comportamientos de la caché se muestran en el orden en que desee que CloudFront los evalúe. Para obtener más información, consulte [Patrón de ruta](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
   + Los comportamientos de la caché son solicitudes de redirección hacia los orígenes correctos. 

# Protocolos y cifrados admitidos entre lectores y CloudFront
<a name="secure-connections-supported-viewer-protocols-ciphers"></a>

Cuando [necesite HTTPS entre los lectores y la distribución de CloudFront](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy), debe elegir una [política de seguridad](DownloadDistValuesGeneral.md#DownloadDistValues-security-policy), que determina la siguiente configuración.
+ El protocolo SSL/TLS mínimo que utiliza CloudFront para comunicarse con los lectores.
+ Los cifrados que CloudFront puede utilizar para cifrar la comunicación con los lectores.

Para elegir una política de seguridad, especifique el valor aplicable para [Política de seguridad (versión mínima de SSL/TLS)](DownloadDistValuesGeneral.md#DownloadDistValues-security-policy). En la siguiente tabla se muestran los protocolos y los cifrados que CloudFront puede utilizar para cada política de seguridad.

Un lector debe admitir al menos uno de los cifrados compatibles para establecer una conexión HTTPS con CloudFront. CloudFront elige un cifrado en el orden mostrado de entre los cifrados que admite el lector. Véase también [Nombres de cifrado OpenSSL, s2n y RFC](#secure-connections-openssl-rfc-cipher-names).


|  | Política de seguridad |  | SSLv3 | TLSv1 | TLSv1\$12016 | TLSv1.1\$12016 | TLSv1.2\$12018 | TLSv1.2\$12019 | TLSv1.2\$12021 | TLSv1.2\$12025 | TLSv1.3\$12025 | 
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | 
| Protocolos SSL/TLS compatibles | 
| TLSv1.3 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLSv1.2 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| TLSv1.1 | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| TLSv1 | ♦ | ♦ | ♦ |  |  |  |  |  |  | 
| SSLv3 | ♦ |  |  |  |  |  |  |  |  | 
| Cifrados TLSv1.3 compatibles | 
| TLS\$1AES\$1128\$1GCM\$1SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1AES\$1256\$1GCM\$1SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1CHACHA20\$1POLY1305\$1SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | ♦ | 
| Cifrados de ECDSA admitidos | 
| ECDHE-ECDSA-AES128-GCM-SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| ECDHE-ECDSA-AES128-SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  | 
| ECDHE-ECDSA-AES128-SHA | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| ECDHE-ECDSA-AES256-GCM-SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| ECDHE-ECDSA-CHACHA20-POLY1305 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  | 
| ECDHE-ECDSA-AES256-SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  | 
| ECDHE-ECDSA-AES256-SHA | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| Cifrados de RSA compatibles | 
| ECDHE-RSA-AES128-GCM-SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| ECDHE-RSA-AES128-SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  | 
| ECDHE-RSA-AES128-SHA | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| ECDHE-RSA-AES256-GCM-SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| ECDHE-RSA-CHACHA20-POLY1305 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  | 
| ECDHE-RSA-AES256-SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  | 
| ECDHE-RSA-AES256-SHA | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| AES128-GCM-SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  |  | 
| AES256-GCM-SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  |  | 
| AES128-SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  |  | 
| AES256-SHA | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| AES128-SHA | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| DES-CBC3-SHA | ♦ | ♦ |  |  |  |  |  |  |  | 
| RC4-MD5 | ♦ |  |  |  |  |  |  |  |  | 

## Nombres de cifrado OpenSSL, s2n y RFC
<a name="secure-connections-openssl-rfc-cipher-names"></a>

OpenSSL y [s2n](https://github.com/awslabs/s2n) usan nombres diferentes para cifrar que los estándares de TLS ([RFC 2246](https://tools.ietf.org/html/rfc2246), [RFC 4346](https://tools.ietf.org/html/rfc4346), [RFC 5246](https://tools.ietf.org/html/rfc5246), y [RFC 8446](https://tools.ietf.org/html/rfc8446)). En la siguiente tabla se mapean los nombres de OpenSSL y s2n al nombre de RFC para cada uno de los cifrados.

CloudFront admite los intercambios de claves clásicos y con seguridad cuántica. Para los intercambios de claves clásicos mediante curvas elípticas, CloudFront admite lo siguiente:
+ `prime256v1`
+ `X25519`
+ `secp384r1`

Para los intercambios de claves con seguridad cuántica, CloudFront admite lo siguiente:
+ `X25519MLKEM768`
+ `SecP256r1MLKEM768`
**nota**  
Los intercambios de claves con seguridad cuántica solo se admiten con TLS 1.3. TLS 1.2 y las versiones anteriores no admiten el intercambio de claves con seguridad cuántica.

  Para obtener más información, consulte los temas siguientes:
  + [Criptografía poscuántica](https://aws.amazon.com/security/post-quantum-cryptography/)
  + [Algoritmos de criptografía y Servicios de AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/encryption-best-practices/aws-cryptography-services.html#algorithms)
  + [Intercambio de claves híbridas en TLS 1.3](https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/)

Para obtener más información acerca de los requisitos del certificado de CloudFront, consulte [Requisitos para la utilización de certificados SSL/TLS con CloudFront](cnames-and-https-requirements.md).


| Nombre del cifrado OpenSSL y s2n | Nombre del cifrado RFC | 
| --- | --- | 
| Cifrados TLSv1.3 compatibles | 
| TLS\$1AES\$1128\$1GCM\$1SHA256 | TLS\$1AES\$1128\$1GCM\$1SHA256 | 
| TLS\$1AES\$1256\$1GCM\$1SHA384 | TLS\$1AES\$1256\$1GCM\$1SHA384 | 
| TLS\$1CHACHA20\$1POLY1305\$1SHA256 | TLS\$1CHACHA20\$1POLY1305\$1SHA256 | 
| Cifrados de ECDSA admitidos | 
| ECDHE-ECDSA-AES128-GCM-SHA256 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1GCM\$1SHA256 | 
| ECDHE-ECDSA-AES128-SHA256 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$1SHA256 | 
| ECDHE-ECDSA-AES128-SHA | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| ECDHE-ECDSA-AES256-GCM-SHA384 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1GCM\$1SHA384 | 
| ECDHE-ECDSA-CHACHA20-POLY1305 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1CHACHA20\$1POLY1305\$1SHA256 | 
| ECDHE-ECDSA-AES256-SHA384 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1SHA384 | 
| ECDHE-ECDSA-AES256-SHA | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| Cifrados de RSA compatibles | 
| ECDHE-RSA-AES128-GCM-SHA256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1SHA256 | 
| ECDHE-RSA-AES128-SHA256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA256  | 
| ECDHE-RSA-AES128-SHA | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| ECDHE-RSA-AES256-GCM-SHA384 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1SHA384  | 
| ECDHE-RSA-CHACHA20-POLY1305 | TLS\$1ECDHE\$1RSA\$1WITH\$1CHACHA20\$1POLY1305\$1SHA256 | 
| ECDHE-RSA-AES256-SHA384 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA384  | 
| ECDHE-RSA-AES256-SHA | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| AES128-GCM-SHA256 | TLS\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1SHA256 | 
| AES256-GCM-SHA384 | TLS\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1SHA384 | 
| AES128-SHA256 | TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA256 | 
| AES256-SHA | TLS\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| AES128-SHA | TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| DES-CBC3-SHA  | TLS\$1RSA\$1WITH\$13DES\$1EDE\$1CBC\$1SHA  | 
| RC4-MD5 | TLS\$1RSA\$1WITH\$1RC4\$1128\$1MD5 | 

## Esquemas de firma admitidos entre los lectores y CloudFront
<a name="secure-connections-viewer-signature-schemes"></a>

CloudFront admite los siguientes esquemas de firma para conexiones entre lectores y CloudFront.


|  | Política de seguridad | Esquemas de firma | SSLv3 | TLSv1 | TLSv1\$12016 | TLSv1.1\$12016 | TLSv1.2\$12018 | TLSv1.2\$12019 |  TLSv1.2\$12021 | TLSv1.2\$12025 | TLSv1.3\$12025 | 
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1PSS\$1SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1PSS\$1SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1PSS\$1SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1RSAE\$1SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1RSAE\$1SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1RSAE\$1SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA224 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA224 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SECP256R1\$1SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SECP384R1\$1SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA1 | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA1 | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 

# Protocolos y cifrados admitidos entre CloudFront y el origen
<a name="secure-connections-supported-ciphers-cloudfront-to-origin"></a>

Si elige [exigir HTTPS entre CloudFront y su origen](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesOriginProtocolPolicy), puede decidir [el protocolo SSL/TLS que desea permitir](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesOriginSSLProtocols) para la conexión segura y CloudFront puede conectarse al origen utilizando cualquiera de los cifrados ECDSA o RSA listados en la siguiente tabla. El origen debe admitir al menos uno de estos códigos cifrados de CloudFront para establecer una conexión HTTPS a su origen.

OpenSSL y [s2n](https://github.com/awslabs/s2n) usan nombres diferentes para cifrar que los estándares de TLS ([RFC 2246](https://tools.ietf.org/html/rfc2246), [RFC 4346](https://tools.ietf.org/html/rfc4346), [RFC 5246](https://tools.ietf.org/html/rfc5246), y [RFC 8446](https://tools.ietf.org/html/rfc8446)). En la siguiente tabla se incluyen los nombres de OpenSSL y s2n y el nombre de RFC para cada uno de los cifrados.

Para los cifrados con algoritmos de intercambio de claves con curvas elípticas, CloudFront admite las siguientes curvas elípticas:
+ prime256v1
+ secp384r1
+ X25519


| Nombre del cifrado OpenSSL y s2n | Nombre del cifrado RFC | 
| --- | --- | 
| Cifrados de ECDSA admitidos | 
| ECDHE-ECDSA-AES256-GCM-SHA384 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1GCM\$1SHA384 | 
| ECDHE-ECDSA-AES256-SHA384 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1SHA384 | 
| ECDHE-ECDSA-AES256-SHA | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| ECDHE-ECDSA-AES128-GCM-SHA256 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1GCM\$1SHA256 | 
| ECDHE-ECDSA-AES128-SHA256 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$1SHA256 | 
| ECDHE-ECDSA-AES128-SHA | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| Cifrados de RSA compatibles | 
| ECDHE-RSA-AES256-GCM-SHA384 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1SHA384 | 
| ECDHE-RSA-AES256-SHA384 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA384 | 
| ECDHE-RSA-AES256-SHA | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| ECDHE-RSA-AES128-GCM-SHA256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1SHA256 | 
| ECDHE-RSA-AES128-SHA256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA256 | 
| ECDHE-RSA-AES128-SHA | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| AES256-SHA | TLS\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| AES128-SHA | TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| DES-CBC3-SHA | TLS\$1RSA\$1WITH\$13DES\$1EDE\$1CBC\$1SHA | 
| RC4-MD5 | TLS\$1RSA\$1WITH\$1RC4\$1128\$1MD5 | 

**Esquemas de firma admitidos entre CloudFront y el origen**

CloudFront admite los siguientes esquemas de firma para las conexiones entre CloudFront y el origen.
+ TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA256
+ TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA384
+ TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA512
+ TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA224
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA256
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA384
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA512
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA224
+ TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA1
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA1

# Uso de nombres de dominio alternativos y HTTPS
<a name="using-https-alternate-domain-names"></a>

Si desea utilizar su propio nombre de dominio en las URL de los archivos (por ejemplo, `https://www.example.com/image.jpg`) y desea que los lectores utilicen HTTPS, debe completar los pasos descritos en los siguientes temas. (Si utiliza el nombre de dominio de distribución de CloudFront predeterminado en las URL, por ejemplo, `https://d111111abcdef8.cloudfront.net/image.jpg`, siga las instrucciones del siguiente tema: [Exigencia de HTTPS para la comunicación entre lectores y CloudFront](using-https-viewers-to-cloudfront.md)).

**importante**  
Cuando se agrega un certificado a la distribución, CloudFront propaga inmediatamente el certificado a todas las ubicaciones de borde. A medida que haya nuevas ubicaciones de borde disponibles, CloudFront también propaga el certificado a dichas ubicaciones. No puede restringir las ubicaciones de borde a las que CloudFront propaga los certificados.

**Topics**
+ [Elección de la forma en que CloudFront atiende las solicitudes HTTPS](cnames-https-dedicated-ip-or-sni.md)
+ [Requisitos para la utilización de certificados SSL/TLS con CloudFront](cnames-and-https-requirements.md)
+ [Cuotas al usar certificados SSL/TLS con CloudFront (solo HTTPS entre lectores y CloudFront)](cnames-and-https-limits.md)
+ [Configuración de nombres de dominio alternativos y HTTPS](cnames-and-https-procedures.md)
+ [Determinación del tamaño de la clave pública en un certificado SSL/TLS RSA](cnames-and-https-size-of-public-key.md)
+ [Aumento de las cuotas de certificados SSL/TLS](increasing-the-limit-for-ssl-tls-certificates.md)
+ [Rotación de certificados SSL/TLS](cnames-and-https-rotate-certificates.md)
+ [Reversión de un certificado SSL/TLS personalizado al certificado de CloudFront predeterminado](cnames-and-https-revert-to-cf-certificate.md)
+ [Cambio de un certificado SSL/TLS personalizado con direcciones IP dedicadas a SNI](cnames-and-https-switch-dedicated-to-sni.md)

# Elección de la forma en que CloudFront atiende las solicitudes HTTPS
<a name="cnames-https-dedicated-ip-or-sni"></a>

Si desea que los lectores usen HTTPS y nombres de dominio alternativos para los archivos, elija una de las opciones siguientes de cómo CloudFront atiende las solicitudes HTTPS:
+ Use [Server Name Indication (SNI) (Indicación de nombre de servidor [SNI])](https://en.wikipedia.org/wiki/Server_Name_Indication): recomendado
+ Utilizar una dirección IP dedicada en cada ubicación de borde

En esta sección se explica cómo funciona cada opción.

## Uso de SNI para atender solicitudes HTTPS (funciona en la mayoría de los clientes)
<a name="cnames-https-sni"></a>

[Server Name Indication (SNI) (Indicación de nombre de servidor [SNI])](https://en.wikipedia.org/wiki/Server_Name_Indication) es una extensión del protocolo TLS que admiten los navegadores y clientes disponibles desde 2010. Si configura CloudFront para atender solicitudes HTTPS mediante SNI, CloudFront asocia el nombre de dominio alternativo a una dirección IP para cada ubicación de borde. Cuando un espectador envía una solicitud HTTPS de contenido, el servicio DNS dirige la solicitud a la dirección IP de la ubicación de borde correcta. La dirección IP de su nombre de dominio se determina durante la negociación del protocolo SSL/TLS; la dirección IP no es exclusiva de su distribución.

La negociación SSL/TLS se produce muy pronto en el proceso de establecimiento de una conexión HTTPS. Si CloudFront no puede determinar inmediatamente para qué dominio es la solicitud, interrumpe la conexión. Cuando un espectador que admite SNI envía una solicitud HTTPS de contenido, esto es lo que ocurre:

1. El espectador obtiene automáticamente el nombre de dominio de la URL de la solicitud y lo agrega a la extensión SNI del mensaje de saludo del cliente de TLS.

1. Cuando CloudFront recibe el saludo del cliente de TLS, utiliza el nombre de dominio de la extensión SNI para buscar la distribución de CloudFront coincidente y devuelve el certificado de TLS asociado.

1. El lector y CloudFront llevan a cabo la negociación SSL/TLS.

1. CloudFront devuelve el contenido solicitado al lector.

Para obtener una lista actualizada de los navegadores que admiten SNI, consulte la entrada de Wikipedia de [Server Name Indication](https://en.wikipedia.org/wiki/Server_Name_Indication).

Si desea utilizar SNI pero algunos de los navegadores de los usuarios no lo admiten, dispone de varias opciones:
+ Configure CloudFront para atender solicitudes HTTPS a través de direcciones IP dedicadas en lugar de SNI. Para obtener más información, consulte [Uso de direcciones IP dedicadas para atender solicitudes HTTPS (funciona en todos los clientes)](#cnames-https-dedicated-ip).
+ Utilice el certificado SSL/TLS de CloudFront en lugar de un certificado personalizado. Esto requiere que utilice el nombre de dominio de CloudFront para la distribución en las URL de los archivos; por ejemplo, `https://d111111abcdef8.cloudfront.net/logo.png`.

  Si utiliza el certificado de CloudFront predeterminado, los lectores deben admitir el protocolo SSL TLSv1 o versiones posteriores. CloudFront no admite SSLv3 con el certificado de CloudFront predeterminado.

  También debe cambiar el certificado SSL/TLS que CloudFront utiliza, de un certificado personalizado al certificado de CloudFront predeterminado:
  + Si no ha usado su distribución para distribuir su contenido, puede simplemente cambiar la configuración. Para obtener más información, consulte [Actualizar una distribución](HowToUpdateDistribution.md).
  + Si ha usado su distribución para distribuir el contenido, debe crear una nueva distribución de CloudFront y cambiar las URL de los archivos para reducir o eliminar la cantidad de tiempo que el contenido no va a estar disponible. Para obtener más información, consulte [Reversión de un certificado SSL/TLS personalizado al certificado de CloudFront predeterminado](cnames-and-https-revert-to-cf-certificate.md).
+ Si puede controlar qué navegador utilizarán los usuarios, haga que lo actualicen a uno que admita SNI.
+ Utilice HTTP en lugar de HTTPS.

## Uso de direcciones IP dedicadas para atender solicitudes HTTPS (funciona en todos los clientes)
<a name="cnames-https-dedicated-ip"></a>

La indicación de nombre de servidor (SNI) es una manera de asociar una solicitud a un dominio. Otra forma es utilizar una dirección IP dedicada. Si tiene usuarios que no pueden actualizar a un navegador o cliente que se haya lanzado después de 2010, puede utilizar una dirección IP dedicada para atender solicitudes HTTPS. Para obtener una lista actualizada de los navegadores que admiten SNI, consulte la entrada de Wikipedia de [Server Name Indication](https://en.wikipedia.org/wiki/Server_Name_Indication). 

**importante**  
Si configura CloudFront para atender solicitudes HTTPS mediante direcciones IP dedicadas, se le aplicará una cuota mensual adicional. El cargo comienza cuando asocia el certificado SSL/TLS a una distribución y la habilita. Para obtener más información acerca de los precios de CloudFront, consulte [Precios de Amazon CloudFront](https://aws.amazon.com/cloudfront/pricing). Además, consulte [Using the Same Certificate for Multiple CloudFront Distributions](cnames-and-https-limits.md#cnames-and-https-same-certificate-multiple-distributions).

Si configura CloudFront para atender solicitudes HTTPS mediante direcciones IP dedicadas, CloudFront asocia el certificado a una dirección IP dedicada en cada ubicación periférica de CloudFront. Cuando un espectador envía una solicitud HTTPS de contenido, esto es lo que ocurre:

1. El DNS dirige la solicitud hacia la dirección IP de su distribución en la ubicación de borde aplicable.

1. Si una solicitud de cliente proporciona la extensión SNI en el mensaje `ClientHello`, CloudFront busca una distribución que esté asociada a ese SNI.
   + Si hay una coincidencia, CloudFront responde a la solicitud con el certificado SSL/TLS.
   + Si no hay una coincidencia, CloudFront utiliza la dirección IP para identificar la distribución y determinar qué certificado SSL/TLS devolver al lector.

1. El lector y CloudFront llevan a cabo una negociación SSL/TLS con el certificado SSL/TLS.

1. CloudFront devuelve el contenido solicitado al lector.

Este método funciona con cualquier solicitud HTTPS, independientemente del navegador o espectador que esté utilizando el usuario. 

**nota**  
Las IP dedicadas no son direcciones IP estáticas y pueden cambiar con el tiempo. La dirección IP que se devuelve para la ubicación periférica se asigna de forma dinámica a partir de los rangos de direcciones IP de la [lista de servidores periféricos de CloudFront](LocationsOfEdgeServers.md).  
Los rangos de direcciones IP de los servidores periféricos de CloudFront están sujetos a cambios. Para recibir notificaciones de cambios de dirección IP, [Subscribe to AWS Public IP Address Changes via Amazon SNS](https://aws.amazon.com/blogs/aws/subscribe-to-aws-public-ip-address-changes-via-amazon-sns/).

## Solicitud de permiso para utilizar tres o más certificados SSL/TLS de direcciones IP dedicadas
<a name="cnames-and-https-multiple-certificates"></a>

Si necesita permiso para asociar de forma permanente tres o más certificados de IP dedicada SSL/TLS con CloudFront, realice el siguiente procedimiento. Para obtener detalles acerca de solicitudes HTTPS, consulte [Elección de la forma en que CloudFront atiende las solicitudes HTTPS](#cnames-https-dedicated-ip-or-sni).

**nota**  
Este es el procedimiento que se debe seguir para utilizar tres o más certificados de direcciones IP dedicadas en las distribuciones de CloudFront. El valor predeterminado es 2. Tenga en cuenta que no puede vincular más de un certificado SSL a una distribución.  
Solo puede asociar un único certificado SSL/TLS a una distribución de CloudFront cada vez. Este es el total de certificados SSL de IP dedicadas que puede utilizar en todas las distribuciones de CloudFront.<a name="cnames-and-https-multiple-certificates-procedure"></a>

**Para solicitar permiso para utilizar tres o más certificados con una distribución de CloudFront**

1. Vaya al [Centro de soporte](https://console.aws.amazon.com/support/home?#/case/create?issueType=service-limit-increase&limitType=service-code-cloudfront-distributions) y cree un caso.

1. Indique la cantidad de certificados a utilizar para la que necesita permiso y describa las circunstancias en su solicitud. Actualizaremos su cuenta tan pronto como sea posible.

1. Continúe con el siguiente procedimiento.

# Requisitos para la utilización de certificados SSL/TLS con CloudFront
<a name="cnames-and-https-requirements"></a>

En este tema se describen los requisitos de los certificados SSL/TLS. Se aplicarán a estos dos tipos de certificados, salvo que se indique lo contrario:
+ Certificados para utilizar HTTPS entre los lectores y CloudFront 
+ Certificados para utilizar HTTPS entre CloudFront y el origen

**Topics**
+ [Emisor de certificados](#https-requirements-certificate-issuer)
+ [Región de AWS para AWS Certificate Manager](#https-requirements-aws-region)
+ [Formato del certificado](#https-requirements-certificate-format)
+ [Certificados intermedios](#https-requirements-intermediate-certificates)
+ [Tipo de clave](#https-requirements-key-type)
+ [Clave privada](#https-requirements-private-key)
+ [Permisos](#https-requirements-permissions)
+ [Tamaño de la clave de certificado](#https-requirements-size-of-public-key)
+ [Tipos de certificados admitidos](#https-requirements-supported-types)
+ [Fecha de vencimiento y renovación de certificados](#https-requirements-cert-expiration)
+ [Nombres de dominio en la distribución de CloudFront y en el certificado](#https-requirements-domain-names-in-cert)
+ [Versión mínima de protocolo SSL/TLS](#https-requirements-minimum-ssl-protocol-version)
+ [Versiones de HTTP compatibles](#https-requirements-supported-http-versions)

## Emisor de certificados
<a name="https-requirements-certificate-issuer"></a>

Le recomendamos que utilice un certificado público emitido por [AWS Certificate Manager(ACM)](https://aws.amazon.com/certificate-manager/). Para obtener información sobre obtener un certificado de parte de ACM, consulte la *[Guía del usuario de AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/)*. Para utilizar un certificado de ACM con una distribución de CloudFront, asegúrese de solicitar (o importar) el certificado en la región Este de EE. UU. (Norte de Virginia) (`us-east-1`).

 CloudFront admite las mismas entidades de certificación (CA, por sus siglas en inglés) que Mozilla, por lo que si no utiliza ACM, utilice un certificado emitido por una entidad de certificados de la [Lista de certificados de CA incluida en Mozilla](https://wiki.mozilla.org/CA/Included_Certificates). 

Los certificados TLS utilizados por el origen que especificó para su distribución de CloudFront también se deben emitir desde la entidad de certificación que figura en la lista de certificados CA incluidos de Mozilla.

Para obtener más información sobre cómo obtener e instalar un certificado SSL/TLS, consulte la documentación de su software del servidor HTTP y la de la entidad de certificados.

## Región de AWS para AWS Certificate Manager
<a name="https-requirements-aws-region"></a>

Para utilizar un certificado en AWS Certificate Manager (ACM) para solicitar HTTPS entre el lector y CloudFront, asegúrese de solicitar (o importar) el certificado en la región Este de EE. UU. (Norte de Virginia) (`us-east-1`).

Si desea solicitar HTTPS entre CloudFront y su origen y utiliza un equilibrador de carga Elastic Load Balancing como origen, puede solicitar o importar un certificado en cualquier Región de AWS.

## Formato del certificado
<a name="https-requirements-certificate-format"></a>

El certificado debe tener el formato X.509 PEM. Este es el formato predeterminado si utiliza AWS Certificate Manager.

## Certificados intermedios
<a name="https-requirements-intermediate-certificates"></a>

Si utiliza una entidad de certificación (CA) de terceros, incluya una lista de todos los certificados intermedios de la cadena de certificados en el archivo `.pem`, comenzando por uno para la entidad de certificación que firmó el certificado para su dominio. Normalmente, en el sitio web de la CA encontrará un archivo que enumera los certificados intermedios y raíz encadenados de la manera correcta.

**importante**  
No incluya lo siguiente: el certificado raíz y los certificados intermedios que no estén en la ruta de confianza, ni el certificado de clave pública de la CA.

A continuación se muestra un ejemplo:

```
-----BEGIN CERTIFICATE-----
Intermediate certificate 2
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Intermediate certificate 1
-----END CERTIFICATE-----
```

## Tipo de clave
<a name="https-requirements-key-type"></a>

CloudFront admite pares de claves públicas/privadas de RSA y ECDSA.

CloudFront admite conexiones HTTPS tanto a los lectores como a los orígenes mediante certificados RSA y ECDSA. Con [AWS Certificate Manager(ACM)](https://console.aws.amazon.com/acm), puede solicitar e importar certificados RSA o ECDSA y, a continuación, asociarlos a la distribución de CloudFront.

Para las listas de cifrados RSA y ECDSA admitidos por CloudFront que puede nego‎ciar en conexiones HTTPS, consulte [Protocolos y cifrados admitidos entre lectores y CloudFront](secure-connections-supported-viewer-protocols-ciphers.md) y [Protocolos y cifrados admitidos entre CloudFront y el origen](secure-connections-supported-ciphers-cloudfront-to-origin.md).

## Clave privada
<a name="https-requirements-private-key"></a>

Si utiliza un certificado de una entidad de certificación (CA) de terceros, tenga en cuenta lo siguiente: 
+ La clave privada debe coincidir con la clave pública que se encuentra en el certificado.
+ La clave privada debe estar en formato PEM.
+ La clave privada no puede cifrarse con una contraseña.

Si AWS Certificate Manager (ACM) ha proporcionado el certificado, ACM no divulga la clave privada. La clave privada se almacena en ACM para que la usen los servicios de AWS integrados con ACM.

## Permisos
<a name="https-requirements-permissions"></a>

Debe tener permiso para usar e importar el certificado SSL/TLS. Si utiliza AWS Certificate Manager (ACM), le recomendamos que utilice los permisos de AWS Identity and Access Management necesarios para restringir el acceso a los certificados. Para obtener más información, consulte [Identity and Access Management](https://docs.aws.amazon.com/acm/latest/userguide/security-iam.html) en la *Guía del usuario de AWS Certificate Manager*.

## Tamaño de la clave de certificado
<a name="https-requirements-size-of-public-key"></a>

El tamaño de clave de certificado que admite CloudFront depende del tipo de clave y el tipo de certificado.

**Para certificados RSA:**  
CloudFront admite claves RSA de 1024, 2048, 3072 y 4096 bits. La longitud máxima de un certificado RSA que se utiliza con CloudFront es de 4096 bits.  
 Tenga en cuenta que ACM emite certificados RSA con claves de hasta 2048 bits. Para utilizar un certificado RSA de 3072 o 4096 bits, debe obtener el certificado externamente e importarlo a ACM, tras lo cual estará disponible para que lo utilice con CloudFront.   
Para obtener más información acerca de cómo determinar el tamaño de la clave RSA, consulte [Determinación del tamaño de la clave pública en un certificado SSL/TLS RSA](cnames-and-https-size-of-public-key.md).

**Para certificados ECDSA:**  
CloudFront admite claves de 256 bits. Si desea utilizar un certificado ECDSA en ACM para solicitar HTTPS entre lectores y CloudFront, utilice la curva elíptica prime256v1.

## Tipos de certificados admitidos
<a name="https-requirements-supported-types"></a>

CloudFront admite todos los tipos de certificados emitidos por una entidad de certificación de confianza.

## Fecha de vencimiento y renovación de certificados
<a name="https-requirements-cert-expiration"></a>

Si utiliza certificados obtenidos de una entidad de certificación (CA) de terceros, debe monitorear las fechas de vencimiento y renovar los certificados SSL/TLS que importe en AWS Certificate Manager (ACM) o cargue en el almacén de certificados de AWS Identity and Access Management antes de su vencimiento.

**importante**  
Para evitar problemas de vencimiento de los certificados, renueve o vuelva a importar su certificado al menos 24 horas antes del valor `NotAfter` del certificado actual. Si su certificado vence en 24 horas, solicite un nuevo certificado a ACM o importe uno nuevo a ACM. A continuación, asocie el nuevo certificado a la distribución de CloudFront.  
Es posible que CloudFront siga utilizando el certificado anterior mientras se esté renovando o reimportando el certificado. Este es un proceso asíncrono que puede tardar hasta 24 horas en mostrar los cambios en CloudFront.

Si utiliza certificados proporcionados por ACM, ACM administra las renovaciones de esos certificados por usted. Para obtener más información, consulte la [Renovación administrada](https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html) en la *guía del usuario de AWS Certificate Manager*.

## Nombres de dominio en la distribución de CloudFront y en el certificado
<a name="https-requirements-domain-names-in-cert"></a>

Cuando se utiliza un origen personalizado, el certificado SSL/TLS del origen incluye un nombre de dominio en el campo **Common Name (Nombre común)** y, posiblemente, varios más en el campo **Subject Alternative Names (Nombres alternativos de sujetos)**. (CloudFront admite caracteres comodín en nombres de dominio de certificados). 

Uno de los nombres de dominio del certificado debe coincidir con el nombre de dominio que especifique en Origin Domain Name. Si no coincide ningún nombre de dominio, CloudFront devuelve al lector el código de estado HTTP `502 (Bad Gateway)`.

**importante**  
Cuando se agrega un nombre de dominio alternativo a una distribución, CloudFront comprueba que el nombre de dominio alternativo esté cubierto por el certificado que se ha asociado. El certificado debe cubrir el nombre de dominio alternativo en el campo de nombre alternativo del sujeto (SAN) del certificado. Esto significa que el campo SAN debe contener una concordancia exacta para el nombre de dominio alternativo o un comodín en el mismo nivel del nombre de dominio alternativo que se está agregando.  
Para obtener más información, consulte [Requisitos para el uso de nombres de dominio alternativos](CNAMEs.md#alternate-domain-names-requirements).

## Versión mínima de protocolo SSL/TLS
<a name="https-requirements-minimum-ssl-protocol-version"></a>

Si utiliza direcciones IP dedicadas, establezca la versión mínima de protocolo SSL/TLS para la conexión entre lectores y CloudFront eligiendo una política de seguridad.

Para obtener más información, consulte [Política de seguridad (versión mínima de SSL/TLS)](DownloadDistValuesGeneral.md#DownloadDistValues-security-policy) en el tema [Referencia de toda la configuración de distribución](distribution-web-values-specify.md).

## Versiones de HTTP compatibles
<a name="https-requirements-supported-http-versions"></a>

Si asocia un certificado con más de una distribución de CloudFront, todas las distribuciones asociadas con el certificado deben utilizar la misma opción para [Versiones de HTTP compatibles](DownloadDistValuesGeneral.md#DownloadDistValuesSupportedHTTPVersions). Esta opción se especifica al crear o actualizar una distribución de CloudFront.

# Cuotas al usar certificados SSL/TLS con CloudFront (solo HTTPS entre lectores y CloudFront)
<a name="cnames-and-https-limits"></a>

Tenga en cuenta las siguientes cuotas en cuanto al uso de certificados SSL/TLS con CloudFront. Estas cuotas se aplican únicamente a los certificados SSL/TLS que aprovisione mediante AWS Certificate Manager (ACM), que importe a ACM o que cargue en el almacén de certificados de IAM para la comunicación con HTTPS entre los lectores y CloudFront.

Para obtener más información, consulte [Aumento de las cuotas de certificados SSL/TLS](increasing-the-limit-for-ssl-tls-certificates.md).

**Cantidad máxima de certificados por distribución de CloudFront**  
Puede asociar un máximo de un certificado SSL/TLS con cada distribución de CloudFront.

**Cantidad máxima de certificados que se pueden importar a ACM o cargar en el almacén de certificados de IAM**  
Si ha obtenido sus certificados SSL/TLS de un distribuidor CA de terceros, debe almacenarlos en una de las siguientes ubicaciones:  
+ **AWS Certificate Manager**: para conocer la cuota actual de certificados de ACM, consulte ‭[Cuotas](https://docs.aws.amazon.com/acm/latest/userguide/acm-limits.html) en la *‬Guía del usuario de AWS Certificate Manager*‬. La cuota mostrada es un total que incluye los certificados que aprovisione mediante ACM y los que importe a ACM.
+ **Almacén de certificados de IAM**: para conocer la cuota (antes denominada límite) actual de certificados que puede cargar en el almacén de certificados de IAM de una cuenta de AWS, consulte [Límites de IAM y STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-limits.html) en la *Guía del usuario de IAM*. Puede solicitar una cuota mayor en la consola de Service Quotas.

**Cantidad máxima de certificados por cuenta de AWS (solo direcciones IP dedicadas)**  
Si desea atender solicitudes HTTPS a través de direcciones IP dedicadas, tenga en cuenta lo siguiente:  
+ De forma predeterminada, CloudFront le concede permiso para utilizar dos certificados con la cuenta de AWS, uno para uso diario y otro para cuando necesite rotar certificados para numerosas distribuciones.
+ Si necesita más de dos certificados SSL/TLS personalizados para su cuenta de AWS, puede solicitar una cuota mayor en la consola de Service Quotas.

**Uso del mismo certificado para distribuciones de CloudFront que se crearon con distintas cuentas de AWS**  
Si utiliza una entidad de certificación externa y desea utilizar el mismo certificado con varias distribuciones de CloudFront creadas con diferentes cuentas de AWS, debe importar el certificado a ACM o cargarlo en el almacén de certificados de IAM una vez por cada cuenta de AWS.  
Si utiliza certificados proporcionados por ACM, no puede configurar CloudFront para utilizar certificados creados por una cuenta diferente de AWS.

**Uso del mismo certificado para CloudFront y para otros servicios de AWS**  
Si ha comprado un certificado de una autoridad de certificación de confianza como Comodo DigiCert o Symantec, puede utilizar el mismo certificado para CloudFront y para otros servicios de AWS. Si importa el certificado a ACM, solo es necesario importarlo una vez para utilizarlo con varios servicios de AWS.  
Si utiliza certificados proporcionados por ACM, estos se almacenan en ACM.

**Uso del mismo certificado para varias distribuciones de CloudFront**  
Puede utilizar el mismo certificado para una o todas las distribuciones de CloudFront que utilice para atender solicitudes HTTPS. Tenga en cuenta lo siguiente:  
+ Puede utilizar el mismo certificado tanto para atender solicitudes mediante direcciones IP dedicadas como para proporcionar solicitudes con SNI. 
+ Puede asociar solo un certificado a cada distribución.
+ Cada distribución debe incluir uno o varios nombres de dominio alternativos que también aparecerán en los campos **Common Name** o **Subject Alternative Names** del certificado.
+ Si está atendiendo solicitudes HTTPS mediante direcciones IP dedicadas y ha creado todas sus distribuciones con la misma cuenta de AWS, puede reducir significativamente sus costos si utiliza el mismo certificado para todas las distribuciones. CloudFront aplica cargos por cada certificado, no por cada distribución. 

  Por ejemplo, suponga que crea tres distribuciones con la misma cuenta de AWS y que utiliza el mismo certificado para las tres distribuciones. Se le aplicará solo un cargo por el uso de direcciones IP dedicadas.

  Sin embargo, si atiende solicitudes HTTPS con direcciones IP dedicadas y con el mismo certificado para crear distribuciones de CloudFront en diferentes cuentas de AWS, a cada cuenta se le aplica el cargo por usar direcciones IP dedicadas. Por ejemplo, si crea tres distribuciones usando tres cuentas diferentes de AWS y utiliza el mismo certificado para las tres distribuciones, a cada cuenta se cobra el cargo completo de uso de direcciones IP dedicadas.

# Configuración de nombres de dominio alternativos y HTTPS
<a name="cnames-and-https-procedures"></a>

Para utilizar nombres de dominio alternativos en las URL de los archivos y utilizar HTTPS entre los lectores y CloudFront, realice los procedimientos aplicables.

**Topics**
+ [Obtención de un certificado SSL/TLS](#cnames-and-https-getting-certificates)
+ [Importación de un certificado SSL/TLS](#cnames-and-https-uploading-certificates)
+ [Actualización de la distribución de CloudFront](#cnames-and-https-updating-cloudfront)

## Obtención de un certificado SSL/TLS
<a name="cnames-and-https-getting-certificates"></a>

Obtenga un certificado SSL/TLS si aún no dispone de uno. Para obtener más información, consulte la documentación aplicable:
+ Para utilizar un certificado proporcionado por AWS Certificate Manager (ACM), consulte la [Guía del usuario de AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/). A continuación, diríjase a [Actualización de la distribución de CloudFront](#cnames-and-https-updating-cloudfront).
**nota**  
Le recomendamos que utilice ACM para aprovisionar, administrar e implementar los certificados SSL/TLS en los recursos administrados de AWS. Debe solicitar un certificado de ACM en la región EE. UU. Este (Norte de Virginia).
+ Para obtener un certificado de una entidad de certificación (CA) de terceros, consulte la documentación que proporciona. Cuando tenga el certificado, continúe con el siguiente procedimiento.

## Importación de un certificado SSL/TLS
<a name="cnames-and-https-uploading-certificates"></a>

Si ha obtenido el certificado de una entidad de certificación de terceros, importe el certificado a ACM o cárguelo en el almacén de certificados de IAM:

**ACM (recomendado)**  
ACM le permite importar certificados de terceros desde la consola de ACM y de forma programada. Para obtener más información sobre la [importación de un certificado a ACM, consulte Importación de certificados a AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html) en la *Guía del usuario de AWS Certificate Manager*. Debe importar el certificado en la región EE. UU. Este (Norte de Virginia).

**Almacén de certificados de IAM**  
(No recomendado) Utilice el siguiente comando de AWS CLI para cargar el certificado de terceros en el almacén de certificados de IAM.  

```
aws iam upload-server-certificate \
        --server-certificate-name CertificateName \
        --certificate-body file://public_key_certificate_file \
        --private-key file://privatekey.pem \
        --certificate-chain file://certificate_chain_file \
        --path /cloudfront/path/
```
Tenga en cuenta lo siguiente:  
+ **Cuenta de AWS**: debe cargar el certificado en el almacén de certificados de IAM con la misma cuenta de AWS que utilizó para crear la distribución de CloudFront.
+ **Parámetro --path**: al cargar el certificado en IAM, el valor del parámetro `--path` (ruta del certificado) debe comenzar por `/cloudfront/`, por ejemplo, `/cloudfront/production/` o `/cloudfront/test/`. La ruta debe acabar con una /.
+ **Certificados existentes**: debe especificar valores para los parámetros `--server-certificate-name` y `--path` que sean diferentes de los valores asociados con los certificados existentes.
+ **Uso de la consola de CloudFront**: el valor que especifique para el parámetro `--server-certificate-name` en AWS CLI, por ejemplo, `myServerCertificate`, aparece en la lista **SSL Certificate (Certificado SSL)** de la consola de CloudFront.
+ **Con la API de CloudFront**: anote la cadena alfanumérica que devuelve AWS CLI, por ejemplo, `AS1A2M3P4L5E67SIIXR3J`. Este es el valor que se especifica en el elemento `IAMCertificateId`. No es necesario el ARN de IAM, que también devuelve la CLI.
Para obtener más información sobre AWS CLI, consulte la [Guía del usuario de AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) y la [Referencia de comandos de AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/).

## Actualización de la distribución de CloudFront
<a name="cnames-and-https-updating-cloudfront"></a>

Para actualizar la configuración de su distribución, realice el siguiente procedimiento:<a name="cnames-and-https-updating-cloudfront-procedure"></a>

**Para configurar la distribución de CloudFront para nombres de dominio alternativos**

1. Inicie sesión en la Consola de administración de AWS y abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Elija la ID de la distribución que desea actualizar.

1. En la pestaña **General**, seleccione **Edit**.

1. Actualice los siguientes valores:  
**Nombre de dominio alternativo (CNAME)**  
Elija **Agregar elemento** para agregar los nombres de dominio alternativos aplicables. Separe los nombres de dominio con comas o escriba uno por línea.  
**Certificado SSL personalizado**  
Seleccione un certificado en el menú desplegable.  
Aquí se enumeran hasta 100 certificados. Si tiene más de 100 certificados y no ve el certificado que desea añadir, puede escribir un ARN de certificado en el campo para elegirlo.  
Si ha cargado un certificado al almacén de certificados de IAM pero no está en la lista y no puede elegirlo escribiendo el nombre en el campo, revise el procedimiento [Importación de un certificado SSL/TLS](#cnames-and-https-uploading-certificates) para confirmar que el certificado se ha cargado correctamente.   
Después de asociar el certificado SSL/TLS a la distribución de CloudFront, no elimine el certificado de ACM ni el almacén de certificados de IAM hasta que haya eliminado el certificado de todas las distribuciones y se hayan implementado.

1. Seleccione **Save changes (Guardar cambios)**.

1. Configure CloudFront para que solicite HTTPS entre lectores y CloudFront:

   1. En la pestaña **Behaviors (Comportamientos)**, elija el comportamiento de la caché que desee actualizar y después elija **Edit (Editar)**.

   1. Especifique uno de los siguientes valores en **Viewer Protocol Policy (Política de protocolo del espectador)**:  
**Redireccionamiento de HTTP a HTTPS**  
Los espectadores pueden usar tanto el protocolo HTTP como el HTTPS, pero las solicitudes HTTP se redirigirán automáticamente a solicitudes HTTPS. CloudFront devuelve el código de estado HTTP `301 (Moved Permanently)` junto con la nueva URL HTTPS. A continuación, el lector vuelve a enviar la solicitud a CloudFront través de la URL HTTPS.  
CloudFront no redirige las solicitudes `DELETE`, `OPTIONS`, `PATCH`, `POST` ni `PUT` de HTTP a HTTPS. Si configura un comportamiento de la caché para que redirija a HTTPS, CloudFront responde a solicitudes HTTP `DELETE`, `OPTIONS`, `PATCH`, `POST` o `PUT` para ese comportamiento de la caché con el código de estado HTTP `403 (Forbidden)`.
Cuando un lector realiza una solicitud HTTP que se redirige a una solicitud HTTPS, se aplican cargos de CloudFront a ambas solicitudes. En el caso de la solicitud HTTP, el cargo es solo para la solicitud y para los encabezados que CloudFront devuelve al lector. En el caso de la solicitud HTTPS, el cargo es por la solicitud y por los encabezados y el archivo que el origen devuelve.  
**Solo HTTPS**  
Los espectadores pueden obtener acceso a su contenido solo si utilizan HTTPS. Si un lector envía una solicitud HTTP en lugar de una solicitud HTTPS, CloudFront devuelve el código de estado HTTP `403 (Forbidden)` y no devuelve el archivo.

   1. Elija **Yes, Edit (Sí, editar)**.

   1. Repita los pasos de la "a" a la "c" para cada comportamiento de la caché adicional para el que desee exigir HTTPS entre los lectores y CloudFront.

1. Confirme lo siguiente antes de utilizar la configuración actualizada en un entorno de producción:
   + El patrón de ruta de cada comportamiento de la caché es aplicable únicamente a las solicitudes en las que desea que los espectadores utilicen HTTPS.
   + Los comportamientos de la caché se muestran en el orden en que desee que CloudFront los evalúe. Para obtener más información, consulte [Patrón de ruta](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
   + Los comportamientos de la caché son solicitudes de redirección hacia los orígenes correctos. 

# Determinación del tamaño de la clave pública en un certificado SSL/TLS RSA
<a name="cnames-and-https-size-of-public-key"></a>

Cuando se usan nombres de dominio alternativos de CloudFront y HTTPS, el tamaño máximo de la clave pública en un certificado SSL/TLS RSA es de 4096 bits. (Este es el tamaño de la clave, no es la cantidad de caracteres de la clave pública). Si utiliza AWS Certificate Manager para sus certificados, tenga en cuenta que aunque ACM admite claves más grandes, no se pueden usar con CloudFront.

Puede determinar el tamaño de la clave pública de RSA al ejecutar el siguiente comando OpenSSL:

```
openssl x509 -in path and filename of SSL/TLS certificate -text -noout 
```

Donde:
+ `-in` especifica la ruta y el nombre de archivo de su certificado SSL/TLS. RSA
+ `-text` provoca que OpenSSL muestre la longitud de la clave pública de RSA en bits.
+ `-noout` impide que OpenSSL muestre la clave pública.

Ejemplo de resultados:

```
Public-Key: (2048 bit)
```

# Aumento de las cuotas de certificados SSL/TLS
<a name="increasing-the-limit-for-ssl-tls-certificates"></a>

Hay cuotas en cuanto a la cantidad de certificados SSL/TLS que puede importar a AWS Certificate Manager (ACM) o cargar en AWS Identity and Access Management (IAM). También hay una cuota en el número de certificados SSL/TLS que puede utilizar con una Cuenta de AWS al configurar CloudFront para atender solicitudes HTTPS con direcciones IP dedicadas. Sin embargo, puede solicitar una ampliación de dichas cuotas.

**Topics**
+ [Aumento de la cuota en certificados importados a ACM](#certificates-to-import-into-acm)
+ [Aumento de la cuota en certificados subidos a IAM](#certificates-to-upload-into-iam)
+ [Aumento de la cuota en certificados utilizados con direcciones IP dedicadas](#certificates-using-dedicated-ip-address)

## Aumento de la cuota en certificados importados a ACM
<a name="certificates-to-import-into-acm"></a>

Para consultar la cuota de certificados que puede importar a ACM, consulte [Cuotas](https://docs.aws.amazon.com/acm/latest/userguide/acm-limits.html) en la *Guía del usuario de AWS Certificate Manager*.

Para solicitar una cuota más alta, use la consola de Service Quotas. Para obtener más información, consulte [Solicitud de aumento de cuota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) en la *Guía del usuario de Service Quotas*.

## Aumento de la cuota en certificados subidos a IAM
<a name="certificates-to-upload-into-iam"></a>

Para obtener información sobre la cuota (antes denominada límite) del número de certificados que puede cargar en IAM, consulte [Límites de IAM y STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-limits.html) en la *Guía del usuario de IAM*.

Para solicitar una cuota más alta, use la consola de Service Quotas. Para obtener más información, consulte [Solicitud de aumento de cuota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) en la *Guía del usuario de Service Quotas*.

## Aumento de la cuota en certificados utilizados con direcciones IP dedicadas
<a name="certificates-using-dedicated-ip-address"></a>

Para conocer la cuota en el número de certificados SSL que puede utilizar por cada Cuenta de AWS si atiende solicitudes HTTPS utilizando direcciones IP dedicadas, consulte [Cuotas en certificados SSL](cloudfront-limits.md#limits-ssl-certificates).

Para solicitar una cuota más alta, use la consola de Service Quotas. Para obtener más información, consulte [Solicitud de aumento de cuota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) en la *Guía del usuario de Service Quotas*.

# Rotación de certificados SSL/TLS
<a name="cnames-and-https-rotate-certificates"></a>

Cuando los certificados SSL/TLS estén a punto de caducar, tendrá que rotarlos para garantizar la seguridad de la distribución y evitar la interrupción del servicio para los lectores. Puede rotarlos de las siguientes formas:
+ Para los certificados SSL/TLS proporcionados por AWS Certificate Manager (ACM), no es necesario rotarlos. ACM administra *automáticamente* las renovaciones de los certificados por usted. Para obtener más información, consulte [Renovación administrada de certificados](https://docs.aws.amazon.com/acm/latest/userguide/acm-renewal.html) en la *Guía del usuario de AWS Certificate Manager*.
+ Si utiliza una autoridad de certificación de terceros y ha importado certificados a ACM (recomendado) o los ha cargado en el almacén de certificados de IAM, debe sustituir ocasionalmente un certificado por otro.

  

**importante**  
ACM no administra renovaciones de certificados que adquiera de autoridades de certificación de terceros y que después importe a ACM.
Si configura CloudFront para atender solicitudes HTTPS a través de direcciones IP dedicadas, es posible que se aplique un cargo prorrateado adicional por uso de uno o varios certificados adicionales mientras rota certificados. Le recomendamos actualizar las distribuciones para minimizar los cargos adicionales.

## Rotación de certificados SSL/TLS
<a name="rotate-ssl-tls-certificate"></a>

Para rotar los certificados, realice el siguiente procedimiento. Los espectadores pueden seguir obteniendo acceso a su contenido mientras rota certificados y también una vez completado el proceso.<a name="rotate-ssl-tls-certificates-proc"></a>

**Para rotar certificados SSL/TLS**

1. [Aumento de las cuotas de certificados SSL/TLS](increasing-the-limit-for-ssl-tls-certificates.md) para determinar si necesita permiso para utilizar más certificados SSL. En caso afirmativo, solicite el permiso y espere hasta que se le conceda antes de continuar con el paso 2.

1. Importe el nuevo certificado a ACM o cárguelo a IAM. Para obtener más información, consulte [Importación de un certificado SSL/TLS](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cnames-and-https-procedures.html#cnames-and-https-uploading-certificates) en la *Guía para desarrolladores de Amazon CloudFront*.

1. (Solo para certificados de IAM) Actualice las distribuciones de una en una para utilizar el nuevo certificado. Para obtener más información, consulte [Actualizar una distribución](HowToUpdateDistribution.md).

1. (Opcional) Elimine el certificado anterior de ACM o IAM.
**importante**  
No elimine un certificado SSL/TLS hasta eliminarlo de todas las distribuciones y hasta que el estado de las distribuciones que ha actualizado haya cambiado a `Deployed`.

# Reversión de un certificado SSL/TLS personalizado al certificado de CloudFront predeterminado
<a name="cnames-and-https-revert-to-cf-certificate"></a>

Si ha configurado CloudFront para utilizar HTTPS entre lectores y CloudFront y ha configurado CloudFront para utilizar un certificado SSL/TLS personalizado, puede cambiar la configuración para utilizar el certificado SSL/TLS de CloudFront predeterminado. El proceso depende de si ha utilizado la distribución para distribuir su contenido:
+ Si no ha usado su distribución para distribuir su contenido, puede simplemente cambiar la configuración. Para obtener más información, consulte [Actualizar una distribución](HowToUpdateDistribution.md).
+ Si ha usado su distribución para distribuir el contenido, debe crear una nueva distribución de CloudFront y cambiar las URL de los archivos para reducir o eliminar la cantidad de tiempo que el contenido no va a estar disponible. Para ello, realice el siguiente procedimiento.

## Reversión a certificado de CloudFront predeterminado
<a name="revert-default-cloudfront-certificate"></a>

El siguiente procedimiento muestra cómo revertir de un certificado SSL/TLS personalizado al certificado de CloudFront predeterminado.<a name="cnames-and-https-revert-to-cf-certificate-proc"></a>

**Para volver al certificado de CloudFront predeterminado**

1. Cree una nueva distribución de CloudFront con la configuración deseada. En **SSL Certificate (Certificado SSL)**, elija **Default CloudFront Certificate (\$1.cloudfront.net) (Certificado de CloudFront predeterminado [\$1.cloudfront.net])**. 

   Para obtener más información, consulte [Creación de una distribución](distribution-web-creating-console.md).

1. En el caso de los archivos distribuidos con CloudFront, actualice las URL en la aplicación para que utilicen el nombre de dominio que CloudFront ha asignado a la nueva distribución. Por ejemplo, cambie `https://www.example.com/images/logo.png` a `https://d111111abcdef8.cloudfront.net/images/logo.png`.

1. Elimine la distribución asociada con un certificado SSL/TLS personalizado o actualice la distribución para cambiar el valor de **SSL Certificate (Certificado SSL)** a **Default CloudFront Certificate (\$1.cloudfront.net) (Certificado de CloudFront predeterminado [\$1.cloudfront.net])**. Para obtener más información, consulte [Actualizar una distribución](HowToUpdateDistribution.md).
**importante**  
Hasta que complete este paso, AWS seguirá acumulando cargos por utilizar un certificado SSL/TLS personalizado.

1. Elimine su certificado SSL/TLS personalizado (opcional).

   1. Ejecute el comando AWS CLI de la `list-server-certificates` para obtener el ID del certificado que desea eliminar. Para obtener más información, consulte [list-server-certificates](https://docs.aws.amazon.com/cli/latest/reference/iam/list-server-certificates.html) en la *Referencia de comandos de AWS CLI*.

   1. Ejecute el comando `delete-server-certificate` de AWS CLI para eliminar el certificado. Para obtener más información, consulte [delete-server-certificate](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-server-certificate.html) en la *Referencia de comandos de AWS CLI*.

# Cambio de un certificado SSL/TLS personalizado con direcciones IP dedicadas a SNI
<a name="cnames-and-https-switch-dedicated-to-sni"></a>

Si configura CloudFront para utilizar un certificado SSL/TLS personalizado con direcciones IP dedicadas, puede utilizar un certificado SSL/TLS personalizado con SNI en su lugar y eliminar el cargo asociado a direcciones IP dedicadas.

**importante**  
Esta actualización de la configuración de CloudFront no afecta a los lectores que admiten SNI. Los lectores pueden acceder al contenido antes y después del cambio, así como mientras el cambio se propaga a las ubicaciones de borde de CloudFront. Los espectadores que no admiten SNI no podrán obtener acceso a su contenido tras el cambio. Para obtener más información, consulte [Elección de la forma en que CloudFront atiende las solicitudes HTTPS](cnames-https-dedicated-ip-or-sni.md). 

## Cambio de un certificado personalizado a SNI
<a name="cloudfront-switch-custom-cert-sni"></a>

El siguiente procedimiento muestra cómo cambiar de un certificado SSL/TLS personalizado con direcciones IP dedicadas a SNI.<a name="cnames-and-https-switch-dedicated-to-sni-proc"></a>

**Para cambiar de un certificado SSL/TLS personalizado con direcciones IP dedicadas a SNI**

1. Inicie sesión en Consola de administración de AWS y abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Elija el ID de la distribución que desea visualizar o actualizar.

1. Elija **Distribution Settings (Configuración de distribución)**.

1. En la pestaña **General**, seleccione **Edit**.

1. En **Certificación SSL personalizada (*opcional*)**, anule la selección de **Soporte de clientes heredados**.

1. Elija **Sí, editar**.

# Autenticación TLS mutua con CloudFront (mTLS de espectador)
<a name="mtls-authentication"></a>

La autenticación TLS mutua (Autenticación de seguridad de la capa de transporte mutua: mTLS) es un protocolo de seguridad que amplía la autenticación TLS estándar al requerir una autenticación bidireccional basada en certificados, en la que tanto el cliente como el servidor deben demostrar su identidad antes de establecer una conexión segura. Con TLS mutua, puede asegurarse de que solo los clientes que presenten certificados TLS de confianza accedan a las distribuciones de CloudFront.

## Funcionamiento
<a name="how-mtls-works"></a>

En un establecimiento de comunicación de TLS estándar, solo el servidor presenta un certificado que demuestre su identidad al cliente. Con TLS mutua, el proceso de autenticación pasa a ser bidireccional. Cuando un cliente intenta conectarse a la distribución de CloudFront, CloudFront solicita un certificado de cliente durante el establecimiento de comunicación de TLS. El cliente debe presentar un certificado X.509 válido que CloudFront valida en el almacén de confianza configurado antes de establecer la conexión segura.

CloudFront realiza esta validación de certificados en ubicaciones periféricas de AWS, lo que reduce la complejidad de la autenticación de los servidores de origen y, al mismo tiempo, mantiene los beneficios de rendimiento global de CloudFront. Puede configurar mTLS de dos modos: el modo de verificación (que requiere que todos los clientes presenten certificados válidos) o el modo opcional (que valida los certificados cuando se presentan, pero también permite las conexiones sin certificados).

## Casos de uso
<a name="mtls-use-cases"></a>

La autenticación TLS mutua con CloudFront aborda varios escenarios de seguridad críticos en los que los métodos de autenticación tradicionales son insuficientes:
+ **Autenticación de dispositivos con almacenamiento en caché de contenido**: puede autenticar consolas de juegos, dispositivos de IoT o hardware corporativo antes de permitir el acceso a las actualizaciones de firmware, las descargas de juegos o los recursos internos. Cada dispositivo contiene un certificado único que demuestra su autenticidad y, al mismo tiempo, se beneficia de las capacidades de almacenamiento en caché de CloudFront.
+ **Autenticación de API a API**: puede proteger la comunicación de máquina a máquina entre socios comerciales, sistemas de pago o microservicios de confianza. La autenticación basada en certificados elimina la necesidad de compartir secretos o claves de API, al tiempo que proporciona una sólida verificación de identidad para el intercambio de datos automatizado.

**Topics**
+ [Funcionamiento](#how-mtls-works)
+ [Casos de uso](#mtls-use-cases)
+ [Almacenes de confianza y administración de certificados](trust-stores-certificate-management.md)
+ [Habilitación de TLS mutua para las distribuciones de CloudFront](enable-mtls-distributions.md)
+ [Asociación de una función de conexión de CloudFront](connection-functions.md)
+ [Configuración adicional](configuring-additional-settings.md)
+ [Encabezados de mTLS del espectador para las políticas de caché y reenvío al origen](viewer-mtls-headers.md)
+ [Revocación mediante la función de conexión de CloudFront y KVS](revocation-connection-function-kvs.md)
+ [Observabilidad mediante registros de conexión](connection-logs.md)

# Almacenes de confianza y administración de certificados
<a name="trust-stores-certificate-management"></a>

La creación y configuración de un almacén de confianza es un requisito obligatorio para implementar la autenticación TLS mutua con CloudFront. Los almacenes de confianza contienen los certificados de la autoridad de certificación (CA) que CloudFront utiliza para validar los certificados de los clientes durante el proceso de autenticación.

## ¿Qué es un almacén de confianza?
<a name="what-is-trust-store"></a>

Un almacén de confianza es un repositorio de certificados CA que CloudFront utiliza para validar los certificados de los clientes durante la autenticación TLS mutua. Los almacenes de confianza contienen los certificados CA raíz e intermedios que forman la cadena de confianza para autenticar los certificados de los clientes.

Al implementar un TLS mutuo con CloudFront, el almacén de confianza define las autoridades de certificación en las que confía para emitir certificados de cliente válidos. CloudFront valida cada certificado de cliente con su almacén de confianza durante el establecimiento de comunicación de TLS. Solo los clientes que presenten certificados encadenados a una de las autoridades de certificación del almacén de confianza se autenticarán correctamente.

Los almacenes de confianza de CloudFront son recursos por cuenta que se pueden asociar a varias distribuciones. Esto permite mantener políticas de validación de certificados coherentes en toda la implementación de CloudFront y, al mismo tiempo, simplificar la administración de certificados CA.

## Compatibilidad de la autoridad de certificación
<a name="ca-support"></a>

CloudFront admite certificados emitidos tanto por una autoridad de certificación privada de AWS como por autoridades de certificación privadas de terceros. Esta flexibilidad permite utilizar la infraestructura de certificados existente o aprovechar los servicios de certificación administrados de AWS en función de los requisitos de la organización.
+ **Autoridad de certificación privada de AWS:** puede utilizar los certificados emitidos por la autoridad de certificación privada de AWS, que proporciona un servicio de autoridad de certificación privada administrada. Esta integración simplifica la administración del ciclo de vida de los certificados y proporciona una integración perfecta con otros servicios de AWS.
+ **Autoridades de certificación privadas de terceros:** también puede utilizar los certificados de la infraestructura de autoridad de certificación privada existente, incluidas las autoridades de certificación empresariales u otros proveedores de certificados de terceros. Esto permite mantener los procesos actuales de administración de certificados y, al mismo tiempo, agregar las capacidades de mTLS de CloudFront.

## Requisitos y especificaciones de certificados
<a name="certificate-requirements"></a>

Los almacenes de confianza tienen requisitos específicos para los certificados CA que contienen:

### Requisitos de formato de certificado CA
<a name="ca-cert-format-requirements"></a>
+ **Formato:** formato PEM (Correo con privacidad mejorada)
+ **Límites de contenido:** los certificados deben estar dentro de los límites -----BEGIN CERTIFICATE----- y -----END CERTIFICATE-----
+ **Comentarios:** deben ir precedidos de un carácter \$1 y no deben contener ningún carácter -
+ **Saltos de línea**: no se permiten líneas en blanco entre los certificados

### Especificaciones de certificados compatibles
<a name="supported-cert-specs"></a>
+ **Tipo de certificado:** X.509v3
+ **Tipos de claves públicas:**
  + RSA 2048, RSA 3072, RSA 4096
  + ECDSA: secp256r1, secp384r1
+ **Algoritmos de firma:**
  + SHA256, SHA384, SHA512 con RSA
  + SHA256, SHA384, SHA512 con EC
  + SHA256, SHA384, SHA512 con RSASSA-PSS con MGF1

### Ejemplo de formato de paquete de certificados
<a name="example-cert-bundle"></a>

Varios certificados (codificados en PEM):

```
# Root CA Certificate
-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAKoK/OvD/XqiMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNV
BAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBX
aWRnaXRzIFB0eSBMdGQwHhcNMTcwNzEyMTU0NzQ4WhcNMjcwNzEwMTU0NzQ4WjBF
MQswCQYDVQQGEwJBVTETMBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW50
ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAuuExKvY1xzHFylsHiuowqpmzs7rEcuuylOuEszpFp+BtXh0ZuEtts9LP
-----END CERTIFICATE-----
# Intermediate CA Certificate
-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAKoK/OvD/XqjMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNV
BAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBX
aWRnaXRzIFB0eSBMdGQwHhcNMTcwNzEyMTU0NzQ4WhcNMjcwNzEwMTU0NzQ4WjBF
MQswCQYDVQQGEwJBVTETMBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW50
ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAuuExKvY1xzHFylsHiuowqpmzs7rEcuuylOuEszpFp+BtXh0ZuEtts9LP
-----END CERTIFICATE-----
```

## Creación de un almacén de confianza
<a name="create-trust-store"></a>

Antes de crear un almacén de confianza, debe cargar un paquete de certificados CA en formato PEM en un bucket de Amazon S3. El paquete de certificados debe contener todos los certificados CA raíz e intermedios de confianza necesarios para validar los certificados de los clientes.

El paquete de certificados CA solo se lee una vez desde S3 al crear un almacén de confianza. Si en el futuro se realizan cambios en el paquete de certificados CA, el almacén de confianza tendrá que actualizarse manualmente. No se mantiene ninguna sincronización entre el almacén de confianza y el paquete de certificados CA de S3.

### Requisitos previos
<a name="trust-store-prerequisites"></a>
+ Un paquete de certificados de la autoridad de certificación (CA) cargado en un bucket de Amazon S3
+ Los permisos necesarios para crear recursos de CloudFront

### Creación de un almacén de confianza (consola)
<a name="create-trust-store-console"></a>

1. Inicie sesión en la Consola de administración de AWS y abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. En el panel de navegación izquierdo, elija **Almacenes de confianza**.

1. Seleccione **Crear almacén de confianza**.

1. En **Nombre del almacén de confianza**, introduzca un nombre para el almacén de confianza.

1. En **Paquete de autoridad de certificación (CA)**, ingrese la ruta de Amazon S3 al paquete de certificados CA de formato PEM.

1. Seleccione **Crear almacén de confianza**.

### Creación de un almacén de confianza (CLI de AWS)
<a name="create-trust-store-cli"></a>

```
aws cloudfront create-trust-store \
  --name MyTrustStore \
  --certificate-authority-bundle-s3-location Bucket=my-bucket,Key=ca-bundle.pem \
  --tags Items=[{Key=Environment,Value=Production}]
```

## Asociación del almacén de confianza con las distribuciones
<a name="associate-trust-store"></a>

Tras crear un almacén de confianza, debe asociarlo a una distribución de CloudFront para habilitar la autenticación TLS mutua.

### Requisitos previos
<a name="associate-prerequisites"></a>
+ Una distribución de CloudFront existente con la política de protocolo de espectador solo HTTPS habilitada y la compatibilidad con HTTP3 desactivada.

### Asociación de un almacén de confianza (consola)
<a name="associate-trust-store-console"></a>

Hay dos formas de asociar un almacén de confianza a la consola de CloudFront: a través de la página de detalles del almacén de confianza o a través de la página de configuración de distribución.

**Asociación de un almacén de confianza a través de la página de detalles del almacén de confianza:**

1. Inicie sesión en la Consola de administración de AWS y abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. En el panel de navegación izquierdo, elija **Almacenes de confianza**.

1. Elija el nombre del almacén de confianza que desea asociar.

1. Elija **Asociar a distribución**.

1. Configure las opciones de mTLS de espectador disponibles:
   + **Modo de validación del certificado de cliente:** elija entre el modo obligatorio y el opcional. En el modo obligatorio, todos los clientes deben presentar los certificados. En el modo opcional, se validan los clientes que presentan certificados, mientras que a los clientes que no los presentan se les permite el acceso.
   + **Anuncie los nombres de las autoridades de certificación de los almacenes de confianza:** elija si desea anunciar los nombres de las autoridades de certificación del almacén de confianza a los clientes durante el establecimiento de comunicación de TLS.
   + **Omita la fecha de caducidad del certificado:** elija si desea permitir las conexiones con certificados caducados (se seguirán aplicando otros criterios de validación).
   + **Función de conexión:** se puede asociar una función de conexión opcional para permitir o denegar las conexiones en función de otros criterios personalizados.

1. Seleccione una o varias distribuciones para asociarlas al almacén de confianza. Solo las distribuciones con HTTP3 desactivado y con comportamientos de caché exclusivos de HTTPS pueden admitir los mTLS de espectador.

1. Elija **Asociar**.

**Asociación de un almacén de confianza a través de la página de configuración de distribución:**

1. Inicie sesión en la Consola de administración de AWS y abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Seleccione la distribución que desea asociar.

1. En la pestaña **General**, dentro del contenedor **Configuración**, elija **Editar** en la esquina superior derecha.

1. Desplácese hacia abajo hasta la parte inferior de la página, dentro del contenedor **Conectividad**, active el interruptor **mTLS de espectador**.

1. Configure las opciones de mTLS de espectador disponibles:
   + **Modo de validación del certificado de cliente:** elija entre el modo obligatorio y el opcional. En el modo obligatorio, todos los clientes deben presentar los certificados. En el modo opcional, se validan los clientes que presentan certificados, mientras que a los clientes que no los presentan se les permite el acceso.
   + **Anuncie los nombres de las autoridades de certificación de los almacenes de confianza:** elija si desea anunciar los nombres de las autoridades de certificación del almacén de confianza a los clientes durante el establecimiento de comunicación de TLS.
   + **Omita la fecha de caducidad del certificado:** elija si desea permitir las conexiones con certificados caducados (se seguirán aplicando otros criterios de validación).
   + **Función de conexión:** se puede asociar una función de conexión opcional para permitir o denegar las conexiones en función de otros criterios personalizados.

1. Elija **Guardar cambios** en la esquina inferior derecha.

### Asociación de un almacén de confianza (CLI de AWS)
<a name="associate-trust-store-cli"></a>

Los almacenes de confianza se pueden asociar a las distribuciones mediante la propiedad DistributionConfig.ViewerMtlsConfig. Esto significa que primero debemos buscar la configuración de distribución y, a continuación, proporcionar ViewerMtlsConfig en una solicitud de UpdateDistribution posterior.

```
// First fetch the distribution
aws cloudfront get-distribution {DISTRIBUTION_ID}

// Update the distribution config, for example:
Distribution config, file://distConf.json: 
{
  ...other fields,
  ViewerMtlsConfig: {
    Mode: 'required',
    TrustStoreConfig: {
        AdvertiseTrustStoreCaNames: false,
        IgnoreCertificateExpiry: true,
        TrustStoreId: {TRUST_STORE_ID}
    }
  }
}

aws cloudfront update-distribution \
   --id {DISTRIBUTION_ID} \
   --if-match {ETAG} \
   --distribution-config file://distConf.json
```

## Administración de almacenes de confianza
<a name="manage-trust-stores"></a>

### Consulta de los detalles del almacén de confianza
<a name="view-trust-store-details"></a>

1. Inicie sesión en la Consola de administración de AWS y abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. En el panel de navegación izquierdo, elija **Almacenes de confianza**.

1. Elija el nombre del almacén de confianza para ver su página de detalles.

La página de detalles muestra:
+ Nombre e ID del almacén de confianza
+ Número de certificados CA
+ Fecha de creación y fecha de última modificación
+ Distribuciones asociadas
+ Etiquetas

### Modificación de un almacén de confianza
<a name="modify-trust-store"></a>

Para reemplazar un paquete de certificados CA:

1. Inicie sesión en la Consola de administración de AWS y abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. En el panel de navegación izquierdo, elija **Almacenes de confianza**.

1. Elija el nombre del almacén de confianza.

1. Elija **Acciones** y, a continuación, **Editar**.

1. Para el **paquete de autoridades de certificación (CA)**, ingrese la ubicación de Amazon S3 del archivo PEM del paquete de autoridad de certificación actualizado.

1. Elija **Actualización del almacén de confianza**.

### Eliminación de un almacén de confianza
<a name="delete-trust-store"></a>

**Requisitos previos:** primero debe desasociar el almacén de confianza de todas las distribuciones de CloudFront.

1. Inicie sesión en la Consola de administración de AWS y abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. En el panel de navegación izquierdo, elija **Almacenes de confianza**.

1. Elija el nombre del almacén de confianza.

1. Elija **Eliminar almacén de confianza**.

1. Elija **Eliminar** para confirmar.

### Siguientes pasos
<a name="trust-store-next-steps"></a>

Tras crear y asociar el almacén de confianza a una distribución de CloudFront, puede proceder a habilitar la autenticación TLS mutua en la distribución y configurar ajustes adicionales, como el reenvío de los encabezados de los certificados a los orígenes. Para obtener instrucciones detalladas sobre cómo habilitar mTLS en las distribuciones, consulte [Habilitación de TLS mutua para las distribuciones de CloudFront](enable-mtls-distributions.md).

# Habilitación de TLS mutua para las distribuciones de CloudFront
<a name="enable-mtls-distributions"></a>

## Requisitos previos y requisitos
<a name="mtls-prerequisites-requirements"></a>

El modo de verificación de TLS mutua de CloudFront exige que todos los clientes presenten certificados válidos durante el establecimiento de comunicación de TLS y rechaza las conexiones sin certificados válidos. Antes de habilitar TLS mutua en una distribución de CloudFront, asegúrese de que dispone de:
+ Se ha creado un almacén de confianza con los certificados de autoridad de certificación
+ Se ha asociado el almacén de confianza a la distribución de CloudFront
+ Se ha asegurado que todos los comportamientos de la caché de distribución utilizan una política de protocolo de espectador solo HTTPS
+ Se ha asegurado que la distribución utilice HTTP/2 (la configuración predeterminada, mTLS de espectador no es compatible con HTTP/3)

**nota**  
La autenticación TLS mutua requiere conexiones HTTPS entre espectadores y CloudFront. No puede habilitar mTLS en una distribución con ningún comportamiento de caché que admita conexiones HTTP.

## Habilitación de TLS mutua (consola)
<a name="enable-mtls-console"></a>

### Para distribuciones nuevas
<a name="enable-mtls-new-distributions"></a>

mTLS de espectador no se puede configurar durante el proceso de creación de una nueva distribución en la consola de CloudFront. Primero cree la distribución por cualquier medio (consola, CLI, API) y, a continuación, edite la configuración de distribución para habilitar mTLS de espectador según las instrucciones de distribución existentes que se indican a continuación.

### Para distribuciones existentes
<a name="enable-mtls-existing-distributions"></a>

1. Inicie sesión en la Consola de administración de AWS y abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. En la lista de distribución, seleccione la distribución que desee modificar.

1. Asegúrese de que la política del protocolo del espectador se establece en **Redireccionamiento de HTTP a HTTPS** o **Solo HTTPS** para todos los comportamientos de la caché. (Puede elegir la pestaña **Comportamientos de la caché** para ver y actualizar cualquier comportamiento de la caché con las políticas del protocolo HTTP).

1. Elija la pestaña **General**.

1. En la sección **Settings** (Configuración), elija **Editar**.

1. En la sección **Conectividad**, busque la **Autenticación mutua del espectador (mTLS)**.

1. Active la opción **Habilitar la autenticación mutua**.

1. Para **Modo de validación de certificados de cliente**, seleccione **Obligatorio** (todos los clientes deben presentar certificados) u **Opcional** (los clientes pueden presentar certificados de forma opcional).

1. Para **Almacén de confianza**, seleccione el almacén de confianza que creó anteriormente.

1. (Opcional) Active la opción **Anunciar nombres de autoridad de certificación de almacenes de confianza** si desea que CloudFront envíe nombres de autoridades de certificación a los clientes durante el establecimiento de comunicación de TLS.

1. (Opcional) Active la opción **Ignorar la fecha de caducidad del certificado** si desea permitir las conexiones con certificados caducados.

1. Seleccione **Save changes (Guardar cambios)**.

## Habilitación de TLS mutua (CLI de AWS)
<a name="enable-mtls-cli"></a>

### Para distribuciones nuevas
<a name="enable-mtls-cli-new"></a>

El siguiente ejemplo muestra cómo crear un archivo de configuración de distribución (distribution-config.json) que incluya la configuración de mTLS:

```
{
  "CallerReference": "cli-example-1",
  "Origins": {
    "Quantity": 1,
    "Items": [
      {
        "Id": "my-origin",
        "DomainName": "example.com",
        "CustomOriginConfig": {
          "HTTPPort": 80,
          "HTTPSPort": 443,
          "OriginProtocolPolicy": "https-only"
        }
      }
    ]
  },
  "DefaultCacheBehavior": {
    "TargetOriginId": "my-origin",
    "ViewerProtocolPolicy": "https-only",
    "MinTTL": 0,
    "ForwardedValues": {
      "QueryString": false,
      "Cookies": {
        "Forward": "none"
      }
    }
  },
  "ViewerCertificate": {
    "CloudFrontDefaultCertificate": true
  },
  "ViewerMtlsConfig": {
    "Mode": "required", 
    "TrustStoreConfig": {
        "TrustStoreId": {TRUST_STORE_ID},
        "AdvertiseTrustStoreCaNames": true,
        "IgnoreCertificateExpiry": true
    }
  },
  "Enabled": true
}
```

Cree la distribución con mTLS habilitado mediante el siguiente comando de ejemplo:

```
aws cloudfront create-distribution --distribution-config file://distribution-config.json
```

### Para distribuciones existentes
<a name="enable-mtls-cli-existing"></a>

Obtenga la configuración de distribución actual mediante el siguiente comando de ejemplo:

```
aws cloudfront get-distribution-config --id E1A2B3C4D5E6F7 --output json > dist-config.json
```

Edite el archivo para agregar la configuración de mTLS. Agregue la sección de ejemplo siguiente a la configuración de distribución:

```
"ViewerMtlsConfig": {
    "Mode": "required", 
    "TrustStoreConfig": {
        "TrustStoreId": {TRUST_STORE_ID},
        "AdvertiseTrustStoreCaNames": true,
        "IgnoreCertificateExpiry": true
    }
}
```

Elimine el campo ETag del archivo, pero guarde su valor de forma independiente.

Actualice la distribución con la nueva configuración mediante el comando de ejemplo siguiente:

```
aws cloudfront update-distribution \
    --id E1A2B3C4D5E6F7 \
    --if-match YOUR-ETAG-VALUE \
    --distribution-config file://dist-config.json
```

## Políticas de protocolo para espectadores
<a name="viewer-protocol-policies"></a>

Cuando se utiliza TLS mutua, todos los comportamientos de la caché distribuida se deben configurar con una política de protocolo de espectador solo HTTPS:
+ **Redirección de HTTP a HTTPS**: redirige las solicitudes HTTP a HTTPS antes de realizar la validación del certificado.
+ **Solo HTTPS**: solo acepta solicitudes HTTPS y realiza la validación del certificado.

**nota**  
La política de protocolo de espectador HTTP y HTTPS no es compatible con TLS mutua, ya que las conexiones HTTP no pueden realizar la validación de los certificados.

## Siguientes pasos
<a name="enable-mtls-next-steps"></a>

Tras habilitar TLS del espectador en la distribución de CloudFront, puede asociar las funciones de conexión para implementar una lógica de validación de certificados personalizada. Las funciones de conexión le permiten ampliar las capacidades de autenticación mTLS integradas con reglas de validación, comprobación de la revocación de certificados y registros personalizados. Para obtener más información sobre la creación y asociación de funciones de conexión, consulte [Asociación de una función de conexión de CloudFront](connection-functions.md).

# Asociación de una función de conexión de CloudFront
<a name="connection-functions"></a>

Las funciones de conexión de CloudFront permiten implementar una lógica de validación de certificados personalizada durante los establecimientos de comunicación de TLS, lo que amplía las capacidades de autenticación mTLS integradas.

## ¿Qué son las funciones de conexión?
<a name="what-are-connection-functions"></a>

Las funciones de conexión son funciones de JavaScript que se ejecutan durante el establecimiento de comunicación de TLS después de que se hayan validado los certificados de cliente. El certificado de cliente validado se pasa a la función de conexión, momento en el que la función de conexión puede tomar una decisión adicional sobre si conceder o no el acceso. Para obtener información detallada sobre las funciones de conexión, consulte [Personalización en la periferia con CloudFront Functions](cloudfront-functions.md).

## Cómo funcionan las funciones de conexión con mTLS
<a name="how-connection-functions-work"></a>

Cuando un cliente intenta establecer una conexión de mTLS con la distribución de CloudFront, se produce la siguiente secuencia:

1. El cliente inicia el establecimiento de comunicación de TLS con la ubicación periférica de CloudFront.

1. CloudFront solicita y recibe el certificado de cliente.

1. CloudFront realiza una validación de certificados estándar en un almacén de confianza.

1. Si el certificado pasa la validación estándar, CloudFront invoca la función de conexión. Si **IgnoreCertificateExpiry** está activado en **ViewerMtlsConfig**, los certificados vencidos (pero válidos por lo demás) también se transfieren a la función de conexión. Si los certificados de cliente no son válidos, no se invocarán las funciones de conexión.

1. La función de conexión recibe la información del certificado analizada y los detalles de la conexión.

1. La función toma una decisión de permitir o denegar en función de una lógica personalizada.

1. CloudFront completa o finaliza la conexión de TLS en función de su decisión.

Las funciones de conexión se invocan tanto en el modo de verificación como en el modo opcional (cuando los clientes presentan certificados).

## Creación de una función de conexión
<a name="create-connection-function"></a>

Puede crear funciones de conexión mediante la consola de CloudFront o la CLI de AWS.

### Creación de una función de conexión (consola)
<a name="create-connection-function-console"></a>

1. Inicie sesión en Consola de administración de AWS y abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Seleccione **Funciones** en el panel de navegación.

1. Elija la pestaña **Funciones de conexión** y, a continuación, elija **Crear función de conexión**.

1. Ingrese un nombre de función que sea exclusivo dentro de la cuenta de AWS.

1. Elija **Continuar**.

1. En el editor de funciones, escriba el código de JavaScript para la validación del certificado. El controlador de funciones debe llamar a permitir o rechazar.

1. Opcional: se puede asociar un almacén KeyValue a la función de conexión para implementar el control de revocación.

1. Seleccione **Save changes (Guardar cambios)**.

### Creación de una función de conexión (CLI de AWS)
<a name="create-connection-function-cli"></a>

En el siguiente ejemplo, se muestra cómo crear una función de conexión:

Escriba el código de la función en un archivo independiente, por ejemplo, code.js:

```
function connectionHandler(connection) {
  connection.allow();
}
```

```
aws cloudfront create-connection-function \
  --name "certificate-validator" \
  --connection-function-config '{
      "Comment": "Client certificate validation function",
      "Runtime": "cloudfront-js-2.0"
  }' \
  --connection-function-code fileb://code.js
```

## Estructura de código de la función de conexión
<a name="connection-function-code-structure"></a>

Las funciones de conexión implementan la función connectionHandler que recibe un objeto de conexión que contiene el certificado y la información de conexión. La función debe utilizar una de las dos opciones, `connection.allow()` o `connection.deny()`, para tomar una decisión sobre la conexión.

### Ejemplo de función de conexión básica
<a name="basic-connection-function-example"></a>

En el siguiente ejemplo, se muestra una función de conexión sencilla que verifica el campo de asunto de los certificados de cliente:

```
function connectionHandler(connection) {
    // Only process if a certificate was presented
    if (!connection.clientCertificate) {
        console.log("No certificate presented");
        connection.deny();
    }
    
    // Check the subject field for specific organization
    const subject = connection.clientCertificate.certificates.leaf.subject;
    if (!subject.includes("O=ExampleCorp")) {
        console.log("Certificate not from authorized organization");
       connection.deny();
    } else {
        // All checks passed
        console.log("Certificate validation passed");
        connection.allow();
    }
}
```

La especificación completa de las propiedades del certificado de cliente disponibles en el objeto de conexión está disponible aquí:

```
{
  "connectionId": "Fdb-Eb7L9gVn2cFakz7wWyBJIDAD4-oNO6g8r3vXDV132BtnIVtqDA==", // Unique identifier for this TLS connection
  "clientIp": "203.0.113.42", // IP address of the connecting client (IPv4 or IPv6)
  "clientCertificate": {
    "certificates": {
      "leaf": {
        "subject": "CN=client.example.com,O=Example Corp,C=US", // Distinguished Name (DN) of the certificate holder
        "issuer": "CN=Example Corp Intermediate CA,O=Example Corp,C=US", // Distinguished Name (DN) of the certificate authority that issued this certificate
        "serialNumber": "4a:3f:5c:92:d1:e8:7b:6c", // Unique serial number assigned by the issuing CA (hexadecimal)
        "validity": {
          "notBefore": "2024-01-15T00:00:00Z", // Certificate validity start date (ISO 8601 format)
          "notAfter": "2025-01-14T23:59:59Z"   // Certificate expiration date (ISO 8601 format)
        },
        "sha256Fingerprint": "a1b2c3d4e5f6...abc123def456", // SHA-256 hash of the certificate (64 hex characters)
      },
    },
  },
}
```

## Asociación de una función de conexión
<a name="associate-connection-function-section"></a>

Tras crear la función de conexión, debe publicarla en la etapa ACTIVA y asociarla a la distribución.

### Publicación y asociación de una función de conexión (consola)
<a name="publish-associate-console"></a>

1. Inicie sesión en la Consola de administración de AWS y abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Seleccione **Funciones** en el panel de navegación

1. Elija la pestaña **Funciones de conexión** y seleccione la función de conexión.

1. Elija **Publicar** para moverla a la etapa ACTIVA.

1. Elija **Agregar asociación** en la tabla de distribuciones asociadas situada debajo de la sección de publicación.

1. Seleccione la distribución que desee asociar con mTLS de espectador habilitado.

Como opción alternativa, las funciones de conexión publicadas también se pueden asociar desde la página de detalles de la distribución.

1. Diríjase a la página de inicio de la consola, donde se muestran todas las distribuciones.

1. Seleccione la distribución que desea asociar.

1. Elija la pestaña **General**.

1. En la sección **Settings** (Configuración), elija **Editar**.

1. En la sección **Conectividad**, busque la **Autenticación mutua del espectador (mTLS)**.

1. Para **Función de conexión**, seleccione la función.

1. Seleccione **Save changes (Guardar cambios)**.

### Asociación de una función de conexión (CLI de AWS)
<a name="associate-connection-function-cli"></a>

En el siguiente ejemplo, se muestra cómo asociar una función de conexión a una distribución:

```
// DistributionConfig:
{
   ...other settings,
    "ConnectionFunctionAssociation": {
        "Id": "cf_30c2CV2elHwCoInb3LtcaUJkZeD"
    }
}
```

## Casos de uso para funciones de conexión
<a name="connection-function-use-cases"></a>

Las funciones de conexión permiten varios casos de uso avanzados de mTLS:
+ **Validación de los atributos de los certificados**: verifique campos específicos de los certificados de los clientes, como los requisitos de las unidades organizativas o los patrones de nombres alternativos de los temas.
+ **Comprobación de la revocación de certificados**: Implemente una comprobación de revocación de certificados personalizada mediante KeyValueStore para almacenar los números de serie de los certificados revocados.
+ **Políticas de certificados basadas en IP**: aplique diferentes políticas de certificación en función de las direcciones IP de los clientes o de las restricciones geográficas.
+ **Validación multiusuario**: implemente reglas de validación específicas para cada inquilino en las que se apliquen diferentes requisitos de certificación en función de los nombres de host o los atributos de certificados.

**nota**  
Las funciones de conexión se ejecutan una vez por conexión de cliente durante el establecimiento de comunicación de TLS.  
Las funciones de conexión solo pueden permitir o denegar las conexiones, no modificar las solicitudes o respuestas HTTP.  
Solo las funciones de etapa ACTIVA (publicadas) se pueden asociar a las distribuciones.  
Cada distribución puede tener como máximo una función de conexión.

## Siguientes pasos
<a name="connection-function-next-steps"></a>

Tras asociar una función de conexión a la distribución de CloudFront, puede configurar los ajustes opcionales para personalizar el comportamiento de la implementación de mTLS. Para obtener instrucciones detalladas sobre cómo configurar ajustes adicionales, como un modo de validación de certificados de cliente opcional, consulte [Configuración adicional](configuring-additional-settings.md).

# Configuración adicional
<a name="configuring-additional-settings"></a>

Tras habilitar la autenticación TLS mutua básica, puede configurar ajustes adicionales para personalizar el comportamiento de autenticación para casos de uso y requisitos específicos.

## Modo opcional de validación de certificados de cliente
<a name="optional-mode"></a>

CloudFront ofrece un modo de validación de certificados de cliente opcional alternativo que valida los certificados de cliente que se presentan, pero permite el acceso a los clientes que no presentan certificados.

### Comportamiento del modo opcional
<a name="optional-mode-behavior"></a>
+ Otorga la conexión a los clientes con certificados válidos (se deniegan los certificados no válidos).
+ Permite la conexión a clientes sin certificados.
+ Permite escenarios de autenticación de clientes mixtos a través de una única distribución.

El modo opcional es ideal para la migración gradual a la autenticación mTLS, para dar soporte a clientes con certificados y clientes sin certificados, o para mantener la compatibilidad con versiones anteriores de clientes antiguos.

**nota**  
En el modo opcional, las funciones de conexión se siguen invocando incluso cuando los clientes no presentan certificados. Esto permite implementar una lógica personalizada, como registrar las direcciones IP de los clientes o aplicar diferentes políticas en función de si se presentan los certificados.

### Configuración del modo opcional (consola)
<a name="configure-optional-mode-console"></a>

1. En la configuración de distribución, vaya a la pestaña **General** y elija **Editar**.

1. Desplácese hasta la sección **Autenticación mutua (mTLS) del espectador** en el contenedor **Conectividad**.

1. Para **Modo de validación de certificado de cliente**, seleccione **Opcional**.

1. Guarde los cambios.

### Configuración del modo opcional (CLI de AWS)
<a name="configure-optional-mode-cli"></a>

En el siguiente ejemplo, se muestra cómo configurar el modo opcional:

```
"ViewerMtlsConfig": {
   "Mode": "optional",
   ...other settings
}
```

## Anuncio de la autoridad de certificación
<a name="ca-advertisement"></a>

El campo AdvertiseTrustStoreCaNames controla si CloudFront envía la lista de nombres de autoridad de certificación de confianza a los clientes durante el establecimiento de comunicación de TLS, lo que ayuda a los clientes a seleccionar el certificado adecuado.

### Configuración de la publicidad de la autoridad de certificación (consola)
<a name="configure-ca-advertisement-console"></a>

1. En la configuración de distribución, vaya a la pestaña **General** y elija **Editar**.

1. Desplácese hasta la sección **Autenticación mutua (mTLS) del espectador** en el contenedor **Conectividad**.

1. Active o desactive la casilla de verificación **Anunciar nombres de autoridad de certificación de almacenes de confianza**.

1. Seleccione **Save changes (Guardar cambios)**.

### Configuración de la publicidad de la autoridad de certificación (CLI de AWS)
<a name="configure-ca-advertisement-cli"></a>

En el ejemplo siguiente, se muestra cómo habilitar la publicidad de la autoridad de certificación:

```
"ViewerMtlsConfig": {
   "Mode": "required", // or "optional"
   "TrustStoreConfig": {
      "AdvertiseTrustStoreCaNames": true,
      ...other settings
   } 
}
```

## Gestión de caducidad de certificados
<a name="certificate-expiration-handling"></a>

La propiedad IgnoreCertificateExpiry determina cómo responde CloudFront a los certificados de cliente caducados. De forma predeterminada, CloudFront rechaza los certificados de cliente caducados, pero puede configurarlo para que los acepte cuando sea necesario. Por lo general, esto se habilita para dispositivos con certificados caducados que no se pueden actualizar fácilmente.

### Configuración de la gestión de la caducidad de los certificados (consola)
<a name="configure-expiration-console"></a>

1. En la configuración de distribución, vaya a la pestaña **General** y elija **Editar**.

1. Desplácese hasta la sección **Autenticación mutua (mTLS) del espectador** del contenedor **Conectividad**.

1. Seleccione o desmarque la casilla de verificación **Omitir la fecha de caducidad del certificado**.

1. Seleccione **Save changes (Guardar cambios)**.

### Configuración de la gestión de la caducidad de los certificados (CLI de AWS)
<a name="configure-expiration-cli"></a>

En el siguiente ejemplo, se muestra cómo ignorar la caducidad de un certificado:

```
"ViewerMtlsConfig": {
  "Mode": "required", // or "optional"
  "TrustStoreConfig": {
     "IgnoreCertificateExpiry": false,
     ...other settings
  }
}
```

**nota**  
**IgnoreCertificateExpiry** solo se aplica a las fechas de validez de los certificados. Se siguen aplicando todas las demás comprobaciones de validación de certificados (cadena de confianza, validación de firmas).

## Siguientes pasos
<a name="additional-settings-next-steps"></a>

Tras configurar ajustes adicionales, puede configurar el reenvío de encabezados para transferir la información del certificado a los orígenes, implementar la revocación de certificados mediante funciones de conexión y KeyValueStore, y habilitar los registros de conexión para su supervisión. Para obtener más información sobre cómo reenviar la información de los certificados a los orígenes, consulte [Reenviar encabezados a los orígenes](viewer-mtls-headers.md).

# Encabezados de mTLS del espectador para las políticas de caché y reenvío al origen
<a name="viewer-mtls-headers"></a>

Al utilizar la autenticación TLS mutua, CloudFront puede extraer información de los certificados de cliente y reenviarla a los orígenes como encabezados HTTP. Esto permite que los servidores de origen accedan a los detalles de los certificados sin implementar una lógica de validación de certificados.

Los siguientes encabezados están disponibles para crear comportamientos de caché:


| Nombre del encabezado | Descripción | Ejemplo de valor | 
| --- | --- | --- | 
| CloudFront-Viewer-Cert-Serial-Number | Representación hexadecimal del número de serie del certificado | 4a:3f:5c:92:d1:e8:7b:6c | 
| CloudFront-Viewer-Cert-Issuer | Representación de cadena RFC2253 del nombre distintivo (DN) del emisor | CN=rootcamtls.com,OU=rootCA,O=mTLS,L=Seattle,ST=Washington,C=US | 
| CloudFront-Viewer-Cert-Subject | Representación de cadena RFC2253 del nombre distintivo (DN) del sujeto | CN=client\$1.com,OU=client-3,O=mTLS,ST=Washington,C=US | 
| CloudFront-Viewer-Cert-Present | 1 (presente) o 0 (no presente) indican si el certificado está presente. Este valor siempre es 1 en el modo obligatorio. | 1 | 
| CloudFront-Viewer-Cert-Sha256 | El hash SHA256 del certificado del cliente | 01fbf94fef5569753420c349f49adbfd80af5275377816e3ab1fb371b29cb586 | 

Para las solicitudes de origen, se proporcionan dos encabezados adicionales, además de los encabezados anteriores disponibles para los comportamientos de la caché:


| Nombre del encabezado | Descripción | Ejemplo de valor | 
| --- | --- | --- | 
| CloudFront-Viewer-Cert-Validity | Formato ISO8601 de la fecha notBefore y notAfter | CloudFront-Viewer-Cert-Validity: NotBefore=2023-09-21T01:50:17Z;NotAfter=2024-09-20T01:50:17Z | 
| CloudFront-Viewer-Cert-Pem | Formato PEM codificado en URL del certificado de hoja | CloudFront-Viewer-Cert-Pem: -----BEGIN%20CERTIFICATE-----%0AMIIG<...reduced...>NmrUlw%0A-----END%20CERTIFICATE-----%0A | 

## Configuración del reenvío de encabezados
<a name="configure-header-forwarding"></a>

### Consola
<a name="configure-headers-console"></a>

En el modo de verificación, CloudFront agrega automáticamente los encabezados CloudFront-Viewer-Cert-\$1 a todas las solicitudes de los espectadores. Reenvío de estos encabezados al origen:

1. En la página principal de distribuciones de la lista, seleccione la distribución con el mTLS de espectador habilitado y vaya a la pestaña **Comportamientos**.

1. Seleccione el comportamiento de caché y elija **Editar**.

1. En la sección **Política de solicitudes de origen**, elija **Crear política** o seleccione una política existente.

1. Asegúrese de que los siguientes encabezados estén incluidos en la política de solicitud de origen:
   + CloudFront-Viewer-Cert-Serial-Number
   + CloudFront-Viewer-Cert-Issuer
   + CloudFront-Viewer-Cert-Subject
   + CloudFront-Viewer-Cert-Present
   + Cloudfront-Viewer-Cert-Sha256
   + CloudFront-Viewer-Cert-Validity
   + CloudFront-Viewer-Cert-Pem

1. Elija **Crear** (para políticas nuevas) o **Guardar cambios** (para políticas existentes).

1. Seleccione la política que se ajuste al comportamiento de la memoria caché y guarde los cambios.

### Uso de la CLI de AWS
<a name="configure-headers-cli"></a>

En el siguiente ejemplo se muestra cómo crear una política de solicitud de origen que incluya encabezados mTLS para el modo de verificación:

```
aws cloudfront create-origin-request-policy \
  --origin-request-policy-config '{
    "Name": "MTLSHeadersPolicy",
    "HeadersConfig": {
      "HeaderBehavior": "whitelist",
      "Headers": {
        "Quantity": 5,
        "Items": [
          "CloudFront-Viewer-Cert-Serial-Number",
          "CloudFront-Viewer-Cert-Issuer",
          "CloudFront-Viewer-Cert-Subject",
          "CloudFront-Viewer-Cert-Validity",
          "CloudFront-Viewer-Cert-Pem"
        ]
      }
    },
    "CookiesConfig": {
      "CookieBehavior": "none"
    },
    "QueryStringsConfig": {
      "QueryStringBehavior": "none"
    }
  }'
```

## Consideraciones sobre el procesamiento de encabezados
<a name="header-processing-considerations"></a>

Cuando trabaje con encabezados de certificados, tenga en cuenta estas prácticas recomendadas:
+ **Validación de encabezados:** compruebe los valores de los encabezados de los certificados en el origen como medida de seguridad adicional
+ **Límites de tamaño de los encabezados:** los encabezados de los certificados PEM pueden ser grandes, asegúrese de que el servidor de origen pueda gestionarlos
+ **Consideraciones sobre la caché:** el uso de encabezados de certificado en la clave de caché aumenta la fragmentación de la caché
+ **Solicitudes de origen cruzado:** si la aplicación usa CORS, es posible que deba configurarla para permitir los encabezados de los certificados

## Siguientes pasos
<a name="headers-next-steps"></a>

Tras configurar el reenvío de encabezados, puede implementar la comprobación de la revocación de certificados mediante funciones de conexión de CloudFront y KeyValueStore. Para obtener más información sobre la implementación de las comprobaciones de revocación, consulte [Revocación mediante la función de conexión de CloudFront y KVS](revocation-connection-function-kvs.md).

# Revocación mediante la función de conexión de CloudFront y KVS
<a name="revocation-connection-function-kvs"></a>

Puede implementar la comprobación de revocación de certificados para la autenticación TLS mutua combinando funciones de conexión de CloudFront con KeyValueStore. Este enfoque proporciona un mecanismo de revocación de certificados escalable y en tiempo real que complementa la validación de certificados integrada en CloudFront.

Las funciones de conexión son funciones de JavaScript que se ejecutan durante el establecimiento de la conexión de TLS en las ubicaciones periféricas de CloudFront y permiten implementar una lógica de validación de certificados personalizada para la autenticación mTLS. Para obtener información detallada sobre las funciones de conexión, consulte [Asociación de una función de conexión de CloudFront](connection-functions.md).

## Cómo funciona la revocación de certificados con funciones de conexión
<a name="how-revocation-works"></a>

La validación de certificados estándar de CloudFront verifica la cadena, la firma y la caducidad del certificado, pero no incluye la comprobación de revocación de certificados integrada. Al usar funciones de conexión, puede implementar una comprobación de revocación personalizada durante el establecimiento de comunicación de TLS.

El proceso de revocación de certificados funciona de la siguiente manera:

1. Guarde los números de serie de los certificados revocados en un KeyValueStore de CloudFront.

1. Cuando un cliente presenta un certificado, se invoca la función de conexión.

1. La función compara el número de serie del certificado con el KeyValueStore.

1. Si el número de serie se encuentra en la tienda, se revoca el certificado.

1. Su función deniega la conexión en el caso de los certificados revocados.

Este enfoque permite comprobar las revocaciones prácticamente en tiempo real en toda la red de periferia global de CloudFront.

## Configuración de KeyValueStore para certificados revocados
<a name="setup-kvs-revoked-certs"></a>

En primer lugar, cree un KeyValueStore para almacenar los números de serie de los certificados revocados:

### Creación de un KeyValueStore (consola)
<a name="create-kvs-console"></a>

1. Inicie sesión en la Consola de administración de AWS y abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. En el panel de navegación, elija **Almacenes de valores de claves**.

1. Elija **Creación de un almacén de valores de claves**.

1. Ingrese un nombre para el almacén de valores de claves (por ejemplo, certificados revocados).

1. (Opcional) Añada una descripción.

1. Elija **Creación de un almacén de valores de claves**.

### Creación de un KeyValueStore (CLI de AWS)
<a name="create-kvs-cli"></a>

En el ejemplo siguiente se muestra cómo crear un KeyValueStore:

```
aws cloudfront create-key-value-store \
  --name "revoked-certificates" \
  --comment "Store for revoked certificate serial numbers"
```

## Importación de los números de serie de los certificados revocados
<a name="import-revoked-serials"></a>

Después de crear un KeyValueStore, debe importar los números de serie de los certificados revocados:

### Preparación de los datos de revocación
<a name="prepare-revocation-data"></a>

Cree un archivo JSON con los números de serie de los certificados revocados:

```
{
  "data": [
    {
      "key": "ABC123DEF456",
      "value": ""
    },
    {
      "key": "789XYZ012GHI",
      "value": ""
    }
  ]
}
```

### Importar desde S3
<a name="import-from-s3"></a>

1. Carga del archivo JSON en un bucket de S3

1. Importación del archivo al KeyValueStore:

   ```
   aws cloudfront create-key-value-store \
     --name "revoked-certificates" \
     --import-source '{
       "SourceType": "S3",
       "SourceARN": "arn:aws:s3:::amzn-s3-demo-bucket1/revoked-serials.json"
     }'
   ```

## Creación de una función de conexión para comprobar las revocaciones
<a name="create-revocation-connection-function"></a>

Cree una función de conexión que compruebe los números de serie de los certificados con el KeyValueStore:

### Ejemplo de código de función de conexión
<a name="revocation-function-example"></a>

En el ejemplo siguiente, se muestra una función de conexión que realiza la comprobación de la revocación de certificados:

```
import cf from 'cloudfront';

async function connectionHandler(connection) {
    const kvsHandle = cf.kvs();
    
    // Get client certificate serial number
    const clientSerialNumber = connection.clientCertificate.certificates.leaf.serialNumber;
    
    // Check if the serial number exists in the KeyValueStore
    const isRevoked = await kvsHandle.exists(clientSerialNumber.replaceAll(':', ''));
    
    if (isRevoked) {
        console.log(`Certificate ${clientSerialNumber} is revoked. Denying connection.`);
        connection.logCustomData(`REVOKED:${clientSerialNumber}`);
        connection.deny();
    } else {
        console.log(`Certificate ${clientSerialNumber} is valid. Allowing connection.`);
        connection.allow();
    }
    
}
```

### Creación de la función de conexión (CLI de AWS)
<a name="create-revocation-function-cli"></a>

En el siguiente ejemplo, se muestra cómo crear una función de conexión con la asociación de KeyValueStore:

```
aws cloudfront create-connection-function \
  --name "revocation-checker" \
  --connection-function-config '{
      "Comment": "Certificate revocation checking function",
      "Runtime": "cloudfront-js-2.0",
      "KeyValueStoreAssociations": {
          "Quantity": 1,
          "Items": [
              {
                  "KeyValueStoreARN": "arn:aws:cloudfront::123456789012:key-value-store/revoked-certificates"
              }
          ]
      }
  }' \
  --connection-function-code fileb://revocation-checker.js
```

## Asociación de la función con la distribución
<a name="associate-revocation-function"></a>

Tras crear y publicar la función de conexión, asóciela a la distribución de CloudFront compatible con mTLS, tal y como se describe en la sección [Asociación de una función de conexión de CloudFront](connection-functions.md).

# Observabilidad mediante registros de conexión
<a name="connection-logs"></a>

Los registros de conexión de CloudFront proporcionan una visibilidad detallada de los eventos de autenticación TLS mutua, lo que permite supervisar la validación de los certificados, realizar un seguimiento de los intentos de conexión y solucionar problemas de autenticación.

## ¿Qué son los registros de conexión?
<a name="what-are-connection-logs"></a>

Los registros de conexión recopilan información detallada sobre los establecimientos de comunicación de TLS y la validación de certificados en el caso de distribuciones mutuas compatibles con TLS. A diferencia de los registros de acceso estándar que registran la información de las solicitudes HTTP, los registros de conexión se centran específicamente en la fase de establecimiento de la conexión de TLS, e incluyen:
+ Estado de la conexión (éxito/error)
+ Detalles del certificado del cliente
+ Información de cifrado y protocolo TLS
+ Métricas de temporización de conexión
+ Datos personalizados de funciones de conexión

Estos registros proporcionan una visibilidad completa de los eventos de autenticación basados en certificados, lo que lo ayuda a supervisar la seguridad, solucionar problemas y cumplir con los requisitos de conformidad.

## Habilitación de registros de conexión
<a name="enable-connection-logs"></a>

Los registros de conexión solo están disponibles para las distribuciones con la autenticación TLS mutua habilitada. Puede enviar registros de conexión a varios destinos, incluidos registros de CloudWatch, Amazon Data Firehose y Amazon S3.

### Requisitos previos
<a name="connection-logs-prerequisites"></a>

Antes de habilitar los registros de conexión:
+ Configure TLS mutua para la distribución de CloudFront.
+ Habilite los registros de conexión para la distribución de CloudFront.
+ Asegúrese de que dispone de los permisos necesarios para el destino de registro elegido.
+ Para realizar entregas entre cuentas, configure las políticas de IAM adecuadas.

### Habilitación de registros de conexión (consola)
<a name="enable-connection-logs-console"></a>

1. Inicie sesión en la Consola de administración de AWS y abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. En la lista de distribución, seleccione la distribución compatible con mTLS.

1. Elija la pestaña **Logging** (Registro).

1. Elija **Agregar**.

1. Seleccione el servicio para recibir los registros:
   + **Registros de CloudWatch**
   + **Firehose**
   + **Amazon S3**

1. Para **Destino**, seleccione el recurso para el servicio elegido:
   + Para registros de CloudWatch, ingrese el **Nombre del grupo de registro**.
   + Para Firehose, seleccione el **Flujo de entrega de Firehose**.
   + Para Amazon S3, ingrese el **Nombre del bucket** (opcionalmente con un prefijo)

1. (Opcional) Configure ajustes adicionales:
   + **Selección de campos:** seleccione los campos de registro específicos que desee incluir.
   + **Formato de salida:** elija entre JSON, Plain, w3c, Raw o Parquet (solo S3).
   + **Delimitador de campo:** especifique cómo separar los campos de registro.

1. Elija **Guardar cambios**.

### Habilitación de los registros de conexión (CLI de AWS)
<a name="enable-connection-logs-cli"></a>

En el siguiente ejemplo, se muestra cómo habilitar registros de conexión mediante la API de CloudWatch:

```
# Step 1: Create a delivery source
aws logs put-delivery-source \
  --name "cf-mtls-connection-logs" \
  --resource-arn "arn:aws:cloudfront::123456789012:distribution/E1A2B3C4D5E6F7" \
  --log-type CONNECTION_LOGS

# Step 2: Create a delivery destination
aws logs put-delivery-destination \
  --name "s3-destination" \
  --delivery-destination-configuration \
  "destinationResourceArn=arn:aws:s3:::amzn-s3-demo-bucket1"

# Step 3: Create the delivery
aws logs create-delivery \
  --delivery-source-name "cf-mtls-connection-logs" \
  --delivery-destination-arn "arn:aws:logs:us-east-1:123456789012:delivery-destination:s3-destination"
```

**nota**  
Al utilizar la API de CloudWatch, debe especificar la región Este de EE. UU. (Norte de Virginia) (us-east-1), incluso al entregar registros a otras regiones.

## Campos de registro de conexión
<a name="connection-log-fields"></a>

Los registros de conexión incluyen información detallada sobre cada intento de conexión de TLS:


| Campo | Descripción | Ejemplo | 
| --- | --- | --- | 
| eventTimestamp | Marca temporal ISO 8601 de cuando se estableció la conexión o se produjo un error | 1731620046814 | 
| connectionId | Identificador único para la conexión de TLS | oLHiEKbQSn8lkvJfA3D4gFowK3\$1iZ0g4i5nMUjE1Akod8TuAzn5nzg== | 
| connectionStatus |  El estado del intento de conexión de mTLS.  | Success o Failed | 
| clientIp | La dirección IP del cliente que se conecta | 2001:0db8:85a3:0000:0000:8a2e:0370:7334 | 
| clientPort | Puerto utilizado por el cliente | 12137 | 
| serverIp | Dirección IP del servidor perimetral de CloudFront | 99.84.71.136 | 
| distributionId | ID de distribución de CloudFront | E2DX1SLDPK0123 | 
| distributionTenantId | ID de inquilino de distribución de CloudFront (cuando proceda) | dt\$12te1Ura9X3R2iCGNjW123 | 
| tlsProtocol | La versión del protocolo TLS usado | TLSv1.3 | 
| tlsCipher | Conjunto de cifrado TLS utilizado para la conexión | TLS\$1AES\$1128\$1GCM\$1SHA256 | 
| tlsHandshakeDuration | Duración del establecimiento de comunicación de TLS en milisegundos | 153 | 
| tlsSni | Valor de indicación del nombre del servidor obtenido del establecimiento de comunicación de TLS | d111111abcdef8.cloudfront.net | 
| clientLeafCertSerialNumber | Número de serie del certificado del cliente | 00:b1:43:ed:93:d2:d8:f3:9d | 
| clientLeafCertSubject | Campo de asunto del certificado del cliente | C=US, ST=WA, L=Seattle, O=Amazon.com, OU=CloudFront, CN=client.test.mtls.net | 
| clientLeafCertIssuer | Campo de emisor del certificado del cliente | C=US, ST=WA, L=Seattle, O=Amazon.com, OU=CloudFront, CN=test.mtls.net | 
| clientLeafCertValidity | Periodo de validez del certificado del cliente | NotBefore=2025-06-05T23:28:21Z;NotAfter=2125-05-12T23:28:21Z | 
| connectionLogCustomData | Datos personalizados agregados a través de las funciones de conexión | REVOKED:00:b1:43:ed:93:d2:d8:f3:9d | 

## Códigos de error de conexión
<a name="connection-error-codes"></a>

```
Failed:ClientCertMaxChainDepthExceeded
Failed:ClientCertMaxSizeExceeded
Failed:ClientCertUntrusted
Failed:ClientCertNotYetValid
Failed:ClientCertExpired
Failed:ClientCertTypeUnsupported
Failed:ClientCertInvalid
Failed:ClientCertIntentInvalid
Failed:ClientCertRejected
Failed:ClientCertMissing
Failed:TcpError
Failed:TcpTimeout
Failed:ConnectionFunctionError
Failed:ConnectionFunctionDenied
Failed:Internal
Failed:UnmappedConnectionError
```

Cuando las conexiones producen un error, CloudFront registra códigos de motivo específicos:


| Código | Descripción | 
| --- | --- | 
| ClientCertMaxChainDepthExceeded | Se ha superado la profundidad máxima de la cadena de certificados | 
| ClientCertMaxSizeExceeded | Se ha superado el tamaño máximo de certificado | 
| ClientCertUntrusted | El certificado no es de confianza | 
| ClientCertNotYetValid | El certificado aún no es válido | 
| ClientCertExpired | El certificado ha caducado | 
| ClientCertTypeUnsupported | El tipo de certificado de cliente no es compatible | 
| ClientCertInvalid | El certificado no es válido | 
| ClientCertIntentInvalid | La finalidad del certificado no es válida | 
| ClientCertRejected | Se ha rechazado el certificado mediante validación personalizada | 
| ClientCertMissing | Certificado faltante | 
| TcpError |  Se ha producido un error al intentar establecer conexión  | 
| TcpTimeout |  No se pudo establecer la conexión dentro del periodo de espera  | 
| ConnectionFunctionError |  Se produjo una excepción no detectada durante la ejecución de la función de conexión  | 
| Interna |  Se ha producido un error de servicio interno  | 
| UnmappedConnectionError |  Se ha producido un error que no pertenece a ninguna de las otras categorías  | 

# TLS mutua de origen con CloudFront
<a name="origin-mtls-authentication"></a>

La autenticación TLS mutua (Autenticación de seguridad de la capa de transporte mutua: mTLS) es un protocolo de seguridad que amplía la autenticación TLS estándar al requerir una autenticación bidireccional basada en certificados, en la que tanto el cliente como el servidor deben demostrar su identidad antes de establecer una conexión segura.

## mTLS de espectador frente a mTLS de origen
<a name="viewer-mtls-vs-origin-mtls"></a>

La autenticación mutua (mTLS) se puede habilitar entre los espectadores y la distribución de CloudFront (mTLS de espectador) o también entre la distribución de CloudFront y el origen (mTLS de origen). Esta documentación se refiere a la configuración de mTLS de origen. Para la configuración de mTLS del espectador consulte: [Autenticación TLS mutua con CloudFront (mTLS de espectador)TLS mutua de origen con CloudFront](mtls-authentication.md).

mTLS de origen permite a CloudFront autenticarse en los servidores de origen mediante certificados de cliente. Con mTLS de origen, puede asegurarse de que solo las distribuciones autorizadas de CloudFront puedan establecer conexiones con los servidores de aplicaciones, lo que ayuda a protegerse contra los intentos de acceso no autorizados.

**nota**  
En las conexiones mTLS de origen, CloudFront actúa como cliente y presenta su certificado de cliente al servidor de origen durante el establecimiento de comunicación de TLS. CloudFront no valida el certificado del cliente ni el estado de revocación, esto es responsabilidad del servidor de origen. La infraestructura de origen debe estar configurada para validar el certificado de cliente con respecto al almacén de confianza, comprobar la caducidad del certificado y realizar comprobaciones de revocación (como la validación de CRL u OCSP) de acuerdo con los requisitos de seguridad. El rol de CloudFront se limita a presentar el certificado; los servidores de origen aplican toda la lógica de validación de certificados y las políticas de seguridad.

## Funcionamiento
<a name="how-origin-mtls-works"></a>

En un establecimiento de comunicación de TLS estándar entre CloudFront y un origen, solo el servidor de origen presenta un certificado que demuestre su identidad a CloudFront. Con mTLS de origen, el proceso de autenticación pasa a ser bidireccional. Cuando CloudFront intenta conectarse al servidor de origen, CloudFront presenta un certificado de cliente durante el establecimiento de comunicación de TLS. El servidor de origen valida este certificado con su almacén de confianza antes de establecer la conexión segura.

## Casos de uso
<a name="origin-mtls-use-cases"></a>

mTLS de origen aborda varios escenarios de seguridad críticos en los que los métodos de autenticación tradicionales crean una sobrecarga operativa:
+ **Seguridad híbrida y multinube**: puede proteger las conexiones entre CloudFront y los orígenes alojados fuera de AWS o los orígenes públicos en AWS. Esto elimina la necesidad de administrar las listas de direcciones IP permitidas o las soluciones de encabezados personalizadas, lo que proporciona una autenticación coherente basada en certificados en AWS, los centros de datos en las instalaciones y proveedores de terceros. Las empresas de medios de comunicación, los minoristas y las empresas que operan infraestructuras distribuidas se benefician de los controles de seguridad estandarizados en toda su infraestructura.
+ **API de B2B y seguridad de backend**: puede proteger las API y microservicios de backend de los intentos de acceso directo y, al mismo tiempo, conservar los beneficios de rendimiento de CloudFront. Las plataformas SaaS, los sistemas de procesamiento de pagos y las aplicaciones empresariales con requisitos de autenticación estrictos pueden comprobar que las solicitudes de API se originan solo en distribuciones de CloudFront autorizadas, lo que evita los ataques de intermediarios y los intentos de acceso no autorizados.

## Importante: requisitos del servidor de origen
<a name="important-origin-server-requirements"></a>

mTLS de origen requiere que los servidores de origen estén configurados para admitir la autenticación TLS mutua. Su infraestructura de origen debe ser capaz de:
+ Solicitar y validar los certificados de los clientes durante los establecimientos de comunicación de TLS.
+ Mantener un almacén de confianza con los certificados de la autoridad de certificación que emitió los certificados de cliente de CloudFront.
+ Registrar y supervisar los eventos de conexión TLS mutua.
+ Administrar las políticas de validación de certificados y gestionar los errores de autenticación.

CloudFront se encarga de la presentación de los certificados del cliente, pero los servidores de origen son responsables de validar estos certificados y administrar la conexión TLS mutua. Asegúrese de que la infraestructura de origen esté configurada correctamente antes de habilitar mTLS de origen en CloudFront.

## Introducción
<a name="how-origin-mtls-getting-started"></a>

Para implementar mTLS de origen con CloudFront, tendrá que importar el certificado de cliente en AWS Certificate Manager, configurar el servidor de origen para que requiera TLS mutua y habilitar mTLS de origen en la distribución de CloudFront. En las siguientes secciones, se proporcionan instrucciones paso a paso para cada tarea de configuración.

**Topics**
+ [mTLS de espectador frente a mTLS de origen](#viewer-mtls-vs-origin-mtls)
+ [Funcionamiento](#how-origin-mtls-works)
+ [Casos de uso](#origin-mtls-use-cases)
+ [Importante: requisitos del servidor de origen](#important-origin-server-requirements)
+ [Introducción](#how-origin-mtls-getting-started)
+ [Administración de certificados con AWS Certificate Manager](origin-certificate-management-certificate-manager.md)
+ [Habilitación de TLS mutua de origen para las distribuciones de CloudFront](origin-enable-mtls-distributions.md)
+ [Uso de CloudFront Functions con TLS mutua de origen](origin-mtls-cloudfront-functions.md)

# Administración de certificados con AWS Certificate Manager
<a name="origin-certificate-management-certificate-manager"></a>

[AWS Certificate Manager (ACM)](https://aws.amazon.com/certificate-manager/) almacena los certificados de cliente que CloudFront presenta a los servidores de origen durante la autenticación de TLS mutua de origen.

## Compatibilidad de la autoridad de certificación
<a name="origin-ca-support"></a>

mTLS de origen de CloudFront requiere certificados de cliente con uso ampliado de claves (EKU) para la autenticación de clientes de TLS. Debido a este requisito, debe emitir los certificados de la autoridad de certificación e importarlos a AWS Certificate Manager. Las características automáticas de aprovisionamiento y renovación de certificados de ACM no están disponibles para los certificados de cliente de mTLS de origen. mTLS de origen de CloudFront admite certificados de cliente de dos orígenes:
+ **Autoridad de certificación privada de AWS:** puede emitir certificados desde una autoridad de certificación privada de AWS mediante plantillas de certificados que incluyan la autenticación de cliente de TLS en el campo Uso ampliado de claves (como la plantilla EndEntityClientAuthCertificate). Después de emitir el certificado de la autoridad de certificación privada de AWS, debe importarla en ACM en la región Este de EE. UU. (Norte de Virginia) (us-east-1). Este enfoque proporciona los beneficios de seguridad de autoridad de certificación privada de AWS y, al mismo tiempo, permite controlar la administración del ciclo de vida de los certificados.
+ **Autoridades de certificación privada de terceros:** también puede emitir certificados desde su infraestructura de autoridad de certificación privada existente e importarlos a ACM. Esto permite mantener los procesos actuales de administración de certificados y, al mismo tiempo, aprovechar las capacidades de mTLS de origen de CloudFront. Los certificados deben incluir la autenticación de cliente de TLS en el campo Uso ampliado de claves y deben estar en formato PEM con el certificado, la clave privada y la cadena de certificados.

**importante**  
Tanto para las autoridades de certificación privadas de AWS como para las de terceros, es responsable de supervisar las fechas de caducidad de los certificados e importar los certificados renovados a ACM antes de que caduquen. La característica de renovación automática de ACM no se aplica a los certificados importados que se utilizan para mTLS de origen.

## Requisitos y especificaciones de certificados
<a name="origin-certificate-requirements"></a>

### Requisitos del certificado de cliente
<a name="origin-ca-cert-format-requirements"></a>
+ **Formato:** formato PEM (Correo con privacidad mejorada)
+ **Componentes:** certificado, clave privada y cadena de certificado
+ **Profundidad máxima de la cadena de certificados:** 3 (certificado de hoja \$1 certificado intermedio \$1 certificado raíz)
+ **Tamaño máximo de la cadena de certificados:** 64 KB
+ **Tamaño del certificado:** no puede superar los 96 KB
+ **Tamaño máximo de clave privada:** 5 KB (restricción de ACM)
+ **Número máximo de ARN de certificados mTLS de origen único que se pueden agregar o modificar por cada llamada a la API de creación o actualización de distribución de CloudFront**: 5
+ **Región:** los certificados se deben almacenar en ACM en la región Este de EE. UU. (Norte de Virginia) (us-east-1)

### Especificaciones de certificados compatibles
<a name="origin-supported-cert-specs"></a>
+ **Tipo de certificado:** X.509v3
+ **Algoritmos de clave pública:**
  + RSA: 2048 bits
  + ECDSA: P-256
+ **Algoritmos de firma:**
  + SHA256, SHA384, SHA512 con RSA
  + SHA256, SHA384, SHA512 con ECDSA
  + SHA256, SHA384, SHA512 con RSASSA-PSS con MGF1
+ **Uso ampliado de claves (obligatorio):** el certificado requiere la extensión del uso ampliado de claves (EKU) configurada como autenticación de cliente de TLS, lo que garantiza que está autorizado para fines de mTLS

### Requisitos del certificado del servidor
<a name="origin-server-certificate-requirements"></a>

Los servidores de origen deben presentar certificados de autoridades de certificación de confianza pública durante el establecimiento de comunicación de TLS mutua. Para obtener detalles completos sobre los requisitos del certificado del servidor de origen, consulte [Requisitos para usar certificados SSL/TLS con CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-cloudfront-to-custom-origin.html#using-https-cloudfront-to-origin-certificate).

### Solicitud o importación de un certificado
<a name="origin-request-import-certificate"></a>

Antes de habilitar mTLS de origen, debe tener un certificado de cliente disponible en ACM.

#### Solicitud e importación de un certificado de la autoridad de certificación privada de AWS
<a name="request-certificate-aws-private-ca"></a>

Requisitos previos:
+ Una autoridad de certificación privada de AWS configurada en la cuenta
+ Permiso para emitir certificados de la autoridad de certificación privada de AWS
+ Permiso para importar certificados en ACM
+ Un ARN de [plantilla de certificado](https://docs.aws.amazon.com/privateca/latest/userguide/UsingTemplates.html) con `Extended key usage:TLS web client authentication` que se adapta al caso de uso
+ Instale OpenSSL, AWS CLI y jq (para analizar JSON).

##### Solicitud de un certificado de PCA e importación en ACM (AWS CLI)
<a name="request-certificate-cli"></a>

1. Configure el ARN de la autoridad de certificación privada en una variable para facilitar su reutilización.

   ```
   PCA_ARN="arn:aws:acm-pca:region:account:certificate-authority/12345678..."
   ```

1. Utilice OpenSSL para generar una clave privada ECDSA P-256 (curva prime256v1) y una solicitud de firma de certificado (CSR), lo que garantiza que el indicador -nodes se utilice para mantener la clave privada sin cifrar, tal como se requiere para la importación de ACM.

   ```
   openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes \
       -keyout private.key \
       -out request.csr \
       -subj "/CN=client.example.com"
   ```

1. Envíe CSR a la autoridad de certificación privada de AWS para emitir un certificado, que devuelva el ARN del certificado recién emitido.

   ```
   CERT_ARN=$(aws acm-pca issue-certificate \
       --certificate-authority-arn "$PCA_ARN" \
       --csr fileb://request.csr \
       --signing-algorithm "SHA256WITHECDSA" \
       --validity Value=365,Type="DAYS" \
       --template-arn arn:aws:acm-pca:::template/EndEntityCertificate/V1 \
       --query 'CertificateArn' --output text)
   ```

1. Recupere el paquete de certificados de AWS PCA mediante el comando get-certificate, que devuelve el certificado de hoja y la cadena. A continuación, utilice jq para separarlos en archivos distintos.

   ```
   # Retrieve the full certificate bundle in JSON format
   aws acm-pca get-certificate \
       --certificate-authority-arn "$PCA_ARN" \
       --certificate-arn "$CERT_ARN" \
       --output json > full_cert.json
   
   # Split into Leaf and Chain
   jq -r '.Certificate' full_cert.json > leaf_cert.pem
   jq -r '.CertificateChain' full_cert.json > cert_chain.pem
   ```

1. Importe la clave privada no cifrada, el certificado de hoja y la cadena de certificados a AWS ACM mediante el protocolo fileb:// para gestionar correctamente los datos de los archivos binarios en la CLI.

   ```
   aws acm import-certificate \
       --certificate fileb://leaf_cert.pem \
       --private-key fileb://private.key \
       --certificate-chain fileb://cert_chain.pem \
       --region us-east-1 \
       --query 'CertificateArn' \
       --output text
   ```

#### Importación de un certificado de una autoridad de certificación de terceros
<a name="import-certificate-third-party-ca"></a>

Requisitos previos:
+ Un certificado, una clave privada no cifrada y la cadena de certificados de la autoridad de certificación en formato PEM
+ El certificado debe incluir el uso ampliado de claves para la autenticación del cliente de TLS
+ Permisos para importar certificados en ACM

##### Importación de un certificado en ACM (AWS CLI)
<a name="import-certificate-cli"></a>

```
aws acm import-certificate \
  --certificate fileb://certificate.pem \
  --private-key fileb://private-key.pem \
  --certificate-chain fileb://certificate-chain.pem \
  --region us-east-1 \
  --query 'CertificateArn' \
  --output text
```

#### Siguientes pasos
<a name="certificate-next-steps"></a>

Tras obtener o importar el certificado de cliente en ACM, puede configurar el servidor de origen para que requiera la autenticación de TLS mutua y habilite mTLS de origen en la distribución de CloudFront. Para obtener instrucciones sobre cómo habilitar mTLS de origen en CloudFront, consulte la siguiente sección “Habilitación de TLS mutua de origen para las distribuciones de CloudFront”.

# Habilitación de TLS mutua de origen para las distribuciones de CloudFront
<a name="origin-enable-mtls-distributions"></a>

Tras obtener un certificado de cliente a través de AWS Certificate Manager y configurar el servidor de origen para requerir TLS mutua, puede habilitar mTLS de origen en la distribución de CloudFront.

## Requisitos previos y requisitos
<a name="origin-mtls-prerequisites-requirements"></a>

Antes de habilitar mTLS de origen en una distribución de CloudFront, asegúrese de que dispone de lo siguiente:
+ Un certificado de cliente almacenado en AWS Certificate Manager en la región Este de EE. UU. (Norte de Virginia) (us-east-1).
+ Servidores de origen configurados para requerir la autenticación de TLS mutua y validar los certificados de los clientes.
+ Servidores de origen que presentan certificados de autoridades de certificación de confianza pública.
+ Permisos para modificar las distribuciones de CloudFront.
+ mTLS de origen solo está disponible en los planes Business, Premium o planes de precio de pago por uso.

**nota**  
mTLS de origen se puede configurar para orígenes personalizados (incluidos los orígenes alojados fuera de AWS) y orígenes de AWS que admiten TLS mutua, como Equilibrador de carga de aplicación y API Gateway.

**importante**  
Las siguientes características de CloudFront no son compatibles con mTLS de origen:  
**Tráfico de gRPC:** el protocolo de gRPC no es compatible con mTLS de origen habilitada.
**Conexiones WebSocket:** el protocolo WebSocket no es compatible con orígenes con mTLS de origen habilitada.
**Orígenes de VPC:** mTLS de origen no se puede usar con orígenes de VPC.
**Desencadenadores de solicitud de origen y respuesta de origen con Lambda@Edge:** las funciones de Lambda@Edge en las posiciones de solicitud de origen y respuesta de origen no son compatibles con mTLS de origen.
**POP incrustados:** mTLS de origen no es compatible con POP incrustados.

## Habilitación de mTLS de origen
<a name="origin-enable-mtls-per-origin"></a>

La configuración por origen permite especificar distintos certificados de cliente para distintos orígenes dentro de la misma distribución. Este enfoque proporciona la máxima flexibilidad cuando los orígenes tienen diferentes requisitos de autenticación.

### Para distribuciones nuevas (consola)
<a name="origin-enable-mtls-new-distributions"></a>

1. Inicie sesión en la Consola de administración de AWS y abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Elija **Crear distribución**.

1. Seleccione un plan de precios: elija **Business** o **Premium** o **Pago por uso** (mTLS de origen no está disponible en el plan gratuito).

1. En la sección de configuración de origen, elija Tipo de origen como otro.

1. En la sección **Configuración de origen**, elija **Personalizar configuración de origen**.

1. Configure el primer origen (nombre de dominio, protocolo, etc.).

1. En la configuración de origen, busque **mTLS**.

1. Active **mTLS**.

1. Para **Certificado de cliente**, seleccione el certificado de AWS Certificate Manager.

1. (Opcional) Agregue orígenes adicionales con sus propias configuraciones de mTLS de origen.

1. Complete el resto de la configuración de distribución y elija **Crear distribución**.

### Para distribuciones existentes (consola)
<a name="origin-enable-mtls-existing-distributions"></a>

1. Inicie sesión en la Consola de administración de AWS y abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. En la lista de distribución, seleccione la distribución que desee modificar. (Nota: Asegúrese de que la distribución esté en un plan de precios **Pro o Premium o Pago por uso**. De lo contrario, debe actualizar el plan de precios antes de habilitar mTLS de origen).

1. Elija la pestaña **Orígenes**.

1. Seleccione el origen que quiere configurar y elija **Editar**.

1. En la configuración de origen, busque **mTLS**.

1. Active **mTLS**.

1. Para **Certificado de cliente**, seleccione el certificado de AWS Certificate Manager. (Nota: Solo se mostrarán los certificados de cliente con la propiedad EKU (Uso ampliado de claves) establecida en “Autenticación de cliente de TLS”)

1. Elija **Guardar cambios**.

1. Repetición de orígenes adicionales según sea necesario

## Uso de la CLI de AWS
<a name="origin-enable-mtls-cli"></a>

Para la configuración por origen, especifique los ajustes de mTLS de origen dentro de la configuración de cada origen:

```
{
  "Origins": {
    "Quantity": 2,
    "Items": [
      {
        "Id": "origin-1",
        "DomainName": "api.example.com",
        "CustomOriginConfig": {
          "HTTPSPort": 443,
          "OriginProtocolPolicy": "https-only"
        },
        "OriginMtlsConfig": {
          "ClientCertificateArn": "arn:aws:acm:us-east-1:123456789012:certificate/cert-1"
        }
      },
      {
        "Id": "origin-2",
        "DomainName": "backend.example.com",
        "CustomOriginConfig": {
          "HTTPSPort": 443,
          "OriginProtocolPolicy": "https-only"
        },
        "OriginMtlsConfig": {
          "CertificateArn": "arn:aws:acm:us-east-1:123456789012:certificate/cert-2"
        }
      }
    ]
  }
}
```

**nota**  
CloudFront no proporcionará el certificado de cliente si el servidor no lo solicita, lo que permitirá que la conexión continúe con normalidad.

## Siguientes pasos
<a name="origin-enable-mtls-next-steps"></a>

Tras habilitar mTLS de origen en la distribución de CloudFront, puede supervisar los eventos de autenticación mediante los registros de acceso de CloudFront.

# Uso de CloudFront Functions con TLS mutua de origen
<a name="origin-mtls-cloudfront-functions"></a>

CloudFront Functions proporciona computación periférica ligera y sin servidor para personalizar la entrega de contenido. Cuando se utiliza TLS mutua de origen con CloudFront Functions, hay comportamientos y limitaciones específicos que hay que tener en cuenta en relación con la selección y la manipulación del origen.

## Operaciones de CloudFront Functions admitidas
<a name="supported-cloudfront-functions-operations"></a>

CloudFront Functions pueden interactuar con orígenes habilitados de mTLS de las siguientes maneras:

### updateRequestOrigin()
<a name="update-request-origin-function"></a>

La función updateRequestOrigin() admite modificaciones limitadas cuando se trabaja con orígenes habilitados de mTLS:
+ **Cambiar entre orígenes de mTLS de origen:** puede actualizar la solicitud para que se dirija a un origen diferente que utilice mTLS de origen, siempre que ambos orígenes utilicen el **mismo certificado de cliente**. Esto permite implementar una lógica de enrutamiento personalizada y, al mismo tiempo, mantener la autenticación de TLS mutua.
+ **Desactivación de mTLS de origen:** puede cambiar de un origen habilitado de mTLS a un origen diferente de mTLS configurando `mTLSConfig: 'off'` en la función. Esto proporciona flexibilidad para desactivar condicionalmente la autenticación de TLS mutua en función de las características de la solicitud.

#### Ejemplo: Cambio entre orígenes de mTLS de origen con el mismo certificado
<a name="example-switching-mtls-origins"></a>

```
function handler(event) {
    var request = event.request;

    // Route to different origin based on request path
    if (request.uri.startsWith('/api/v2')) {
        request.origin = {
            domainName: 'api-v2.example.com',
            customHeaders: {},
            // Both origins must use the same certificate
        };
    }

    return request;
}
```

#### Ejemplo: Deshabilitar condicionalmente mTLS de origen
<a name="example-disabling-mtls"></a>

```
function handler(event) {
    var request = event.request;

    // Disable mTLS for specific paths
    if (request.uri.startsWith('/public')) {
        request.origin = {
            domainName: 'public-origin.example.com',
            customHeaders: {},
            mTLSConfig: 'off'
        };
    }

    return request;
}
```

## Operaciones de CloudFront Functions no admitidas
<a name="unsupported-cloudfront-functions-operations"></a>

Las siguientes operaciones de CloudFront Functions no admiten orígenes habilitados de mTLS en condiciones de disponibilidad general:

### selectRequestOriginById()
<a name="select-request-origin-by-id-function"></a>

La función `selectRequestOriginById()` no puede seleccionar un origen que tenga mTLS de origen habilitada. Si se intenta seleccionar un origen habilitado de mTLS mediante esta función, se producirá un error de validación.

Si su caso de uso requiere una selección de origen dinámica con mTLS de origen, utilice `updateRequestOrigin()` en su lugar, asegurándose de que todos los orígenes de destino utilicen el mismo certificado de cliente.

### createRequestOriginGroup()
<a name="create-request-origin-group-function"></a>

La función `createRequestOriginGroup()` no admite la creación de grupos de origen que incluyan orígenes habilitados de mTLS. Los grupos de origen con orígenes de mTLS de origen no se pueden crear dinámicamente mediante CloudFront Functions.

Si necesita capacidades de conmutación por error de origen con mTLS de origen, configure los grupos de origen directamente en la configuración de distribución de CloudFront, en lugar de crearlos de forma dinámica en funciones.

# Distribución de contenido privado con URL firmadas y cookies firmadas
<a name="PrivateContent"></a>

Muchas empresas que distribuyen contenido a través de Internet desean restringir el acceso a documentos, información corporativa, transmisiones multimedia o contenido destinado a una selección de usuarios; por ejemplo, a los usuarios que hayan pagado una determinada tarifa. Para ofrecer este contenido privado de forma segura a través de CloudFront, puede hacer lo siguiente:
+ Solicite que los usuarios accedan al contenido privado mediante URL firmadas o cookies firmadas especiales de CloudFront. 
+ Solicite que los usuarios accedan al contenido a través de URL de CloudFront, no URL que accedan al contenido directamente en el servidor de origen (por ejemplo, Amazon S3 o un servidor HTTP privado). No es necesario solicitar URL de CloudFront, pero lo recomendamos para impedir que los usuarios eludan las restricciones que especifique en URL firmadas o cookies firmadas.

Para obtener más información, consulte [Restricción del acceso a archivos](private-content-overview.md).

## Distribución de contenido privado
<a name="private-content-task-list"></a>

Para configurar CloudFront para que distribuya contenido privado, realice las siguientes tareas:

1. Solicite a los usuarios que accedan al contenido solo a través de CloudFront (opcional pero recomendado). El método que utilice depende de si utiliza Amazon S3 u orígenes personalizados:
   + **Amazon S3**: consulte [Restricción del acceso a un origen de Amazon S3](private-content-restricting-access-to-s3.md).
   + **Origen personalizado**: consulte [Restricción del acceso a archivos en orígenes personalizados](private-content-overview.md#forward-custom-headers-restrict-access).

   Los orígenes personalizados incluyen Amazon EC2, buckets de Amazon S3 configurados como puntos de enlace del sitio web, Elastic Load Balancing y sus propios servidores web HTTP.

1. Especifique los *grupos de claves de confianza* o los *signatarios de confianza* que desea utilizar para crear URL firmadas o cookies firmadas. Le recomendamos que utilice grupos de claves de confianza. Para obtener más información, consulte [Especificación de los signatarios que pueden crear URL firmadas y cookies firmadas](private-content-trusted-signers.md).

1. Escriba la aplicación para responder a las solicitudes de los usuarios autorizados con URL firmadas o con encabezados `Set-Cookie` que establezcan cookies firmadas. Siga los pasos en uno de los siguientes temas: 
   + [Uso de URL firmadas](private-content-signed-urls.md)
   + [Uso de cookies firmadas](private-content-signed-cookies.md)

   Si no está seguro de qué método utilizar, consulte [Decisión de utilizar URL firmadas o cookies firmadas](private-content-choosing-signed-urls-cookies.md).

**Topics**
+ [Distribución de contenido privado](#private-content-task-list)
+ [Restricción del acceso a archivos](private-content-overview.md)
+ [Especificación de los signatarios que pueden crear URL firmadas y cookies firmadas](private-content-trusted-signers.md)
+ [Decisión de utilizar URL firmadas o cookies firmadas](private-content-choosing-signed-urls-cookies.md)
+ [Uso de URL firmadas](private-content-signed-urls.md)
+ [Uso de cookies firmadas](private-content-signed-cookies.md)
+ [Comandos de Linux y OpenSSL para codificación y cifrado base64](private-content-linux-openssl.md)
+ [Ejemplos de código para la creación de una firma para una URL firmada](PrivateCFSignatureCodeAndExamples.md)

# Restricción del acceso a archivos
<a name="private-content-overview"></a>

Puede controlar el acceso de los usuarios al contenido privado de dos maneras:
+ [Restringir el acceso a los archivos en las cachés de CloudFront](#private-content-overview-edge-caches).
+ Restrinja el acceso a los archivos en su origen de la siguiente manera:
  + [Configure un control de acceso de origen (OAC) para su bucket de Amazon S](private-content-restricting-access-to-s3.md).
  + [Configure encabezados personalizados para un servidor HTTP privado (un origen personalizado)](#forward-custom-headers-restrict-access).

## Restricción del acceso a archivos en las cachés de CloudFront
<a name="private-content-overview-edge-caches"></a>

Puede configurar CloudFront para que solicite que los usuarios accedan a los archivos mediante *URL firmadas* o *cookies firmadas*. Después, deberá desarrollar la aplicación para crear y distribuir URL firmadas para los usuarios autenticados o para enviar encabezados `Set-Cookie` que establecen cookies firmadas para usuarios autenticados. (También puede crear URL firmadas manualmente para ofrecer a unos pocos usuarios acceso largo plazo a un número reducido de archivos). 

Si crea URL o cookies firmadas para controlar el acceso a sus archivos, puede especificar las siguientes restricciones:
+ La fecha y la hora de finalización, a partir de la cual la URL deja de ser válida. 
+ La fecha y la hora a la que la URL pasa a ser válida (opcional).
+ La dirección IP o a un rango de direcciones IP de los equipos desde los que se puede obtener acceso a su contenido. 

A una parte de una URL firmada o una cookie firmada se le aplica el algoritmo hash y se firma con la clave privada de un par de claves públicas-privadas. Cuando alguien utiliza una URL firmada o una cookie firmada para acceder a un archivo, CloudFront compara las partes firmadas y sin firmar de la URL o de la cookie. Si no coinciden, CloudFront no envía el archivo.

Debe utilizar claves privadas RSA 2048 o ECDSA 256 para firmar URL o cookies.

## Restricción del acceso a archivos en buckets de Amazon S3
<a name="private-content-overview-s3"></a>

Si lo desea, puede proteger el contenido de su bucket de Amazon S3 para que los usuarios puedan acceder a él a través de la distribución de CloudFront especificada, pero no puedan acceder directamente mediante las URL de Amazon S3. Esto evita que se eluda CloudFront y se use la URL de Amazon S3 para obtener el contenido cuyo acceso desea restringir. Este paso no es necesario para utilizar URL firmadas, pero recomendamos seguirlo.

Para solicitar que los usuarios accedan al contenido a través de URL de CloudFront, realice las siguientes tareas:
+ Conceder un permiso de *control de acceso de origen* de CloudFront para leer los archivos del bucket de S3.
+ Crear el control de acceso de origen y asociarlo con su distribución de CloudFront.
+ Quite a todos los demás el permiso para usar URL de Amazon S3 para leer los archivos.

Para obtener más información, consulte [Restricción del acceso a un origen de Amazon S3](private-content-restricting-access-to-s3.md).

## Restricción del acceso a archivos en orígenes personalizados
<a name="forward-custom-headers-restrict-access"></a>

Si utiliza un origen personalizado, tiene la opción de configurar encabezados personalizados para restringir el acceso. Para que CloudFront obtenga los archivos de un origen personalizado, debe ser posible el acceso de CloudFront a los archivos mediante una solicitud HTTP estándar (o HTTPS). Sin embargo, mediante el uso de encabezados personalizados, puede restringir aún más el acceso al contenido para que los usuarios puedan acceder al mismo solo a través de CloudFront, no directamente. Este paso no es necesario para utilizar URL firmadas, pero recomendamos seguirlo.

Para solicitar que los usuarios accedan al contenido a través de CloudFront, cambie la siguiente configuración de las distribuciones de CloudFront:

**Encabezados personalizados de origen**  
Configure CloudFront para reenviar encabezados personalizados al origen. Consulte [Configuración de CloudFront para agregar encabezados personalizados a solicitudes de origen](add-origin-custom-headers.md#add-origin-custom-headers-configure).

**Viewer Protocol Policy**  
Configure la distribución para solicitar a los lectores que utilicen HTTPS para acceder a CloudFront. Consulte [Política de protocolo para lectores](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy). 

**Origin Protocol Policy**  
Configure la distribución para solicitar a CloudFront que utilice el mismo protocolo que los lectores para reenviar solicitudes al origen. Consulte [Protocolo (solo orígenes personalizados)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy). 

Después de haber realizado estos cambios, actualice la aplicación en el origen personalizado para aceptar solo solicitudes que incluyan los encabezados personalizados que ha configurado para que CloudFront los envíe.

La combinación de **Viewer Protocol Policy (Política de protocolo del lector)** y **Origin Protocol Policy (Política de protocolo de origen)** garantiza que los encabezados personalizados se cifren en tránsito. Sin embargo, le recomendamos realizar periódicamente las siguientes acciones para rotar los encabezados personalizados que CloudFront reenvía al origen:

1. Actualice la distribución de CloudFront para comenzar a reenviar un nuevo encabezado al origen personalizado.

1. Actualice la aplicación para aceptar el nuevo encabezado a modo de confirmación de que la solicitud proviene de CloudFront.

1. Cuando las solicitudes ya no incluyan el encabezado que ha reemplazado, actualice la aplicación para que ya no acepte el encabezado anterior a modo de confirmación de que la solicitud proviene de CloudFront.

# Especificación de los signatarios que pueden crear URL firmadas y cookies firmadas
<a name="private-content-trusted-signers"></a>

**Topics**
+ [Elección entre grupos de claves de confianza (recomendado) y Cuentas de AWS](#choosing-key-groups-or-AWS-accounts)
+ [Creación de pares de claves para los firmantes](#private-content-creating-cloudfront-key-pairs)
+ [Volver a formatear la clave privada (solo .NET y Java)](#private-content-reformatting-private-key)
+ [Agregación de un firmante a una distribución](#private-content-adding-trusted-signers)
+ [Rotación de pares de claves](#private-content-rotating-key-pairs)

Para crear URL firmadas o cookies firmadas, necesita un *signatario*. Un signatario es un grupo de claves de confianza que se crea en CloudFront o una cuenta de AWS que contiene un par de claves de CloudFront. Le recomendamos que utilice grupos de claves de confianza con URL firmadas y cookies firmadas. Para obtener más información, consulte [Elección entre grupos de claves de confianza (recomendado) y Cuentas de AWS](#choosing-key-groups-or-AWS-accounts).

El signatario tiene dos fines:
+ Tan pronto como agregue el signatario a la distribución, CloudFront comienza a requerir que los lectores utilicen URL firmadas o cookies firmadas para acceder a los archivos.
+ Al crear URL firmadas o cookies firmadas, se utiliza la clave privada del par de claves del signatario para firmar una parte de la URL o la cookie. Cuando alguien solicita un archivo restringido, CloudFront compara la firma de la URL o la cookie con la URL o la cookie sin firmar, para verificar que no se ha manipulado. CloudFront también verifica que la URL o la cookie sean válidas, es decir, por ejemplo, que la fecha y la hora de vencimiento no han pasado todavía.

Cuando se especifica un signatario, también se especifican indirectamente los archivos que requieren URL firmadas o cookies firmadas al agregar el signatario a un comportamiento de la caché. Si la distribución solo dispone de un comportamiento de la caché, los lectores deben utilizar URL o cookies firmadas para acceder a cualquier archivo de la distribución. Si crea varios comportamientos de la caché y agrega signatarios a algunos de ellos pero no a otros, puede exigir que los lectores utilicen URL o cookies firmadas para acceder a algunos archivos y no a otros.

Para especificar los signatarios (las claves privadas) autorizados para crear URL firmadas o cookies firmadas y para agregar los signatarios a la distribución de CloudFront, realice las siguientes tareas:

1. Decida si desea utilizar un grupo de claves de confianza o una Cuenta de AWS como firmante. Recomendamos utilizar un grupo de claves de confianza. Para obtener más información, consulte [Elección entre grupos de claves de confianza (recomendado) y Cuentas de AWS](#choosing-key-groups-or-AWS-accounts).

1. Para el signatario que eligió en el paso 1, cree un par de claves privadas-públicas. Para obtener más información, consulte [Creación de pares de claves para los firmantes](#private-content-creating-cloudfront-key-pairs).

1. Si utiliza .NET o Java para crear URL firmadas o cookies firmadas, vuelva a formatear la clave privada. Para obtener más información, consulte [Volver a formatear la clave privada (solo .NET y Java)](#private-content-reformatting-private-key).

1. En la distribución para la que va a crear URL firmadas o cookies firmadas, especifique el signatario. Para obtener más información, consulte [Agregación de un firmante a una distribución](#private-content-adding-trusted-signers).

## Elección entre grupos de claves de confianza (recomendado) y Cuentas de AWS
<a name="choosing-key-groups-or-AWS-accounts"></a>

Para utilizar URL firmadas o cookies firmadas, necesita un *signatario*. Un firmante es un grupo de claves de confianza que se crea en CloudFront o una Cuenta de AWS que contiene un par de claves de CloudFront. Se recomienda utilizar grupos de claves de confianza, por los siguientes motivos:
+ Con los grupos de claves de CloudFront no es necesario usar el usuario raíz de la cuenta de AWS para administrar las claves públicas de las URL firmadas y las cookies firmadas de CloudFront. Las [prácticas recomendadas de AWS](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root) indican no utilizar el usuario raíz cuando no es necesario.
+ Con los grupos de claves de CloudFront, puede administrar claves públicas, grupos de claves y signatarios de confianza mediante la API de CloudFront. Puede usar la API para automatizar la creación de claves y la rotación de claves. Cuando se utiliza el usuario raíz de AWS, se debe utilizar la Consola de administración de AWS para administrar pares de claves de CloudFront, de modo que no se puede automatizar el proceso.
+ Dado que puede administrar grupos de claves con la API de CloudFront, también puede utilizar las políticas de permisos de AWS Identity and Access Management (IAM) para limitar lo que los distintos usuarios pueden hacer. Por ejemplo, puede permitir a los usuarios cargar claves públicas, pero no eliminarlas. También puede permitir que los usuarios eliminen claves públicas, pero solo cuando se cumplen ciertas condiciones, como el uso de la autenticación multifactor, el envío de la solicitud desde una red determinada o el envío de la solicitud dentro de un intervalo de fecha y hora determinado.
+ Con los grupos de claves de CloudFront, puede asociar un número mayor de claves públicas con la distribución de CloudFront, lo que le concede más flexibilidad en la forma de usar y administrar las claves públicas. De forma predeterminada, puede asociar hasta cuatro grupos de claves con una sola distribución y puede tener hasta cinco claves públicas en un grupo de claves.

  Cuando utiliza el usuario raíz de la cuenta de AWS para administrar pares de claves de CloudFront, solo puede tener hasta dos pares de claves activos de CloudFront por cuenta de AWS.

## Creación de pares de claves para los firmantes
<a name="private-content-creating-cloudfront-key-pairs"></a>

Cada signatario que utilice para crear URL firmadas o cookies firmadas de CloudFront debe tener un par de claves públicas-privadas. El signatario utiliza la clave privada para firmar la URL o las cookies y CloudFront utiliza la clave pública para comprobar la firma.

La forma en que se crea un par de claves depende de si se utiliza un grupo de claves de confianza como el signatario (recomendado) o un par de claves de CloudFront. Para obtener más información, consulte las siguientes secciones. El par de claves que cree debe cumplir los siguientes requisitos:
+ Debe ser un par de claves SSH-2 RSA 2048 o ECDSA 256.
+ Debe encontrarse en formato PEM codificado en Base64.

Para ayudar a proteger las aplicaciones, le recomendamos que cambie los pares de claves periódicamente. Para obtener más información, consulte [Rotación de pares de claves](#private-content-rotating-key-pairs).

### Crear un par de claves para un grupo de claves de confianza (recomendado)
<a name="create-key-pair-and-key-group"></a>

Para crear un par de claves para un grupo de claves de confianza, realice los siguientes pasos:

1. Cree el par de claves públicas-privadas.

1. Cargue la clave pública en CloudFront.

1. Agregue la clave pública a un grupo de claves de CloudFront.

Para obtener más información, consulte los siguientes procedimientos.<a name="private-content-uploading-cloudfront-public-key-procedure"></a>

**Para crear un par de claves**
**nota**  
En los siguientes pasos se utiliza OpenSSL como ejemplo de un método para crear un par de claves. Hay muchas otras formas de crear un par de claves RSA o ECDSA.

1. Ejecute uno de los siguientes comandos de ejemplo:
   + El siguiente comando de ejemplo utiliza OpenSSL para generar un par de claves RSA con una longitud de 2048 bits y guardarlo en el archivo denominado `private_key.pem`.

     ```
     openssl genrsa -out private_key.pem 2048
     ```
   + El siguiente comando de ejemplo utiliza OpenSSL para generar un par de claves ECDSA con la curva `prime256v1` y guárdelo en el archivo denominado `private_key.pem`.

     ```
     openssl ecparam -name prime256v1 -genkey -noout -out privatekey.pem
     ```

1. El archivo resultante contiene tanto la clave pública como la privada. El siguiente comando de ejemplo extrae la clave pública del archivo denominado `private_key.pem`.

   ```
   openssl rsa -pubout -in private_key.pem -out public_key.pem
   ```

   Se carga la clave pública (en el archivo `public_key.pem`) más adelante, en el siguiente procedimiento.

**Para cargar la clave pública en CloudFront**

1. Inicie sesión en Consola de administración de AWS y abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. En el menú de navegación, elija **Claves públicas**.

1. Elija **Crear clave pública**.

1. En la ventana **Crear clave pública**, haga lo siguiente:

   1. En **Key name (Nombre de la clave)**, escriba un nombre para identificar la clave pública.

   1. En **Key value (Valor de clave)**, pegue la clave pública. Si ha seguido los pasos del procedimiento anterior, la clave pública se encuentra en el archivo denominado `public_key.pem`. Para copiar y pegar el contenido de la clave pública, puede:
      + Use el comando **cat** en la línea de comandos de macOS o Linux, así:

        ```
        cat public_key.pem
        ```

        Copie el resultado de ese comando y péguelo en el campo **Key value (Valor de clave)**.
      + Abra el archivo `public_key.pem` con un editor de texto sin formato como el Bloc de notas (en Windows) o TextEdit (en macOS). Copie el contenido del archivo y péguelo en el campo **Key value (Valor de clave)**.

   1. (Opcional) En **Comment (Comentario)**, agregue un comentario para describir la clave pública.

   Cuando haya terminado, elija **Add (Agregar)**.

1. Registre el ID de la clave pública. Lo usará más adelante cuando cree URL firmadas o cookies firmadas, como valor del campo `Key-Pair-Id`.

**Para agregar la clave pública a un grupo de claves**

1. Abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. En el menú de navegación, elija **Grupos de claves**.

1. Elija **Add key group (Agregar grupo de claves)**.

1. En la página **Create key group (Crear grupo de claves)**, haga lo siguiente:

   1. En **Key group name (Nombre del grupo de claves)**, escriba un nombre para identificar el grupo de claves.

   1. (Opcional) En **Comment (Comentario)**, escriba un comentario para describir el grupo de claves.

   1. En **Public keys (Claves públicas)**, seleccione la clave pública que desea agregar al grupo de claves y, a continuación, elija **Add (Agregar)**. Repita este paso para cada clave pública que desee agregar al grupo de claves.

1. Elija **Create key group (Crear grupo de claves)**.

1. Registre el nombre del grupo de claves. Se utiliza más adelante para asociar el grupo de claves con un comportamiento de la caché en una distribución de CloudFront. (En la API de CloudFront, se utiliza el ID del grupo de claves para asociar el grupo de claves con un comportamiento de la caché).

### Creación de un par de claves de CloudFront (no recomendado, se requiere el usuario raíz de la Cuenta de AWS)
<a name="create-key-pair-aws-account"></a>

**importante**  
Se recomienda crear una clave pública para un grupo de claves de confianza en lugar de seguir estos pasos. Para obtener información sobre la forma recomendada de crear claves públicas para URL firmadas y cookies firmadas, consulte [Crear un par de claves para un grupo de claves de confianza (recomendado)](#create-key-pair-and-key-group).

Puede crear un par de claves de CloudFront de las siguientes maneras:
+ Crear un par de claves en la Consola de administración de AWS y descargar la clave privada. Consulte el procedimiento siguiente.
+ Cree un par de claves RSA usando una aplicación como OpenSSL y, a continuación, cargue la clave pública en la Consola de administración de AWS. Para obtener más información acerca de la creación de un par de claves RSA, consulte [Crear un par de claves para un grupo de claves de confianza (recomendado)](#create-key-pair-and-key-group).<a name="private-content-creating-cloudfront-key-pairs-procedure"></a>

**Para crear pares de claves de CloudFront en la Consola de administración de AWS**

1. Inicie sesión en la Consola de administración de AWS con las credenciales del usuario raíz de la cuenta de AWS.
**importante**  
Los usuarios de IAM no pueden crear pares de claves de CloudFront. Debe iniciar sesión con credenciales de usuario raíz para crear pares de claves.

1. Elija el nombre de la cuenta y, a continuación, elija **My Security Credentials (Mis credenciales de seguridad)**.

1. Elija **CloudFront key pairs (Pares de claves de CloudFront)**.

1. Confirme que no tiene más de un par de claves activas. No se puede crear un par de claves si ya dispone de dos pares de claves activos.

1. Elija **Create New Key Pair (Crear un nuevo par de claves)**.
**nota**  
También puede elegir crear su propio par de claves y cargar la clave pública. Los pares de claves de CloudFront admiten claves de 1024, 2048 o 4096 bits.

1. En el cuadro de diálogo **Create Key Pair (Crear par de claves)**, elija **Download Private Key File (Descargar archivo de claves privadas)** y, a continuación, guarde el archivo en el equipo.
**importante**  
Guarde la clave privada del par de claves de CloudFront en un lugar seguro y establezca permisos en el archivo para que solo los administradores que usted decida puedan leerlo. Si alguien obtiene su clave privada, puede generar URL y cookies firmadas válidas y descargar su contenido. No podrá obtener la clave privada de nuevo, por lo que si la pierde o la elimina, deberá crear un nuevo par de claves de CloudFront.

1. Registre el ID de su par de claves. (En la Consola de administración de AWS, esto se denomina **Access Key ID [ID de clave de acceso]**). Lo utilizará al crear URL firmadas o cookies firmadas.

## Volver a formatear la clave privada (solo .NET y Java)
<a name="private-content-reformatting-private-key"></a>

Si utiliza .NET o Java para crear URL firmadas o cookies firmadas, no puede utilizar la clave privada del par de claves en el formato PEM predeterminado para crear la firma. En su lugar, haga lo siguiente:
+ **.NET framework**: convierte la clave privada en el formato XML que utiliza .NET Framework. Hay varias herramientas disponibles.
+ **Java**: convierte la clave privada en formato DER. Una forma de hacerlo es con el siguiente comando de OpenSSL. En el siguiente comando, `private_key.pem` es el nombre del archivo que contiene la clave privada con formato PEM y `private_key.der` es el nombre del archivo que contiene la clave privada con formato DER después de ejecutar el comando.

  ```
  openssl pkcs8 -topk8 -nocrypt -in private_key.pem -inform PEM -out private_key.der -outform DER
  ```

  Para asegurarse de que el codificador funciona correctamente, agregue el recurso JAR de la API de criptografía Java Bouncy Castle a su proyecto y, a continuación, agregue el proveedor Bouncy Castle.

## Agregación de un firmante a una distribución
<a name="private-content-adding-trusted-signers"></a>

Un signatario es el grupo de claves de confianza (recomendado) o el par de claves de CloudFront que puede crear URL firmadas y cookies firmadas para una distribución. Para utilizar URL firmadas o cookies firmadas con una distribución de CloudFront, debe especificar un signatario.

Los signatarios se asocian con comportamientos de la caché. Esto le permite exigir URL firmadas o cookies firmadas para algunos archivos y no para otros dentro de la misma distribución. Una distribución requiere URL o cookies firmadas solo para los archivos asociados con los comportamientos de la caché correspondientes.

Del mismo modo, un signatario solo puede firmar URL o cookies para archivos asociados con los comportamientos de la caché correspondientes. Por ejemplo, si tiene un signatario para un comportamiento de la caché y un signatario diferente para un comportamiento de la caché diferente, ninguno de los dos signatarios puede crear URL o cookies firmadas para los archivos asociados con el otro comportamiento de la caché.

**importante**  
Antes de agregar un signatario a la distribución, haga lo siguiente:  
Defina cuidadosamente los patrones de ruta y la secuencia de los comportamientos de la caché para no conceder a los usuarios acceso no deseado al contenido o impedir que accedan al contenido que desea que esté disponible para todos.  
Supongamos que una solicitud coincide con el patrón de ruta de dos comportamientos de la caché. El primer comportamiento de la caché no requiere URL firmadas ni cookies firmadas y el segundo comportamiento de la caché sí. Los usuarios podrán acceder a los archivos sin usar URL ni cookies firmadas porque CloudFront procesa el comportamiento de la caché que está asociado con la primera coincidencia.  
Para obtener más información acerca de patones de rutas, consulte [Patrón de ruta](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
Para una distribución que ya utiliza para distribuir contenido, asegúrese de que está listo para comenzar a generar URL firmadas y cookies firmadas antes de agregar un signatario. Cuando se agrega un signatario, CloudFront rechaza las solicitudes que no incluyen una URL firmada o una cookie firmada válidas.

Puede agregar signatarios a la distribución utilizando la consola de CloudFront o la API de CloudFront.

------
#### [ Console ]

En los siguientes pasos se muestra cómo agregar un grupo de claves de confianza como signatario. También puede agregar una Cuenta de AWS como firmante de confianza, pero no es recomendable hacerlo.<a name="private-content-adding-trusted-signers-console-procedure"></a>

**Para agregar un signatario a una distribución mediante la consola**

1. Registre el ID del grupo de claves del grupo de claves que desea utilizar como signatario de confianza. Para obtener más información, consulte [Crear un par de claves para un grupo de claves de confianza (recomendado)](#create-key-pair-and-key-group).

1. Abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Elija la distribución cuyos archivos desea proteger con URL firmadas o cookies firmadas.
**nota**  
Para agregar un signatario a una distribución nueva, se especifica la misma configuración que se describe en el paso 6 al crear la distribución.

1. Elija la pestaña **Behaviors (Comportamientos)**.

1. Seleccione el comportamiento de caché cuyo patrón de ruta coincida con los archivos que desea proteger con URL firmadas o cookies firmadas y, a continuación, elija **Edit (Editar)**.

1. En la página **Edit Behavior (Editar comportamiento)**, haga lo siguiente:

   1. En **Restrict Viewer Access (Use Signed URLs or Signed Cookies) (Restringir el acceso a lectores [mediante URL o cookies firmadas])**, elija **Yes (Sí)**.

   1. En **Trusted Key Groups or Trusted Signer (Grupos de claves de confianza o signatario de confianza)**, elija **Trusted Key Groups (Grupos de claves de confianza)**.

   1. En **Trusted Key Groups (Grupos de claves de confianza)**, elija el grupo de claves que desea agregar y, a continuación, elija **Add (Agregar)**. Repita el procedimiento si desea agregar más de un grupo de claves.

1. Elija **Yes, Edit (Sí, Editar)** para actualizar el comportamiento de la caché.

------
#### [ API ]

Puede usar la API de CloudFront para agregar un grupo de claves de confianza como signatario. Puede agregar un signatario a una distribución existente o a una distribución nueva. En cualquier caso, deberá especificar los valores en el elemento `TrustedKeyGroups`.

También puede agregar una Cuenta de AWS como firmante de confianza, pero no es recomendable hacerlo.

Consulte los siguientes temas en la *Referencia de la API de Amazon CloudFront*:
+ **Actualizar una distribución existente**: [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)
+ **Crear una nueva distribución**: [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html)

------

## Rotación de pares de claves
<a name="private-content-rotating-key-pairs"></a>

Se recomienda rotar periódicamente (cambiar) los pares de claves para las URL firmadas y las cookies firmadas. Para rotar pares de claves que utiliza para crear URL firmadas o cookies firmadas sin invalidar las URL o cookies que no hayan vencido todavía, realice las siguientes tareas:

1. Cree un nuevo par de claves y agregue la clave pública a un grupo de claves. Para obtener más información, consulte [Crear un par de claves para un grupo de claves de confianza (recomendado)](#create-key-pair-and-key-group).

1. Si ha creado un nuevo grupo de claves en el paso anterior, [agregue el grupo de claves a la distribución como signatario](#private-content-adding-trusted-signers).
**importante**  
No elimine ninguna clave pública existente del grupo de claves ni ningún grupo de claves de la distribución todavía. Solo agregue los nuevos.

1. Actualice la aplicación para crear firmas con la clave privada del nuevo par de claves. Confirme que las URL firmadas o las cookies firmadas con las nuevas claves privadas funcionan.

1. Espere hasta que pase la fecha de vencimiento de las URL o las cookies firmadas con la clave privada anterior. A continuación, elimine la clave pública anterior del grupo de claves. Si ha creado un nuevo grupo de claves en el paso 2, elimine el grupo de claves anterior de la distribución.

# Decisión de utilizar URL firmadas o cookies firmadas
<a name="private-content-choosing-signed-urls-cookies"></a>

Las URL firmadas y las cookies firmadas de CloudFront proporcionan la misma funcionalidad básica: le permiten controlar quién puede obtener acceso al contenido. Si desea distribuir contenido privado a través de CloudFront e intenta decidir si utilizar URL firmadas o cookies firmadas, tenga en cuenta lo siguiente.

Utilice URL firmadas en los casos siguientes:
+ Si desea restringir el acceso a archivos individuales, por ejemplo, una descarga de instalación para su aplicación.
+ Si sus usuarios utilizan un cliente (por ejemplo, un cliente HTTP personalizado) que no admite cookies.

Utilice cookies firmadas en los casos siguientes:
+ Si desea proporcionar acceso a varios archivos restringidos (por ejemplo, a todos los archivos de un vídeo en formato HLS o a todos los archivos del área de suscriptores de un sitio web).
+ Si no quiere cambiar las URL actuales.

Si en la actualidad no utiliza URL firmadas y si sus URL (sin firmar) contienen cualquiera de los siguientes parámetros de cadenas de consulta, no puede utilizar cookies firmadas ni URL firmadas:
+ `Expires`
+ `Policy`
+ `Signature`
+ `Key-Pair-Id`

CloudFront asume que las URL que contienen cualquiera de los parámetros de cadenas de consulta son URL firmadas y, por lo tanto, no examina las cookies firmadas.

## Uso de URL firmadas y cookies firmadas
<a name="private-content-using-signed-urls-and-cookies"></a>

Las URL firmadas tienen prioridad sobre las cookies firmadas. Si utiliza URL firmadas y cookies firmadas para controlar el acceso a los mismos archivos y un lector utiliza una URL firmada para solicitar un archivo, CloudFront determina si debe devolver el objeto al lector basándose únicamente en la URL firmada.

# Uso de URL firmadas
<a name="private-content-signed-urls"></a>

Una URL firmada incluye información adicional, por ejemplo, una fecha y hora de vencimiento, lo que permite un mayor control sobre el acceso a su contenido. Esta información adicional aparece en una instrucción de política basada en una política predefinida o personalizada. Las diferencias entre las políticas personalizadas y las predefinidas se explican en las próximas dos secciones.

**nota**  
Puede crear algunas URL firmadas con políticas predefinidas y crear otras con políticas personalizadas para la misma distribución.

**Topics**
+ [Decisión de utilizar políticas predefinidas o personalizadas para URL firmadas](#private-content-choosing-canned-custom-policy)
+ [Cómo funcionan las URL firmadas](#private-content-how-signed-urls-work)
+ [Decisión del tiempo de validez de las URL firmadas](#private-content-overview-choosing-duration)
+ [Cuándo comprueba CloudFront la fecha y hora de vencimiento de una URL firmada](#private-content-check-expiration)
+ [Código de ejemplo y herramientas de terceros](#private-content-overview-sample-code)
+ [Creación de una URL firmada mediante una política predefinida](private-content-creating-signed-url-canned-policy.md)
+ [Creación de una URL firmada mediante una política personalizada](private-content-creating-signed-url-custom-policy.md)

## Decisión de utilizar políticas predefinidas o personalizadas para URL firmadas
<a name="private-content-choosing-canned-custom-policy"></a>

Al crear una URL firmada, se escribe una instrucción de política en formato JSON que especifica las restricciones en la URL firmada, por ejemplo, el tiempo de validez de la URL. Puede utilizar una política predefinida o personalizada. A continuación, se presenta una comparación entre las políticas predefinidas y las personalizadas:


****  

| Descripción | Política predefinida | Política personalizada | 
| --- | --- | --- | 
| Puede reutilizar la instrucción de la política con varios archivos. Para reutilizar la instrucción de política, debe utilizar caracteres comodín en el objeto `Resource`. Para obtener más información, consulte [Valores que se especifican en la instrucción de política de una URL firmada que utiliza una política personalizada](private-content-creating-signed-url-custom-policy.md#private-content-custom-policy-statement-values)).  | No | Sí | 
| Puede especificar la fecha y la hora a la que los usuarios pueden empezar a obtener acceso a su contenido. | No | Sí (opcional) | 
| Puede especificar la fecha y la hora a la que los usuarios dejan de obtener acceso a su contenido. | Sí | Sí | 
| Puede especificar la dirección IP o a un rango de direcciones IP de los usuarios que pueden obtener acceso a su contenido. | No | Sí (opcional) | 
| La URL firmada incluye una versión de la política con codificación de tipo base64, lo que resulta en una URL más larga. | No | Sí | 

Para obtener información acerca de cómo crear URL firmadas mediante una política *predefinida*, consulte [Creación de una URL firmada mediante una política predefinida](private-content-creating-signed-url-canned-policy.md).

Para obtener información acerca de cómo crear URL firmadas mediante una política *personalizada*, consulte [Creación de una URL firmada mediante una política personalizada](private-content-creating-signed-url-custom-policy.md).

## Cómo funcionan las URL firmadas
<a name="private-content-how-signed-urls-work"></a>

A continuación, se muestra información general de cómo se configura CloudFront y Amazon S3 para URL firmadas y cómo responde CloudFront cuando un usuario utiliza una URL firmada para solicitar un archivo. 

1. En la distribución de CloudFront, especifique uno o más grupos de claves de confianza, que contienen las claves públicas que CloudFront puede utilizar para comprobar la firma de URL. Se utilizan las claves privadas correspondientes para firmar las URL.

   CloudFront admite direcciones URL firmadas con firmas de claves RSA 2048 y ECDSA 256.

   Para obtener más información, consulte [Especificación de los signatarios que pueden crear URL firmadas y cookies firmadas](private-content-trusted-signers.md).

1. Desarrolle la aplicación para determinar si un usuario debe tener acceso al contenido y crear URL firmadas para los archivos o partes de la aplicación a las que desea restringir el acceso. Para obtener más información, consulte los siguientes temas:
   + [Creación de una URL firmada mediante una política predefinida](private-content-creating-signed-url-canned-policy.md)
   + [Creación de una URL firmada mediante una política personalizada](private-content-creating-signed-url-custom-policy.md)

1. Un usuario solicita un archivo que va a requerir URL firmadas.

1. La aplicación verifica si el usuario tiene derecho para obtener acceso al archivo: si ha iniciado sesión, si ha pagado por obtener acceso al contenido o si ha cumplido algún otro requisito para obtener acceso.

1. Su aplicación crea una URL firmada y la devuelve el usuario.

1. Las URL firmadas permiten al usuario descargar o transmitir el contenido.

   Este paso es automático; el usuario normalmente no tiene que hacer nada más para obtener acceso al contenido. Por ejemplo, si un usuario accede a su contenido desde un navegador web, la aplicación devuelve la URL firmada al navegador. El navegador utiliza inmediatamente la URL firmada para acceder al archivo de la caché de borde de CloudFront sin necesidad de que el usuario intervenga.

1. CloudFront utiliza la clave pública para validar la firma y confirmar que la URL no se ha manipulado. Si la firma no es válida, se rechaza la solicitud. 

   Si la firma es válida, CloudFront examina la instrucción de la política en la URL (o crea una si utiliza una política predefinida) para confirmar que la solicitud sigue siendo válida. Por ejemplo, si especifica una fecha y hora de inicio y fin de la URL, CloudFront confirma que el usuario intenta acceder al contenido durante el periodo que usted ha decidido permitir dicho acceso. 

   Si la solicitud cumple los requisitos de la instrucción de política, CloudFront realiza las operaciones estándar: determina si el archivo ya está en la caché de borde, reenvía la solicitud al origen en caso necesario y devuelve el archivo al usuario.

**nota**  
Si una URL sin firmar contiene parámetros de cadena de consulta, asegúrese de incluirlos en la parte de la dirección URL que firma. Si agrega una cadena de consulta a una URL firmada después de firmarla, la URL devuelve un estado HTTP 403.

## Decisión del tiempo de validez de las URL firmadas
<a name="private-content-overview-choosing-duration"></a>

Puede distribuir contenido privado mediante una URL firmada cuyo periodo de validez sea corto, incluso de unos pocos minutos. Las URL firmadas con un tiempo de validez tan corto son adecuadas para distribuir contenido sobre la marcha a un usuario con una finalidad específica, como la distribución de películas de alquiler o descargas de música bajo demanda para clientes. Si el periodo de validez de las URL firmadas es corto, es recomendable generarlas automáticamente con una aplicación que puede desarrollar. Cuando el usuario comienza a descargar un archivo o a reproducir un archivo multimedia, CloudFront compara la fecha y hora de vencimiento de la URL con el momento actual para determinar si la URL todavía es válida.

También puede distribuir contenido privado mediante una URL firmada con un periodo de validez más largo, de incluso años. Las URL válidas durante periodos largos resultan útiles para distribuir contenido privado a usuarios conocidos, como, por ejemplo, la distribución de un plan de negocio a inversores o la distribución de materiales de formación a los empleados. Puede desarrollar una aplicación para generar estas URL firmadas a largo plazo para usted.

## Cuándo comprueba CloudFront la fecha y hora de vencimiento de una URL firmada
<a name="private-content-check-expiration"></a>

CloudFront comprueba la fecha y hora de vencimiento de una URL firmada al realizarse la solicitud HTTP. Si un cliente comienza a descargar un archivo grande inmediatamente antes de la fecha de vencimiento, la descarga se realizará por completo incluso si se sobrepasa la hora de vencimiento durante la descarga. Si la conexión TCP se interrumpe y el cliente intenta reiniciar la descarga después de la fecha de vencimiento, la descarga fallará.

Si un cliente utiliza rangos GET para obtener un archivo en partes más pequeñas, cualquier solicitud GET que se produzca después de la fecha de vencimiento no se procesará. Para obtener más información acerca de Range GET, consulte [Cómo CloudFront procesa las solicitudes parciales de un objeto (rango GET)](RangeGETs.md).

## Código de ejemplo y herramientas de terceros
<a name="private-content-overview-sample-code"></a>

Para ver un código de ejemplo que crea la parte de las URL firmadas y a la que se le haya aplicado una función hash, consulte los siguientes temas:
+ [Crear una firma de URL con Perl](CreateURLPerl.md)
+ [Crear una firma de URL con PHP](CreateURL_PHP.md)
+ [Crear una firma de URL mediante C\$1 y .NET Framework](CreateSignatureInCSharp.md)
+ [Crear una firma de URL con Java](CFPrivateDistJavaDevelopment.md)

# Creación de una URL firmada mediante una política predefinida
<a name="private-content-creating-signed-url-canned-policy"></a>

Para crear una URL firmada mediante una política predefinida, complete los pasos siguientes.<a name="private-content-creating-signed-url-canned-policy-procedure"></a>

**Para crear una URL firmada mediante una política predefinida**

1. Si utiliza. NET o Java para crear URL firmadas y no ha reformateado la clave privada del par de claves del formato .pem predeterminado a un formato compatible con .NET o con Java, hágalo ahora. Para obtener más información, consulte [Volver a formatear la clave privada (solo .NET y Java)](private-content-trusted-signers.md#private-content-reformatting-private-key).

1. Concatene los siguientes valores. Puede utilizar el formato de este ejemplo de URL firmada. 

   ```
   https://d111111abcdef8.cloudfront.net/image.jpg?color=red&size=medium&Expires=1767290400&Signature=nitfHRCrtziwO2HwPfWw~yYDhUF5EwRunQA-j19DzZrvDh6hQ73lDx~-ar3UocvvRQVw6EkC~GdpGQyyOSKQim-TxAnW7d8F5Kkai9HVx0FIu-5jcQb0UEmatEXAMPLE3ReXySpLSMj0yCd3ZAB4UcBCAqEijkytL6f3fVYNGQI6&Key-Pair-Id=K2JCJMDEHXQW5F
   ```

   Elimine todos los espacios vacíos (incluidos tabuladores y caracteres de línea nueva). Es posible que tenga que incluir caracteres de escape en la cadena del código de la aplicación. Todos los valores tienen un tipo de `String`.  
**1. *URL base del archivo***  
La URL base es la URL de CloudFront que utilizaría para acceder al archivo si no utilizara las URL firmadas, incluidos los parámetros de la cadena de consulta propios, si los hay. En el ejemplo anterior, la URL base es `https://d111111abcdef8.cloudfront.net/image.jpg`. Para obtener más información acerca del formato de las URL para distribuciones, consulte [Personalización del formato de URL para archivos en CloudFront](LinkFormat.md).  
   + La siguiente URL de CloudFront es para un archivo de imagen en una distribución (utilizando el nombre de dominio de CloudFront). `image.jpg` está en un directorio `images`. La ruta hacia el archivo de la URL debe coincidir con la ruta hacia el archivo del servidor HTTP o del bucket de Amazon S3.

     `https://d111111abcdef8.cloudfront.net/images/image.jpg`
   + La siguiente URL de CloudFront incluye una cadena de consulta:

     `https://d111111abcdef8.cloudfront.net/images/image.jpg?size=large`
   + Las siguientes URL de CloudFront corresponden a archivos de imagen de una distribución. Ambas usan un nombre de dominio alternativo. La segunda incluye una cadena de consulta:

     `https://www.example.com/images/image.jpg`

     `https://www.example.com/images/image.jpg?color=red`
   + La siguiente URL de CloudFront corresponde a un archivo de imagen de una distribución que utiliza un nombre de dominio alternativo y el protocolo HTTPS:

     `https://www.example.com/images/image.jpg`  
** 2. `?`**  
`?` indica que los parámetros de consulta siguen la URL base. Incluya el parámetro `?` par si no especifica ningún otro parámetro de consulta.  
Puede especificar los siguientes parámetros de consulta en cualquier orden.  
**3. *Sus parámetros de cadena de consulta, de haberlos*`&`**  
(Opcional) Puede introducir sus propios parámetros de la cadena de consulta. Para ello, agregue un signo y (`&`) entre cada uno de ellos; por ejemplo, `color=red&size=medium`. Puede especificar los parámetros de consulta en cualquier orden dentro de la URL.  
Los parámetros de la cadena de consulta no podrán llamarse `Expires`, `Signature` ni `Key-Pair-Id`.  
** 4. `Expires=`*fecha y hora en formato de tiempo Unix (en segundos), en hora universal coordinada (UTC)***  
La fecha y la hora en las que desea que la URL deje de permitir el acceso al archivo.  
Especifique la fecha y la hora de vencimiento en formato de tiempo Unix (en segundos) y hora universal coordinada (UTC). Por ejemplo, 1 de enero de 2026 a las 10:00 UTC pasa a ser `1767290400` en formato de tiempo Unix, como se muestra en el ejemplo al principio de este tema.   
Para utilizar el tiempo de época, especifique un número entero de 64 bits para una fecha que no sea posterior a `9223372036854775807` (viernes, 11 de abril de 2262 a las 23:47:16.854 UTC).  
  
Para obtener información acerca de UTC, consulte [RFC 3339, fecha y hora en Internet: marcas temporales](https://tools.ietf.org/html/rfc3339).  
** 5. `&Signature=`*versión firmada y a la que se le ha aplicado una función hash de la instrucción de política***  
Una versión firmada, a la que se le ha aplicado una función hash y codificada en base64 de la instrucción de política JSON. Para obtener más información, consulte [Creación de una firma para una URL firmada que utiliza una política predefinida](#private-content-canned-policy-creating-signature).  
** 6. `&Key-Pair-Id=`*ID de clave pública para la clave pública de CloudFront cuya clave privada correspondiente va a utilizar para generar la firma***  
El ID de una clave pública de CloudFront, por ejemplo, `K2JCJMDEHXQW5F`. El ID de clave pública indica a CloudFront qué clave pública usar para validar la URL firmada. CloudFront compara la información de la firma con la información de la instrucción de política para comprobar que la URL no se ha manipulado.  
Esta clave pública debe pertenecer a un grupo de claves que tiene un signatario de confianza en la distribución. Para obtener más información, consulte [Especificación de los signatarios que pueden crear URL firmadas y cookies firmadas](private-content-trusted-signers.md).

## Creación de una firma para una URL firmada que utiliza una política predefinida
<a name="private-content-canned-policy-creating-signature"></a>

Para crear la firma para una URL firmada que utilice una política predefinida, realice los procedimientos indicados a continuación.

**Topics**
+ [Creación de una instrucción de política para una URL firmada que utiliza una política predefinida](#private-content-canned-policy-creating-policy-statement)
+ [Creación de una firma para una URL firmada que utiliza una política predefinida](#private-content-canned-policy-signing-policy-statement)

### Creación de una instrucción de política para una URL firmada que utiliza una política predefinida
<a name="private-content-canned-policy-creating-policy-statement"></a>

Al crear una URL firmada mediante una política predefinida, el parámetro `Signature` es una versión firmada y a la que se le ha aplicado una función hash de una instrucción de política. En el caso de URL firmadas que utilizan una política predefinida, la instrucción de política no se incluye en la URL, a diferencia de las URL firmadas que utilizan una política personalizada. Para crear la instrucción de política, siga el procedimiento que se indica a continuación.<a name="private-content-canned-policy-creating-policy-statement-procedure"></a>

**Para crear una instrucción de política para una URL firmada que use una política predefinida**

1. Cree la instrucción de política utilizando el siguiente formato JSON y codificación de caracteres UTF-8. Incluya toda la puntuación y otros valores literalmente, tal como se especifica. Para obtener más información acerca de los parámetros `Resource` y `DateLessThan`, consulte [Valores que se especifican en la instrucción de política de una URL firmada que utiliza una política predefinida](#private-content-canned-policy-statement-values).

   ```
   {
       "Statement": [
           {
               "Resource": "base URL or stream name",
               "Condition": {
                   "DateLessThan": {
                       "AWS:EpochTime": ending date and time in Unix time format and UTC
                   }
               }
           }
       ]
   }
   ```

1. Elimine todos los espacios vacíos (incluidos tabuladores y caracteres de línea nueva) de la instrucción de la política. Es posible que tenga que incluir caracteres de escape en la cadena del código de la aplicación.

#### Valores que se especifican en la instrucción de política de una URL firmada que utiliza una política predefinida
<a name="private-content-canned-policy-statement-values"></a>

Al crear una instrucción de política para una política predefinida, debe especificar los siguientes valores.

**Recurso**  
Puede especificar solo un valor en `Resource`.
La URL base incluye las cadenas de consulta, de haberlas, pero excluye los parámetros de CloudFront `Expires`, `Signature` y `Key-Pair-Id`, por ejemplo:  
`https://d111111abcdef8.cloudfront.net/images/horizon.jpg?size=large&license=yes`  
Tenga en cuenta lo siguiente:  
+ **Protocol (Protocolo)**: el valor debe comenzar con `http://` o `https://`.
+ **Query string parameters (Parámetros de cadena de consulta)**: si no tiene parámetros de cadena de consulta, omita el signo de interrogación.
+ **Alternate domain names (Nombres de dominio alternativos)**: si especifica un nombre de dominio alternativo (CNAME) en la URL, debe especificarlo al hacer referencia al archivo en la página web o aplicación. No especifique la URL de Amazon S3 del objeto.

**DateLessThan**  
La fecha y hora de vencimiento de la URL en formato de tiempo Unix (en segundos) y hora universal coordinada (UTC). Por ejemplo, 1 de enero de 2026 a las 10:00 UTC pasa a ser 1767290400 en formato de tiempo Unix.  
Este valor debe coincidir con el valor del parámetro de cadena de consulta `Expires` de la URL firmada. No incluya el valor entre comillas.  
Para obtener más información, consulte [Cuándo comprueba CloudFront la fecha y hora de vencimiento de una URL firmada](private-content-signed-urls.md#private-content-check-expiration).

#### Ejemplo de instrucción de política para una URL firmada que utiliza una política predefinida
<a name="private-content-canned-policy-creating-policy-statement-example"></a>

Cuando se utiliza la siguiente instrucción de política de ejemplo en una URL firmada, un usuario puede acceder al archivo `https://d111111abcdef8.cloudfront.net/horizon.jpg` hasta el 1 de enero de 2026 a las 10:00 UTC:

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/horizon.jpg?size=large&license=yes",
            "Condition": {
                "DateLessThan": {
                    "AWS:EpochTime": 1767290400
                }
            }
        }
    ]
}
```

### Creación de una firma para una URL firmada que utiliza una política predefinida
<a name="private-content-canned-policy-signing-policy-statement"></a>

Para crear el valor del parámetro `Signature` en una URL firmada, aplique una función hash y firme la instrucción de política que ha creado en [Creación de una instrucción de política para una URL firmada que utiliza una política predefinida](#private-content-canned-policy-creating-policy-statement).

Para obtener más información y ejemplos de cómo resumir, aplicar una función hash y codificar la instrucción de política, consulte:
+ [Comandos de Linux y OpenSSL para codificación y cifrado base64](private-content-linux-openssl.md)
+ [Ejemplos de código para la creación de una firma para una URL firmada](PrivateCFSignatureCodeAndExamples.md)<a name="private-content-canned-policy-creating-signature-download-procedure"></a>

**Opción 1: para crear una firma mediante una política predefinida**

1. Use la función hash SHA-1 y la clave privada RSA o ECDSA generada para codificar y firmar la instrucción de política creada en el procedimiento [Para crear una instrucción de política para una URL firmada que use una política predefinida](#private-content-canned-policy-creating-policy-statement-procedure). Utilice la versión de la instrucción de política que ya no incluye espacios vacíos.

   Para la clave privada requerida por la función hash, utilice una clave privada cuya clave pública esté en un grupo de claves de confianza activo para la distribución.
**nota**  
El método que utilice para resumir y aplicar una función hash la instrucción de política depende de su lenguaje de programación y plataforma. Para ver código de muestra, consulte [Ejemplos de código para la creación de una firma para una URL firmada](PrivateCFSignatureCodeAndExamples.md).

1. Elimine los espacios vacíos (incluidos tabuladores y caracteres de línea nueva) de la cadena a la que se le ha aplicado una función hash y firmada.

1. Codifique la cadena con codificación base64 de MIME. Para obtener más información, consulte la [Section 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) de *RFC 2045, MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies*.

1. Sustituya caracteres no válidos en una cadena de consulta de URL por caracteres válidos. En la siguiente tabla se muestran los caracteres válidos y no válidos.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonCloudFront/latest/DeveloperGuide/private-content-creating-signed-url-canned-policy.html)

1. Añada el valor resultante a la URL firmada después de `&Signature=` y vuelva a [Para crear una URL firmada mediante una política predefinida](#private-content-creating-signed-url-canned-policy-procedure) para terminar de encadenar las partes de la URL firmada.

# Creación de una URL firmada mediante una política personalizada
<a name="private-content-creating-signed-url-custom-policy"></a>

Para crear una URL firmada mediante una política personalizada, realice el procedimiento que se indica a continuación.<a name="private-content-creating-signed-url-custom-policy-procedure"></a>

**Para crear una URL firmada mediante una política personalizada**

1. Si utiliza. NET o Java para crear URL firmadas y no ha reformateado la clave privada del par de claves del formato .pem predeterminado a un formato compatible con .NET o con Java, hágalo ahora. Para obtener más información, consulte [Volver a formatear la clave privada (solo .NET y Java)](private-content-trusted-signers.md#private-content-reformatting-private-key).

1. Concatene los siguientes valores. Puede utilizar el formato de este ejemplo de URL firmada.

   

   ```
   https://d111111abcdef8.cloudfront.net/image.jpg?color=red&size=medium&Policy=eyANCiAgICEXAMPLEW1lbnQiOiBbeyANCiAgICAgICJSZXNvdXJjZSI6Imh0dHA6Ly9kemJlc3FtN3VuMW0wLmNsb3VkZnJvbnQubmV0L2RlbW8ucGhwIiwgDQogICAgICAiQ29uZGl0aW9uIjp7IA0KICAgICAgICAgIklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIyMDcuMTcxLjE4MC4xMDEvMzIifSwNCiAgICAgICAgICJEYXRlR3JlYXRlclRoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTI5Njg2MDE3Nn0sDQogICAgICAgICAiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjEyOTY4NjAyMjZ9DQogICAgICB9IA0KICAgfV0gDQp9DQo&Signature=nitfHRCrtziwO2HwPfWw~yYDhUF5EwRunQA-j19DzZrvDh6hQ73lDx~-ar3UocvvRQVw6EkC~GdpGQyyOSKQim-TxAnW7d8F5Kkai9HVx0FIu-5jcQb0UEmatEXAMPLE3ReXySpLSMj0yCd3ZAB4UcBCAqEijkytL6f3fVYNGQI6&Key-Pair-Id=K2JCJMDEHXQW5F
   ```

   Elimine todos los espacios vacíos (incluidos tabuladores y caracteres de línea nueva). Es posible que tenga que incluir caracteres de escape en la cadena del código de la aplicación. Todos los valores tienen un tipo de `String`.  
**1. *URL base del archivo***  
La URL base es la URL de CloudFront que utilizaría para acceder al archivo si no utilizara las URL firmadas, incluidos los parámetros de la cadena de consulta propios, si los hay. En el ejemplo anterior, la URL base es `https://d111111abcdef8.cloudfront.net/image.jpg`. Para obtener más información acerca del formato de las URL para distribuciones, consulte [Personalización del formato de URL para archivos en CloudFront](LinkFormat.md).  
Los siguientes ejemplos muestran valores que especifica para distribuciones.  
   + La siguiente URL de CloudFront es para un archivo de imagen en una distribución (utilizando el nombre de dominio de CloudFront). `image.jpg` está en un directorio `images`. La ruta hacia el archivo de la URL debe coincidir con la ruta hacia el archivo del servidor HTTP o del bucket de Amazon S3.

     `https://d111111abcdef8.cloudfront.net/images/image.jpg`
   + La siguiente URL de CloudFront incluye una cadena de consulta:

     `https://d111111abcdef8.cloudfront.net/images/image.jpg?size=large`
   + Las siguientes URL de CloudFront corresponden a archivos de imagen de una distribución. Ambas utilizan un nombre de dominio alternativo; la segunda incluye una cadena de consulta:

     `https://www.example.com/images/image.jpg`

     `https://www.example.com/images/image.jpg?color=red`
   + La siguiente URL de CloudFront corresponde a un archivo de imagen de una distribución que utiliza un nombre de dominio alternativo y el protocolo HTTPS:

     `https://www.example.com/images/image.jpg`  
**2. `?`**  
`?` indica que los parámetros de la cadena de consulta siguen a la URL base. Incluya el parámetro `?` par si no especifica ningún otro parámetro de consulta.  
Puede especificar los siguientes parámetros de consulta en cualquier orden.  
**3. *Sus parámetros de cadena de consulta, de haberlos*`&`**  
(Opcional) Puede introducir sus propios parámetros de la cadena de consulta. Para ello, agregue un signo y (&) entre cada uno de ellos; por ejemplo, `color=red&size=medium`. Puede especificar los parámetros de consulta en cualquier orden dentro de la URL.  
Los parámetros de la cadena de consulta no podrán llamarse `Policy`, `Signature` ni `Key-Pair-Id`.
Si añade sus propios parámetros, incluya un `&` después de cada uno, incluso después del último.   
**4. `Policy=`*versión codificada con base64 de la instrucción de política***  
La instrucción de política en formato JSON después de haber eliminado los espacios vacíos y, a continuación, codificada con base64. Para obtener más información, consulte [Creación de una instrucción de política para una URL firmada que utiliza una política personalizada](#private-content-custom-policy-statement).  
La instrucción de política controla el acceso que una URL firmada concede a un usuario. Incluye la URL del archivo, una fecha y hora de vencimiento, una fecha y hora opcionales en que la URL se convierte en válida y una dirección IP opcional o un intervalo de direcciones IP a las que se permite acceder al archivo.  
**5. `&Signature=`*versión firmada y a la que se le ha aplicado una función hash de la instrucción de política***  
Una versión firmada, a la que se le ha aplicado una función hash y codificada en base64 de la instrucción de política JSON. Para obtener más información, consulte [Creación de una firma para una URL firmada que utiliza una política personalizada](#private-content-custom-policy-creating-signature).  
**6. `&Key-Pair-Id=`*ID de clave pública para la clave pública de CloudFront cuya clave privada correspondiente va a utilizar para generar la firma***  
El ID de una clave pública de CloudFront, por ejemplo, `K2JCJMDEHXQW5F`. El ID de clave pública indica a CloudFront qué clave pública usar para validar la URL firmada. CloudFront compara la información de la firma con la información de la instrucción de política para comprobar que la URL no se ha manipulado.  
Esta clave pública debe pertenecer a un grupo de claves que tiene un signatario de confianza en la distribución. Para obtener más información, consulte [Especificación de los signatarios que pueden crear URL firmadas y cookies firmadas](private-content-trusted-signers.md).

## Creación de una instrucción de política para una URL firmada que utiliza una política personalizada
<a name="private-content-custom-policy-statement"></a>

Complete los siguientes pasos para crear una instrucción de política para una URL firmada que utiliza una política personalizada.

Para consultar instrucciones de políticas de ejemplo que controlan el acceso a archivos de distintas maneras, consulte [Instrucciones de políticas de ejemplo para una URL firmada que utiliza una política personalizada](#private-content-custom-policy-statement-examples).<a name="private-content-custom-policy-creating-policy-procedure"></a>

**Para crear una instrucción de política para una URL firmada que use una política personalizada**

1. Cree la instrucción de política en el siguiente formato JSON. Sustituya los símbolos menor que (`<`) y mayor que (`>`) y las descripciones que contienen, por sus propios valores. Para obtener más información, consulte [Valores que se especifican en la instrucción de política de una URL firmada que utiliza una política personalizada](#private-content-custom-policy-statement-values).

   ```
   {
       "Statement": [
           {
               "Resource": "<Optional but recommended: URL of the file>",
               "Condition": {
                   "DateLessThan": {
   	                "AWS:EpochTime": <Required: ending date and time in Unix time format and UTC>
                   },
                   "DateGreaterThan": {
   	                "AWS:EpochTime": <Optional: beginning date and time in Unix time format and UTC>
                   },
                   "IpAddress": {
   	                "AWS:SourceIp": "<Optional: IP address>"
                   }
               }
           }
       ]
   }
   ```

   Tenga en cuenta lo siguiente:
   + Puede incluir solo una instrucción en la política.
   + Utilice la codificación de caracteres UTF-8.
   + Incluya toda la puntuación y los nombres de parámetros exactamente como se especifica. No se aceptan abreviaturas de nombres de parámetros.
   + El orden de los parámetros de la sección `Condition` no importa.
   + Para obtener información acerca de valores para `Resource`, `DateLessThan`, `DateGreaterThan` y `IpAddress`, consulte [Valores que se especifican en la instrucción de política de una URL firmada que utiliza una política personalizada](#private-content-custom-policy-statement-values).

1. Elimine todos los espacios vacíos (incluidos tabuladores y caracteres de línea nueva) de la instrucción de la política. Es posible que tenga que incluir caracteres de escape en la cadena del código de la aplicación.

1. Codifique la instrucción de política con codificación base64 de MIME. Para obtener más información, consulte la [Section 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) de *RFC 2045, MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies*.

1. Sustituya caracteres no válidos en una cadena de consulta de URL por caracteres válidos. En la siguiente tabla se muestran los caracteres válidos y no válidos.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonCloudFront/latest/DeveloperGuide/private-content-creating-signed-url-custom-policy.html)

1. Añada el valor resultante a la URL firmada después de `Policy=`.

1. Cree una firma para la URL firmada aplicando una función hash, firmando y codificando con base64 la instrucción de política. Para obtener más información, consulte [Creación de una firma para una URL firmada que utiliza una política personalizada](#private-content-custom-policy-creating-signature).

### Valores que se especifican en la instrucción de política de una URL firmada que utiliza una política personalizada
<a name="private-content-custom-policy-statement-values"></a>

Al crear una instrucción de política para una política personalizada, debe especificar los siguientes valores.

**Resource**  
La URL, incluidas las cadenas de consulta, pero excluyendo los parámetros de CloudFront `Policy`, `Signature` y `Key-Pair-Id`. Por ejemplo:  
`https://d111111abcdef8.cloudfront.net/images/horizon.jpg\?size=large&license=yes`  
Puede especificar solo un valor de URL para `Resource`.  
Puede omitir el parámetro `Resource` en una política, pero hacerlo significa que cualquiera con la URL firmada puede acceder a *todos* los archivos en *cualquier* distribución asociada con el par de claves que utiliza para crear la URL firmada.
Tenga en cuenta lo siguiente:  
+ **Protocolo**: el valor debe comenzar con `http://`, `https://` o `*://`.
+ **Parámetros de cadena de consulta**: si la URL tiene parámetros de cadena de consulta, no utilice una barra oblicua inversa (`\`) para evitar el signo de interrogación (`?`) que comienza la cadena de consulta. Por ejemplo:

  `https://d111111abcdef8.cloudfront.net/images/horizon.jpg?size=large&license=yes`
+ **Caracteres comodín**: puede utilizar caracteres comodín en la URL de la política. Se admiten los siguientes caracteres comodín:
  + asterisco (`*`), que busca coincidencias con cero o más caracteres
  + el signo de interrogación de cierre (`?`), que busca coincidencias exactamente con un carácter

  Cuando CloudFront hace coincidir la URL de la política con la URL de la solicitud HTTP, la URL de la política se divide en cuatro secciones (protocolo, dominio, ruta y cadena de consulta) de la siguiente manera:

  `[protocol]://[domain]/[path]\?[query string]`

  Al utilizar un carácter comodín en la URL de la política, la coincidencia de caracteres comodín solo se aplica dentro de los límites de la sección que contiene el comodín. Por ejemplo, considere esta URL en una política:

  `https://www.example.com/hello*world`

  En este ejemplo, el comodín asterisco (`*`) solo se aplica a la sección de rutas, por lo que coincide con las URL `https://www.example.com/helloworld` y `https://www.example.com/hello-world`, pero no con la URL `https://www.example.net/hello?world`.

  Las siguientes excepciones se aplican a los límites de las secciones para la coincidencia de caracteres comodín:
  + Un asterisco al final de la sección de rutas implica un asterisco en la sección de cadenas de consulta. Por ejemplo, `http://example.com/hello*` equivale a `http://example.com/hello*\?*`.
  + Un asterisco al final de la sección de dominio implica un asterisco en la secciones de ruta y cadena de consulta. Por ejemplo, `http://example.com*` equivale a `http://example.com*/*\?*`.
  + Una URL en la política puede omitir la sección de protocolo y empezar con un asterisco en la sección de dominio. En ese caso, la sección de protocolo se establece implícitamente en un asterisco. Por ejemplo, la URL `*example.com` en una política es equivalente a `*://*example.com/`.
  + Un asterisco por sí solo (`"Resource": "*"`) coincide con cualquier URL.

  Por ejemplo, el valor: `https://d111111abcdef8.cloudfront.net/*game_download.zip*` en una política coincide con todas las URL siguientes:
  + `https://d111111abcdef8.cloudfront.net/game_download.zip`
  + `https://d111111abcdef8.cloudfront.net/example_game_download.zip?license=yes`
  + `https://d111111abcdef8.cloudfront.net/test_game_download.zip?license=temp`
+ **Nombres de dominio alternativos**: si especifica un nombre de dominio alternativo (CNAME) en la URL de la política, la solicitud HTTP debe usar el nombre de dominio alternativo en la página web o aplicación. No especifique la URL de Amazon S3 para el archivo en una política.

**DateLessThan**  
La fecha y hora de vencimiento de la URL en formato de tiempo Unix (en segundos) y hora universal coordinada (UTC). En la política, no incluya el valor entre comillas. Para obtener información acerca de UTC, consulte [Fecha y hora en Internet: marcas temporales](https://tools.ietf.org/html/rfc3339).  
Por ejemplo, el 31 de enero de 2023 a las 10:00 UTC pasa a ser 1675159200 en formato de tiempo Unix.  
Este es el único parámetro requerido en la sección `Condition`. CloudFront requiere este valor para impedir que los usuarios tengan acceso permanente al contenido privado.  
Para obtener más información, consulte [Cuándo comprueba CloudFront la fecha y hora de vencimiento de una URL firmada](private-content-signed-urls.md#private-content-check-expiration)

**DateGreaterThan (opcional)**  
Una fecha y hora de inicio opcionales de la URL en formato de tiempo Unix (en segundos) y hora universal coordinada (UTC). Los usuarios no pueden acceder al archivo en la fecha y hora especificadas ni antes. No incluya el valor entre comillas. 

**IpAddress (opcional)**  
La dirección IP del cliente que hace la solicitud HTTP. Tenga en cuenta lo siguiente:  
+ Para permitir que cualquier dirección IP obtenga acceso al archivo, omita el parámetro `IpAddress`.
+ Puede especificar una dirección IP o a un rango de direcciones IP. No puede usar la política para permitir el acceso si la dirección IP del cliente está en uno de dos rangos separados.
+ Para permitir el acceso desde una única dirección IP, especifique:

  `"`*Dirección IP IPv*`/32"`
+ Debe especificar rangos de direcciones IP en formato estándar IPv4 CIDR (por ejemplo, `192.0.2.0/24`). Para obtener más información, consulte [Enrutamiento entre dominios sin clases (CIDR): Asignación de dirección de Internet y plan de agregación](https://tools.ietf.org/html/rfc4632).
**importante**  
Las direcciones IP en formato IPv6, como 2001:0db8:85a3::8a2e:0370:7334, no son compatibles. 

  Si está utilizando una política personalizada que incluya `IpAddress`, no habilite IPv6 para la distribución. Si desea restringir el acceso a algún contenido por dirección IP y admite solicitudes IPv6 de otro contenido, puede crear dos distribuciones. Para obtener más información, consulte [Habilitación de IPv6 (solicitudes de espectadores)](DownloadDistValuesGeneral.md#DownloadDistValuesEnableIPv6) en el tema [Referencia de toda la configuración de distribución](distribution-web-values-specify.md).

## Instrucciones de políticas de ejemplo para una URL firmada que utiliza una política personalizada
<a name="private-content-custom-policy-statement-examples"></a>

En los siguientes ejemplos de instrucciones de políticas, se muestra cómo controlar el acceso a un archivo específico, a todos los archivos de un directorio o a todos los archivos asociados a un ID de par de claves. Los ejemplos también muestran cómo controlar el acceso desde una dirección IP individual o a un rango de direcciones IP, y cómo impedir que los usuarios utilicen la URL firmada después de una fecha y hora específicas.

Si copia y pega cualquiera de estos ejemplos, elimine los espacios vacíos (incluidos los tabuladores y los caracteres de línea nueva), sustituya los valores por sus propios valores e incluya un carácter de línea nueva después de la llave de cierre (`}`).

Para obtener más información, consulte [Valores que se especifican en la instrucción de política de una URL firmada que utiliza una política personalizada](#private-content-custom-policy-statement-values).

**Topics**
+ [Ejemplo de instrucción de política: acceso a un archivo desde un intervalo de direcciones IP](#private-content-custom-policy-statement-example-one-object)
+ [Ejemplo de instrucción de política: acceso a todos los archivos de un directorio desde un intervalo de direcciones IP](#private-content-custom-policy-statement-example-all-objects)
+ [Ejemplo de instrucción de política: acceso a todos los archivos asociados con un ID de par de claves desde una dirección IP](#private-content-custom-policy-statement-example-one-ip)

### Ejemplo de instrucción de política: acceso a un archivo desde un intervalo de direcciones IP
<a name="private-content-custom-policy-statement-example-one-object"></a>

En el siguiente ejemplo de política personalizada de una URL firmada se especifica que un usuario puede acceder al archivo `https://d111111abcdef8.cloudfront.net/game_download.zip` desde las direcciones IP del intervalo `192.0.2.0/24` hasta el 31 de enero de 2023 a las 10:00 UTC:

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/game_download.zip",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.0/24"
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1675159200
                }
            }
        }
    ]
}
```

### Ejemplo de instrucción de política: acceso a todos los archivos de un directorio desde un intervalo de direcciones IP
<a name="private-content-custom-policy-statement-example-all-objects"></a>

La siguiente política personalizada de ejemplo le permite crear URL firmadas para cualquier archivo del directorio `training`, tal y como indica el carácter comodín asterisco (`*`) del parámetro `Resource`. Los usuarios pueden acceder al archivo desde una dirección IP incluida en el rango `192.0.2.0/24` hasta el 31 de enero de 2023 a las 10:00 UTC:

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/training/*",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.0/24"
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1675159200
                }
            }
        }
    ]
}
```

Cada URL firmada con la que utilice esta política tiene una URL que identifica a un archivo específico, por ejemplo:

`https://d111111abcdef8.cloudfront.net/training/orientation.pdf`

### Ejemplo de instrucción de política: acceso a todos los archivos asociados con un ID de par de claves desde una dirección IP
<a name="private-content-custom-policy-statement-example-one-ip"></a>

La siguiente política personalizada de ejemplo le permite crear URL firmadas para cualquier archivo asociado a cualquier distribución, tal y como indica el carácter comodín asterisco (`*`) del parámetro `Resource`. La URL firmada debe usar el protocolo `https://`, no `http://`. El usuario debe utilizar la dirección IP `192.0.2.10/32`. (El valor `192.0.2.10/32` en notación CIDR se refiere a la dirección IP individual `192.0.2.10`). Los archivos solo van a estar disponibles desde el 31 de enero de 2023 a las 10:00 UTC hasta el 2 de febrero de 2023 a las 10:00 UTC:

```
{
    "Statement": [
       {
            "Resource": "https://*",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.10/32"
                },
                "DateGreaterThan": {
                    "AWS:EpochTime": 1675159200
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1675332000
                }
            }
        }
    ]
}
```

Cada URL firmada con la que utilice esta política tiene una URL que identifica un archivo específico de una distribución de CloudFront específica; por ejemplo:

`https://d111111abcdef8.cloudfront.net/training/orientation.pdf`

La URL firmada también incluye un ID de par de claves que se debe asociar con un grupo de claves de confianza en la distribución (d111111abcdef8.cloudfront.net) que se especifica en la URL.

## Creación de una firma para una URL firmada que utiliza una política personalizada
<a name="private-content-custom-policy-creating-signature"></a>

La firma de una URL firmada que utiliza una política personalizada es una versión de la instrucción de política a la que se le ha aplicado una función hash, firmada y codificada con base64. Para crear una firma para una política personalizada, complete los pasos siguientes.

Para obtener más información y ejemplos de cómo resumir, aplicar una función hash y codificar la instrucción de política, consulte:
+ [Comandos de Linux y OpenSSL para codificación y cifrado base64](private-content-linux-openssl.md)
+ [Ejemplos de código para la creación de una firma para una URL firmada](PrivateCFSignatureCodeAndExamples.md)<a name="private-content-custom-policy-creating-signature-download-procedure"></a>

**Opción 1: para crear una firma mediante una política personalizada**

1. Use la función hash SHA-1 y la clave privada RSA o ECDSA generada para codificar y firmar la instrucción de política JSON creada en el procedimiento [Para crear una instrucción de política para una URL firmada que use una política personalizada](#private-content-custom-policy-creating-policy-procedure). Utilice la versión de la instrucción de política que ya no incluye espacios vacíos pero que aún no se ha codificado con base64.

   Para la clave privada requerida por la función hash, utilice una clave privada cuya clave pública esté en un grupo de claves de confianza activo para la distribución.
**nota**  
El método que utilice para resumir y aplicar una función hash la instrucción de política depende de su lenguaje de programación y plataforma. Para ver código de muestra, consulte [Ejemplos de código para la creación de una firma para una URL firmada](PrivateCFSignatureCodeAndExamples.md).

1. Elimine los espacios vacíos (incluidos tabuladores y caracteres de línea nueva) de la cadena a la que se le ha aplicado una función hash y firmada.

1. Codifique la cadena con codificación base64 de MIME. Para obtener más información, consulte la [Section 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) de *RFC 2045, MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies*.

1. Sustituya caracteres no válidos en una cadena de consulta de URL por caracteres válidos. En la siguiente tabla se muestran los caracteres válidos y no válidos.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonCloudFront/latest/DeveloperGuide/private-content-creating-signed-url-custom-policy.html)

1. Añada el valor resultante a la URL firmada después de `&Signature=` y vuelva a [Para crear una URL firmada mediante una política personalizada](#private-content-creating-signed-url-custom-policy-procedure) para terminar de encadenar las partes de la URL firmada.

# Uso de cookies firmadas
<a name="private-content-signed-cookies"></a>

Las cookies firmadas de CloudFront le permiten controlar quién puede acceder al contenido cuando no desea cambiar las URL actuales o cuando desea proporcionar acceso a varios archivos restringidos, por ejemplo, todos los archivos del área de suscriptores de un sitio web. En este tema se explica qué tomar en cuenta al utilizar cookies firmadas y describe cómo configurarlas mediante políticas predefinidas o personalizadas.

**Topics**
+ [Decisión de utilizar políticas predefinidas o personalizadas para cookies firmadas](#private-content-choosing-canned-custom-cookies)
+ [Cómo funcionan las cookies firmadas](#private-content-how-signed-cookies-work)
+ [Prevención del uso indebido de cookies firmadas](#private-content-signed-cookie-misuse)
+ [Cuándo comprueba CloudFront la fecha y hora de vencimiento de una cookie firmada](#private-content-check-expiration-cookie)
+ [Código de muestra y herramientas de terceros](#private-content-overview-sample-code-cookies)
+ [Establecimiento de cookies firmadas mediante una política predefinida](private-content-setting-signed-cookie-canned-policy.md)
+ [Establecimiento de cookies firmadas mediante una política personalizada](private-content-setting-signed-cookie-custom-policy.md)
+ [Create signed cookies using PHP](signed-cookies-PHP.md)

## Decisión de utilizar políticas predefinidas o personalizadas para cookies firmadas
<a name="private-content-choosing-canned-custom-cookies"></a>

Al crear una cookie firmada, se escribe una instrucción de política en formato JSON que especifica las restricciones en la cookie firmada, por ejemplo, el tiempo de validez de la cookie. Puede utilizar políticas predefinidas o personalizadas. En la siguiente tabla se comparan las políticas predefinidas y las personalizadas:


****  

| Descripción | Política predefinida | Política personalizada | 
| --- | --- | --- | 
| Puede reutilizar la instrucción de la política con varios archivos. Para reutilizar la instrucción de política, debe utilizar caracteres comodín en el objeto `Resource`. Para obtener más información, consulte ). [Valores que se especifican en la instrucción de política de una política personalizada para cookies firmadas](private-content-setting-signed-cookie-custom-policy.md#private-content-custom-policy-statement-cookies-values).)  | No | Sí | 
| Puede especificar la fecha y la hora a la que los usuarios pueden empezar a obtener acceso a su contenido. | No | Sí (opcional) | 
| Puede especificar la fecha y la hora a la que los usuarios dejan de obtener acceso a su contenido. | Sí | Sí | 
| Puede especificar la dirección IP o a un rango de direcciones IP de los usuarios que pueden obtener acceso a su contenido. | No | Sí (opcional) | 

Para obtener información acerca de cómo crear cookies firmadas mediante una política predefinida, consulte [Establecimiento de cookies firmadas mediante una política predefinida](private-content-setting-signed-cookie-canned-policy.md).

Para obtener información acerca de cómo crear cookies firmadas mediante una política personalizada, consulte [Establecimiento de cookies firmadas mediante una política personalizada](private-content-setting-signed-cookie-custom-policy.md).

## Cómo funcionan las cookies firmadas
<a name="private-content-how-signed-cookies-work"></a>

A continuación, se muestra información general acerca de cómo configurar CloudFront para cookies firmadas y cómo responde CloudFront cuando un usuario envía una solicitud que contiene una cookie firmada. 

1. En la distribución de CloudFront, especifique uno o más grupos de claves de confianza, que contienen las claves públicas que CloudFront puede utilizar para comprobar la firma de URL. Se utilizan las claves privadas correspondientes para firmar las URL.

   Para obtener más información, consulte [Especificación de los signatarios que pueden crear URL firmadas y cookies firmadas](private-content-trusted-signers.md).

1. Desarrolle una aplicación para determinar si un usuario debe obtener acceso a su contenido y, en caso de que sí, que envíe 3 encabezados `Set-Cookie` al espectador. (Cada encabezado `Set-Cookie` puede contener solo un par de nombre-valor y una cookie de CloudFront firmada requiere tres pares de nombre-valor). Debe enviar los encabezados `Set-Cookie` al espectador antes de que el usuario solicite su contenido privado. Si configura un periodo de vencimiento corto en la cookie, le recomendamos enviar tres encabezados `Set-Cookie` más en respuesta a solicitudes posteriores, de modo que el usuario continúe teniendo acceso.

   Normalmente, la distribución de CloudFront tendrá al menos dos comportamientos de la caché: uno que no requiere autenticación y otro que sí. La página de error de la parte segura del sitio incluye un redirector o un enlace a una página de inicio de sesión.

   Si configura la distribución para que el almacenamiento de archivos en la caché dependa de las cookies, CloudFront no almacenará archivos independientes en la caché en función de los atributos de las cookies firmadas.

1. Un usuario inicia sesión en su sitio web y paga por el contenido o cumple algún otro requisito para el acceso.

1. Su aplicación devuelve los encabezados `Set-Cookie` en la respuesta, y el espectador almacena los pares nombre-valor.

1. El usuario solicita un archivo.

   El navegador del usuario o cualquier otro espectador obtiene los pares nombre-valor del paso 4 y los añade a la solicitud en un encabezado `Cookie`. Esta es la cookie firmada.

1. CloudFront utiliza la clave pública para validar la firma en la cookie firmada y confirmar que dicha cookie no se ha manipulado. Si la firma no es válida, se rechaza la solicitud.

   Si la firma de la cookie es válida, CloudFront examina la instrucción de la política en la cookie (o crea una si utiliza una política predefinida) para confirmar que la solicitud sigue siendo válida. Por ejemplo, si ha especificado una fecha y hora de inicio y fin de la cookie, CloudFront confirma que el usuario intenta acceder al contenido durante el periodo en el que ha decidido permitir dicho acceso.

   Si la solicitud cumple los requisitos de la instrucción de la política, CloudFront enviará el contenido del mismo modo que envía el contenido no restringido: determina si el archivo ya está en la caché de borde, reenvía la solicitud al origen en caso necesario y devuelve el archivo al usuario.

## Prevención del uso indebido de cookies firmadas
<a name="private-content-signed-cookie-misuse"></a>

Si especifica el parámetro `Domain` en un encabezado `Set-Cookie`, especifique el valor de la forma más precisa posible para reducir el acceso potencial por parte de alguien con el mismo nombre de dominio raíz. Por ejemplo, app.example.com es mejor que example.com, especialmente si no controla example.com. Esto ayuda a impedir que alguien obtenga acceso a su contenido desde www.example.com.

Para evitar este tipo de ataques, haga lo siguiente:
+ Excluya los atributos de cookies `Expires` y `Max-Age` para que el encabezado `Set-Cookie` cree una cookie de sesión. Las cookies de sesión se eliminan automáticamente cuando el usuario cierra el navegador, lo que reduce la posibilidad de alguien obtenga acceso no autorizado a su contenido.
+ Incluya el atributo `Secure` para que la cookie se cifre cuando un espectador la incluya en una solicitud.
+ De ser posible, utilice una política personalizada e incluya la dirección IP del espectador.
+ En el atributo `CloudFront-Expires`, especifique el menor tiempo de vencimiento posible pero razonable en función de por cuánto tiempo desea que los usuarios puedan obtener acceso a su contenido.

## Cuándo comprueba CloudFront la fecha y hora de vencimiento de una cookie firmada
<a name="private-content-check-expiration-cookie"></a>

Para determinar si una cookie firmada sigue siendo válida, CloudFront comprueba la fecha y hora de vencimiento de la cookie en el momento de la solicitud HTTP. Si un cliente comienza a descargar un archivo grande inmediatamente antes de la fecha de vencimiento, la descarga se realizará por completo incluso si se sobrepasa la hora de vencimiento durante la descarga. Si la conexión TCP se interrumpe y el cliente intenta reiniciar la descarga después de la fecha de vencimiento, la descarga fallará.

Si un cliente utiliza rangos GET para obtener un archivo en partes más pequeñas, cualquier solicitud GET que se produzca después de la fecha de vencimiento no se procesará. Para obtener más información acerca de Range GET, consulte [Cómo CloudFront procesa las solicitudes parciales de un objeto (rango GET)](RangeGETs.md).

## Código de muestra y herramientas de terceros
<a name="private-content-overview-sample-code-cookies"></a>

El código de muestra para contenido privado solo muestra cómo crear firmas para URL firmadas. Sin embargo, el proceso de creación de una firma para una cookie firmada es muy similar, así que gran parte del código de muestra es aplicable. Para obtener más información, consulte los temas siguientes: 
+ [Crear una firma de URL con Perl](CreateURLPerl.md)
+ [Crear una firma de URL con PHP](CreateURL_PHP.md)
+ [Crear una firma de URL mediante C\$1 y .NET Framework](CreateSignatureInCSharp.md)
+ [Crear una firma de URL con Java](CFPrivateDistJavaDevelopment.md)

# Establecimiento de cookies firmadas mediante una política predefinida
<a name="private-content-setting-signed-cookie-canned-policy"></a>

Para establecer una cookie firmada utilizando una política predefinida, complete los pasos siguientes. Para crear la firma, consulte [Creación de una firma para una cookie firmada que utiliza una política predefinida](#private-content-canned-policy-signature-cookies).<a name="private-content-setting-signed-cookie-canned-policy-procedure"></a>

**Para establecer cookies firmadas mediante una política predefinida**

1. Si utiliza. NET o Java para crear cookies firmadas y no ha reformateado la clave privada del par de claves del formato .pem predeterminado a un formato compatible con .NET o con Java, hágalo ahora. Para obtener más información, consulte [Volver a formatear la clave privada (solo .NET y Java)](private-content-trusted-signers.md#private-content-reformatting-private-key).

1. Programe su aplicación para enviar tres encabezados `Set-Cookie` a los espectadores aprobados. Necesita tres encabezados `Set-Cookie` porque cada encabezado `Set-Cookie` puede contener solo un par de nombre-valor y una cookie firmada de CloudFront requiere tres pares de nombre-valor. Los pares de nombre-valor son: `CloudFront-Expires`, `CloudFront-Signature` y `CloudFront-Key-Pair-Id`. Los valores deben estar presentes en el lector antes de que un usuario realice la primera solicitud de un archivo cuyo acceso desea controlar. 
**nota**  
En general, recomendamos que excluya los atributos `Expires` y `Max-Age`. Al excluir los atributos, el navegador elimina la cookie cuando el usuario lo cierra, lo que reduce la posibilidad de alguien obtenga acceso no autorizado a su contenido. Para obtener más información, consulte [Prevención del uso indebido de cookies firmadas](private-content-signed-cookies.md#private-content-signed-cookie-misuse).

   **Los nombres de los atributos de las cookies distinguen entre mayúsculas y minúsculas**. 

   Los saltos de línea se incluyen únicamente para que los atributos sean más legibles.

   ```
   Set-Cookie: 
   CloudFront-Expires=date and time in Unix time format (in seconds) and Coordinated Universal Time (UTC); 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   
   Set-Cookie: 
   CloudFront-Signature=hashed and signed version of the policy statement; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   
   Set-Cookie: 
   CloudFront-Key-Pair-Id=public key ID for the CloudFront public key whose corresponding private key you're using to generate the signature; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   ```  
**(Opcional) `Domain`**  
Nombre de dominio del archivo solicitado. Si no especifica un atributo `Domain`, el valor predeterminado será el nombre de dominio de la URL; esto es aplicable solo al nombre de dominio especificado, no a subdominios. Si especifica un atributo `Domain`, también será aplicable a subdominios. Un punto al inicio del nombre de dominio (por ejemplo, `Domain=.example.com`) es opcional. Además, si no especifica un atributo `Domain`, el nombre de dominio de la URL y el valor del atributo `Domain` deberán coincidir.  
Puede especificar el nombre de dominio que CloudFront ha asignado a la distribución, por ejemplo, d111111abcdef8.cloudfront.net, pero no puede especificar \$1.cloudfront.net para el nombre de dominio.  
Si desea utilizar un nombre de dominio alternativo como example.com en las URL, debe añadir dicho nombre de dominio a su distribución independientemente de que especifique el atributo `Domain`. Para obtener más información, consulte [Nombres de dominio alternativos (CNAME)](DownloadDistValuesGeneral.md#DownloadDistValuesCNAME) en el tema [Referencia de toda la configuración de distribución](distribution-web-values-specify.md).  
**(Opcional) `Path`**  
Ruta del archivo solicitado. Si no especifica un atributo `Path`, el valor predeterminado será la ruta de la URL.  
**`Secure`**  
Requiere que el espectador cifre cookies antes de enviar una solicitud. Recomendamos que envíe el encabezado `Set-Cookie` a través de una conexión HTTPS para asegurarse de que los atributos de la cookie estén protegidos contra ataques man-in-the-middle.  
**`HttpOnly`**  
Define la forma en que el navegador (si es compatible) interactúa con el valor de la cookie. Con `HttpOnly`, JavaScript no puede acceder a los valores de las cookies. Esta precaución puede ayudar a mitigar los ataques de scripting entre sitios (XSS). Para obtener más información, consulte [Using HTTP cookies](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies).  
**`CloudFront-Expires`**  
Especifique la fecha y la hora de vencimiento en formato de tiempo Unix (en segundos) y hora universal coordinada (UTC). Por ejemplo, 1 de enero de 2026 a las 10:00 UTC pasa a ser 1767290400 en formato de tiempo Unix.   
Para utilizar el tiempo de época, especifique un número entero de 64 bits para una fecha que no sea posterior a `9223372036854775807` (viernes, 11 de abril de 2262 a las 23:47:16.854 UTC).  
Para obtener información acerca de UTC, consulte *RFC 3339, fecha y hora en Internet: marcas temporales*, [https://tools.ietf.org/html/rfc3339](https://tools.ietf.org/html/rfc3339).  
**`CloudFront-Signature`**  
Una versión de una instrucción de política JSON firmada, a la que se le ha aplicado una función hash y codificada en base64. Para obtener más información, consulte [Creación de una firma para una cookie firmada que utiliza una política predefinida](#private-content-canned-policy-signature-cookies).  
**`CloudFront-Key-Pair-Id`**  
El ID de una clave pública de CloudFront, por ejemplo, `K2JCJMDEHXQW5F`. El ID de clave pública indica a CloudFront qué clave pública usar para validar la URL firmada. CloudFront compara la información de la firma con la información de la instrucción de política para comprobar que la URL no se ha manipulado.  
Esta clave pública debe pertenecer a un grupo de claves que tiene un signatario de confianza en la distribución. Para obtener más información, consulte [Especificación de los signatarios que pueden crear URL firmadas y cookies firmadas](private-content-trusted-signers.md).

En el ejemplo siguiente, se muestran los encabezados `Set-Cookie` de una cookie firmada cuando se usa el nombre de dominio asociado a la distribución en las URL de los archivos:

```
Set-Cookie: CloudFront-Expires=1426500000; Domain=d111111abcdef8.cloudfront.net; Path=/images/*; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=yXrSIgyQoeE4FBI4eMKF6ho~CA8_; Domain=d111111abcdef8.cloudfront.net; Path=/images/*; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=d111111abcdef8.cloudfront.net; Path=/images/*; Secure; HttpOnly
```

En el ejemplo siguiente, se muestran los encabezados `Set-Cookie` de una cookie firmada cuando se usa el nombre de dominio alternativo example.org en las URL de los archivos:

```
Set-Cookie: CloudFront-Expires=1426500000; Domain=example.org; Path=/images/*; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=yXrSIgyQoeE4FBI4eMKF6ho~CA8_; Domain=example.org; Path=/images/*; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=example.org; Path=/images/*; Secure; HttpOnly
```

Si desea utilizar un nombre de dominio alternativo como example.com en las URL, debe añadir dicho nombre de dominio a su distribución independientemente de que especifique el atributo `Domain`. Para obtener más información, consulte [Nombres de dominio alternativos (CNAME)](DownloadDistValuesGeneral.md#DownloadDistValuesCNAME) en el tema [Referencia de toda la configuración de distribución](distribution-web-values-specify.md).

## Creación de una firma para una cookie firmada que utiliza una política predefinida
<a name="private-content-canned-policy-signature-cookies"></a>

Para crear la firma para una cookie firmada que utilice una política predefinida, realice los procedimientos indicados a continuación.

**Topics**
+ [Creación de una instrucción de política para una cookie firmada que use una política predefinida](#private-content-canned-policy-statement-cookies)
+ [Firma de la instrucción de política para crear una firma para una cookie firmada que utiliza una política predefinida](#private-content-canned-policy-cookies-signing-policy-statement)

### Creación de una instrucción de política para una cookie firmada que use una política predefinida
<a name="private-content-canned-policy-statement-cookies"></a>

Al establecer una cookie firmada que use una política predefinida, el atributo `CloudFront-Signature` es una versión de una instrucción de política firmada y a la que se le ha aplicado una función hash. En el caso de cookies firmadas que utilizan una política predefinida, la instrucción de política no se incluye en el encabezado `Set-Cookie`, a diferencia de las cookies firmadas que utilizan una política personalizada. Para crear la instrucción de política, complete los pasos siguientes.<a name="private-content-canned-policy-statement-cookies-procedure"></a>

**Para crear una instrucción de política para una cookie firmada que use una política predefinida**

1. Cree la instrucción de política utilizando el siguiente formato JSON y codificación de caracteres UTF-8. Incluya toda la puntuación y otros valores literalmente, tal como se especifica. Para obtener más información acerca de los parámetros `Resource` y `DateLessThan`, consulte [Valores que se especifican en la instrucción de política de una política predefinida para cookies firmadas](#private-content-canned-policy-statement-cookies-values).

   ```
   {
       "Statement": [
           {
               "Resource": "base URL or stream name",
               "Condition": {
                   "DateLessThan": {
                       "AWS:EpochTime": ending date and time in Unix time format and UTC
                   }
               }
           }
       ]
   }
   ```

1. Elimine todos los espacios vacíos (incluidos tabuladores y caracteres de línea nueva) de la instrucción de la política. Es posible que tenga que incluir caracteres de escape en la cadena del código de la aplicación.

#### Valores que se especifican en la instrucción de política de una política predefinida para cookies firmadas
<a name="private-content-canned-policy-statement-cookies-values"></a>

Al crear una instrucción de una política predefinida, debe especificar los siguientes valores:

**Recurso**  
La URL base, incluidas las cadenas de consulta, de haberlas; por ejemplo:  
`https://d111111abcdef8.cloudfront.net/images/horizon.jpg?size=large&license=yes`  
Puede especificar solo un valor en `Resource`.  
Tenga en cuenta lo siguiente:  
+ **Protocol (Protocolo)**: el valor debe comenzar con `http://` o `https://`.
+ **Query string parameters (Parámetros de cadena de consulta)**: si no tiene parámetros de cadena de consulta, omita el signo de interrogación.
+ **Alternate domain names (Nombres de dominio alternativos)**: si especifica un nombre de dominio alternativo (CNAME) en la URL, debe especificarlo al hacer referencia al archivo en la página web o aplicación. No especifique la URL de Amazon S3 para el archivo.

**DateLessThan**  
La fecha y hora de vencimiento de la URL en formato de tiempo Unix (en segundos) y hora universal coordinada (UTC). No incluya el valor entre comillas.  
Por ejemplo, 16 de marzo de 2015 a las 10:00 h UTC pasa a ser 1426500000 en formato de tiempo Unix.  
Este valor debe coincidir con el valor del atributo `CloudFront-Expires` en el encabezado `Set-Cookie`. No incluya el valor entre comillas.  
Para obtener más información, consulte [Cuándo comprueba CloudFront la fecha y hora de vencimiento de una cookie firmada](private-content-signed-cookies.md#private-content-check-expiration-cookie).

#### Ejemplo de instrucción de política para una política predefinida
<a name="private-content-canned-policy-cookies-sample-policy-statement"></a>

Si se utiliza el siguiente ejemplo de instrucción de política en una cookie firmada, los usuarios podrán obtener acceso al archivo `https://d111111abcdef8.cloudfront.net/horizon.jpg` hasta el 16 de marzo de 2015 a las 10:00 h UTC:

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/horizon.jpg?size=large&license=yes",
            "Condition": {
                "DateLessThan": {
                    "AWS:EpochTime": 1426500000
                }
            }
        }
    ]
}
```

### Firma de la instrucción de política para crear una firma para una cookie firmada que utiliza una política predefinida
<a name="private-content-canned-policy-cookies-signing-policy-statement"></a>

Para crear el valor del atributo `CloudFront-Signature` en un encabezado `Set-Cookie`, aplique una función hash y firme la instrucción de política creada en [Para crear una instrucción de política para una cookie firmada que use una política predefinida](#private-content-canned-policy-statement-cookies-procedure). 

Para obtener más información y ejemplos de cómo aplicar una función hash, firmar y codificar la instrucción de política, consulte los siguientes temas:
+ [Comandos de Linux y OpenSSL para codificación y cifrado base64](private-content-linux-openssl.md)
+ [Ejemplos de código para la creación de una firma para una URL firmada](PrivateCFSignatureCodeAndExamples.md)<a name="private-content-canned-policy-cookie-creating-signature-procedure"></a>

**Para crear una firma para una cookie firmada que use una política predefinida**

1. Use la función hash SHA-1 y RSA para resumir y firmar la instrucción de política creada en el procedimiento [Para crear una instrucción de política para una cookie firmada que use una política predefinida](#private-content-canned-policy-statement-cookies-procedure). Utilice la versión de la instrucción de política que ya no incluye espacios vacíos.

   Para la clave privada requerida por la función hash, utilice una clave privada cuya clave pública esté en un grupo de claves de confianza activo para la distribución.
**nota**  
El método que utilice para resumir y aplicar una función hash la instrucción de política depende de su lenguaje de programación y plataforma. Para ver código de muestra, consulte [Ejemplos de código para la creación de una firma para una URL firmada](PrivateCFSignatureCodeAndExamples.md).

1. Elimine los espacios vacíos (incluidos tabuladores y caracteres de línea nueva) de la cadena a la que se le ha aplicado una función hash y firmada.

1. Codifique la cadena con codificación base64 de MIME. Para obtener más información, consulte la [Section 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) de *RFC 2045, MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies*.

1. Sustituya caracteres no válidos en una cadena de consulta de URL por caracteres válidos. En la siguiente tabla se muestran los caracteres válidos y no válidos.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonCloudFront/latest/DeveloperGuide/private-content-setting-signed-cookie-canned-policy.html)

1. Incluya el valor resultante en el encabezado `Set-Cookie` para el par nombre-valor `CloudFront-Signature`. A continuación, vuelva a [Para establecer cookies firmadas mediante una política predefinida](#private-content-setting-signed-cookie-canned-policy-procedure) y añada el encabezado `Set-Cookie` en `CloudFront-Key-Pair-Id`.

# Establecimiento de cookies firmadas mediante una política personalizada
<a name="private-content-setting-signed-cookie-custom-policy"></a>

Para establecer una cookie firmada que utiliza una política personalizada, complete los siguientes pasos.<a name="private-content-setting-signed-cookie-custom-policy-procedure"></a>

**Para establecer cookies firmadas mediante una política personalizada**

1. Si utiliza. NET o Java para crear URL firmadas y no ha reformateado la clave privada del par de claves del formato .pem predeterminado a un formato compatible con .NET o con Java, hágalo ahora. Para obtener más información, consulte [Volver a formatear la clave privada (solo .NET y Java)](private-content-trusted-signers.md#private-content-reformatting-private-key).

1. Programe su aplicación para enviar tres encabezados `Set-Cookie` a los espectadores aprobados. Necesita tres encabezados `Set-Cookie` porque cada encabezado `Set-Cookie` puede contener solo un par de nombre-valor y una cookie firmada de CloudFront requiere tres pares de nombre-valor. Los pares de nombre-valor son: `CloudFront-Policy`, `CloudFront-Signature` y `CloudFront-Key-Pair-Id`. Los valores deben estar presentes en el lector antes de que un usuario realice la primera solicitud de un archivo cuyo acceso desea controlar. 
**nota**  
En general, recomendamos que excluya los atributos `Expires` y `Max-Age`. Al excluirlos, el navegador elimina la cookie cuando el usuario lo cierra, lo que reduce la posibilidad de alguien obtenga acceso no autorizado a su contenido. Para obtener más información, consulte [Prevención del uso indebido de cookies firmadas](private-content-signed-cookies.md#private-content-signed-cookie-misuse).

   **Los nombres de los atributos de las cookies distinguen entre mayúsculas y minúsculas**. 

   Los saltos de línea se incluyen únicamente para que los atributos sean más legibles.

   ```
   Set-Cookie: 
   CloudFront-Policy=base64 encoded version of the policy statement; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   
   
   Set-Cookie: 
   CloudFront-Signature=hashed and signed version of the policy statement; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   
   Set-Cookie: 
   CloudFront-Key-Pair-Id=public key ID for the CloudFront public key whose corresponding private key you're using to generate the signature; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   ```  
**(Opcional) `Domain`**  
Nombre de dominio del archivo solicitado. Si no especifica un atributo `Domain`, el valor predeterminado será el nombre de dominio de la URL; esto es aplicable solo al nombre de dominio especificado, no a subdominios. Si especifica un atributo `Domain`, también será aplicable a subdominios. Un punto al inicio del nombre de dominio (por ejemplo, `Domain=.example.com`) es opcional. Además, si no especifica un atributo `Domain`, el nombre de dominio de la URL y el valor del atributo `Domain` deberán coincidir.  
Puede especificar el nombre de dominio que CloudFront ha asignado a la distribución, por ejemplo, d111111abcdef8.cloudfront.net, pero no puede especificar \$1.cloudfront.net para el nombre de dominio.  
Si desea utilizar un nombre de dominio alternativo como example.com en las URL, debe añadir dicho nombre de dominio a su distribución independientemente de que especifique el atributo `Domain`. Para obtener más información, consulte [Nombres de dominio alternativos (CNAME)](DownloadDistValuesGeneral.md#DownloadDistValuesCNAME) en el tema [Referencia de toda la configuración de distribución](distribution-web-values-specify.md).  
**(Opcional) `Path`**  
Ruta del archivo solicitado. Si no especifica un atributo `Path`, el valor predeterminado será la ruta de la URL.  
**`Secure`**  
Requiere que el espectador cifre cookies antes de enviar una solicitud. Recomendamos que envíe el encabezado `Set-Cookie` a través de una conexión HTTPS para asegurarse de que los atributos de la cookie estén protegidos contra ataques man-in-the-middle.  
**`HttpOnly`**  
Requiere que el espectador envíe la cookie únicamente en solicitudes de HTTP o HTTPS.  
**`CloudFront-Policy`**  
La instrucción de política en formato JSON después de haber eliminado los espacios vacíos y, a continuación, codificada con base64. Para obtener más información, consulte [Creación de una firma para una cookie firmada que utiliza una política personalizada](#private-content-custom-policy-signature-cookies).  
La instrucción de política controla el acceso que una cookie firmada concede a un usuario. Incluye los archivos a los que el usuario puede acceder, una fecha y hora de vencimiento, una fecha y hora opcionales a las que la URL se convierte en válida y una dirección IP opcional o un intervalo de direcciones IP a las que se permite acceder al archivo.  
**`CloudFront-Signature`**  
Una versión firmada, a la que se le ha aplicado una función hash y codificada en base64 de la instrucción de política JSON. Para obtener más información, consulte [Creación de una firma para una cookie firmada que utiliza una política personalizada](#private-content-custom-policy-signature-cookies).  
**`CloudFront-Key-Pair-Id`**  
El ID de una clave pública de CloudFront, por ejemplo, `K2JCJMDEHXQW5F`. El ID de clave pública indica a CloudFront qué clave pública usar para validar la URL firmada. CloudFront compara la información de la firma con la información de la instrucción de política para comprobar que la URL no se ha manipulado.  
Esta clave pública debe pertenecer a un grupo de claves que tiene un signatario de confianza en la distribución. Para obtener más información, consulte [Especificación de los signatarios que pueden crear URL firmadas y cookies firmadas](private-content-trusted-signers.md).

## Ejemplos de encabezados `Set-Cookie` para políticas personalizadas
<a name="example-set-cookie-headers-custom-policy"></a>

Consulte los siguientes ejemplos de pares de encabezados `Set-Cookie`. 

Si desea utilizar un nombre de dominio alternativo como example.org en las URL, debe agregarlo a la distribución independientemente de que especifique el atributo `Domain`. Para obtener más información, consulte [Nombres de dominio alternativos (CNAME)](DownloadDistValuesGeneral.md#DownloadDistValuesCNAME) en el tema [Referencia de toda la configuración de distribución](distribution-web-values-specify.md).

**Example Ejemplo 1**  
Puede utilizar los encabezados `Set-Cookie` de una cookie firmada cuando se utiliza el nombre de dominio asociado a la distribución en las URL de los archivos.  

```
Set-Cookie: CloudFront-Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cDovL2QxMTExMTFhYmNkZWY4LmNsb3VkZnJvbnQubmV0L2dhbWVfZG93bmxvYWQuemlwIiwiQ29uZGl0aW9uIjp7IklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIxOTIuMC4yLjAvMjQifSwiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE0MjY1MDAwMDB9fX1dfQ__; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=dtKhpJ3aUYxqDIwepczPiDb9NXQ_; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
```

**Example Ejemplo 2**  
Puede utilizar los encabezados `Set-Cookie` de una cookie firmada cuando se utiliza el nombre de dominio alternativo (example.org) en las URL de los archivos.  

```
Set-Cookie: CloudFront-Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cDovL2QxMTExMTFhYmNkZWY4LmNsb3VkZnJvbnQubmV0L2dhbWVfZG93bmxvYWQuemlwIiwiQ29uZGl0aW9uIjp7IklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIxOTIuMC4yLjAvMjQifSwiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE0MjY1MDAwMDB9fX1dfQ__; Domain=example.org; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=dtKhpJ3aUYxqDIwepczPiDb9NXQ_; Domain=example.org; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=example.org; Path=/; Secure; HttpOnly
```

**Example Ejemplo 3**  
Puede utilizar los pares de encabezados `Set-Cookie` de una solicitud firmada cuando se utiliza el nombre de dominio asociado a la distribución en las URL de los archivos.  

```
Set-Cookie: CloudFront-Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cDovL2QxMTExMTFhYmNkZWY4LmNsb3VkZnJvbnQubmV0L2dhbWVfZG93bmxvYWQuemlwIiwiQ29uZGl0aW9uIjp7IklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIxOTIuMC4yLjAvMjQifSwiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE0MjY1MDAwMDB9fX1dfQ__; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=dtKhpJ3aUYxqDIwepczPiDb9NXQ_; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=dd111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
```

**Example Ejemplo 4**  
Puede utilizar los pares de encabezados `Set-Cookie` de una solicitud firmada cuando se utiliza un nombre de dominio alternativo (example.org) asociado a la distribución en las URL de los archivos.  

```
Set-Cookie: CloudFront-Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cDovL2QxMTExMTFhYmNkZWY4LmNsb3VkZnJvbnQubmV0L2dhbWVfZG93bmxvYWQuemlwIiwiQ29uZGl0aW9uIjp7IklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIxOTIuMC4yLjAvMjQifSwiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE0MjY1MDAwMDB9fX1dfQ__; Domain=example.org; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=dtKhpJ3aUYxqDIwepczPiDb9NXQ_; Domain=example.org; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=example.org; Path=/; Secure; HttpOnly
```

## Creación de una instrucción de política para una cookie firmada que utiliza una política personalizada
<a name="private-content-custom-policy-statement-cookies"></a>

Para crear una instrucción de política para una política personalizada, complete los siguientes pasos. Para consultar varias instrucciones de políticas de ejemplo que controlan el acceso a archivos de distintas maneras, consulte [Ejemplos de instrucciones de políticas para una cookie firmada que utiliza una política personalizada](#private-content-custom-policy-statement-signed-cookies-examples).<a name="private-content-custom-policy-statement-cookies-procedure"></a>

**Para crear una instrucción de política para una cookie firmada que use una política personalizada**

1. Cree la instrucción de política en el siguiente formato JSON.

   ```
   {
       "Statement": [
           {
               "Resource": "URL of the file",
               "Condition": {
                   "DateLessThan": {
                       "AWS:EpochTime":required ending date and time in Unix time format and UTC
                   },
                   "DateGreaterThan": {
                       "AWS:EpochTime":optional beginning date and time in Unix time format and UTC
                   },
                   "IpAddress": {
                       "AWS:SourceIp": "optional IP address"
                   }
               }
           }
       ]
   }
   ```

   Tenga en cuenta lo siguiente:
   + Puede incluir una instrucción.
   + Utilice la codificación de caracteres UTF-8.
   + Incluya toda la puntuación y los nombres de parámetros exactamente como se especifica. No se aceptan abreviaturas de nombres de parámetros.
   + El orden de los parámetros de la sección `Condition` no importa.
   + Para obtener información acerca de valores para `Resource`, `DateLessThan`, `DateGreaterThan` y `IpAddress`, consulte [Valores que se especifican en la instrucción de política de una política personalizada para cookies firmadas](#private-content-custom-policy-statement-cookies-values).

1. Elimine todos los espacios vacíos (incluidos tabuladores y caracteres de línea nueva) de la instrucción de la política. Es posible que tenga que incluir caracteres de escape en la cadena del código de la aplicación.

1. Codifique la instrucción de política con codificación base64 de MIME. Para obtener más información, consulte la [Section 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) de *RFC 2045, MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies*.

1. Sustituya caracteres no válidos en una cadena de consulta de URL por caracteres válidos. En la siguiente tabla se muestran los caracteres válidos y no válidos.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonCloudFront/latest/DeveloperGuide/private-content-setting-signed-cookie-custom-policy.html)

1. Incluya el valor resultante en el encabezado `Set-Cookie` después de `CloudFront-Policy=`.

1. Cree una firma para el encabezado `Set-Cookie` en `CloudFront-Signature` aplicando una función hash, firmando y codificando con base64 la instrucción de política. Para obtener más información, consulte [Creación de una firma para una cookie firmada que utiliza una política personalizada](#private-content-custom-policy-signature-cookies).

### Valores que se especifican en la instrucción de política de una política personalizada para cookies firmadas
<a name="private-content-custom-policy-statement-cookies-values"></a>

Al crear una instrucción de política para una política personalizada, debe especificar los siguientes valores.

**Recurso**  
La URL base, incluidas las cadenas de consulta, de haberlas:  
`https://d111111abcdef8.cloudfront.net/images/horizon.jpg?size=large&license=yes`  
Si omite el parámetro `Resource`, los usuarios podrán obtener acceso a todos los archivos asociados a cualquier distribución que esté asociada al par de claves utilizado para crear la URL firmada.
Puede especificar solo un valor en `Resource`.  
Tenga en cuenta lo siguiente:  
+ **Protocol (Protocolo)**: el valor debe comenzar con `http://` o `https://`.
+ **Query string parameters (Parámetros de cadena de consulta)**: si no tiene parámetros de cadena de consulta, omita el signo de interrogación.
+ **Wildcards (Caracteres comodín)**: puede utilizar el carácter comodín que coincide con cero o más caracteres (\$1) o el carácter comodín que coincide exactamente con un carácter (?) en cualquier lugar de la cadena. Por ejemplo, el valor:

  `https://d111111abcdef8.cloudfront.net/*game_download.zip*`

  incluiría, por ejemplo, los siguientes archivos:
  + `https://d111111abcdef8.cloudfront.net/game_download.zip`
  + `https://d111111abcdef8.cloudfront.net/example_game_download.zip?license=yes`
  + `https://d111111abcdef8.cloudfront.net/test_game_download.zip?license=temp`
+ **Alternate domain names (Nombres de dominio alternativos)**: si especifica un nombre de dominio alternativo (CNAME) en la URL, debe especificarlo al hacer referencia al archivo en la página web o aplicación. No especifique la URL de Amazon S3 para el archivo.

**DateLessThan**  
La fecha y hora de vencimiento de la URL en formato de tiempo Unix (en segundos) y hora universal coordinada (UTC). No incluya el valor entre comillas.  
Por ejemplo, 16 de marzo de 2015 a las 10:00 h UTC pasa a ser 1426500000 en formato de tiempo Unix.  
Para obtener más información, consulte [Cuándo comprueba CloudFront la fecha y hora de vencimiento de una cookie firmada](private-content-signed-cookies.md#private-content-check-expiration-cookie).

**DateGreaterThan (opcional)**  
Una fecha y hora de inicio opcionales de la URL en formato de tiempo Unix (en segundos) y hora universal coordinada (UTC). Los usuarios no pueden acceder al archivo en la fecha y hora especificadas ni antes. No incluya el valor entre comillas. 

**IpAddress (opcional)**  
La dirección IP del cliente que hace la solicitud GET. Tenga en cuenta lo siguiente:  
+ Para permitir que cualquier dirección IP obtenga acceso al archivo, omita el parámetro `IpAddress`.
+ Puede especificar una dirección IP o a un rango de direcciones IP. Por ejemplo, no puede configurar la política para permitir el acceso si la dirección IP del cliente está en uno de dos rangos separados.
+ Para permitir el acceso desde una única dirección IP, especifique:

  `"`*Dirección IP IPv*`/32"`
+ Debe especificar rangos de direcciones IP en formato estándar IPv4 CIDR (por ejemplo, `192.0.2.0/24`). Para obtener más información, consulte *RFC 4632, Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan*, [https://tools.ietf.org/html/rfc4632](https://tools.ietf.org/html/rfc4632).
**importante**  
Las direcciones IP en formato IPv6, como 2001:0db8:85a3::8a2e:0370:7334, no son compatibles. 

  Si está utilizando una política personalizada que incluya `IpAddress`, no habilite IPv6 para la distribución. Si desea restringir el acceso a algún contenido por dirección IP y admite solicitudes IPv6 de otro contenido, puede crear dos distribuciones. Para obtener más información, consulte [Habilitación de IPv6 (solicitudes de espectadores)](DownloadDistValuesGeneral.md#DownloadDistValuesEnableIPv6) en el tema [Referencia de toda la configuración de distribución](distribution-web-values-specify.md).

## Ejemplos de instrucciones de políticas para una cookie firmada que utiliza una política personalizada
<a name="private-content-custom-policy-statement-signed-cookies-examples"></a>

En los siguientes ejemplos de instrucciones de políticas, se muestra cómo controlar el acceso a un archivo específico, a todos los archivos de un directorio o a todos los archivos asociados a un ID de par de claves. Los ejemplos también muestran cómo controlar el acceso de una dirección IP individual o a un rango de direcciones IP, y cómo impedir que los usuarios utilicen la cookie firmada después de una fecha y hora específicas.

Si copia y pega cualquiera de estos ejemplos, elimine los espacios vacíos (incluidos los tabuladores y los caracteres de línea nueva), sustituya los valores por sus propios valores e incluya un carácter de línea nueva después de la llave de cierre ( \$1 ).

Para obtener más información, consulte [Valores que se especifican en la instrucción de política de una política personalizada para cookies firmadas](#private-content-custom-policy-statement-cookies-values).

**Topics**
+ [Ejemplo de instrucción de política: acceso a un archivo desde un intervalo de direcciones IP](#private-content-custom-policy-statement-signed-cookies-example-one-object)
+ [Ejemplo de instrucción de política: acceso a todos los archivos de un directorio desde un intervalo de direcciones IP](#private-content-custom-policy-statement-signed-cookies-example-all-objects)
+ [Ejemplo de instrucción de política: acceso a todos los archivos asociados con un ID de par de claves desde una dirección IP](#private-content-custom-policy-statement-signed-cookies-example-one-ip)

### Ejemplo de instrucción de política: acceso a un archivo desde un intervalo de direcciones IP
<a name="private-content-custom-policy-statement-signed-cookies-example-one-object"></a>

En la siguiente política personalizada de ejemplo de una cookie firmada se especifica que un usuario puede acceder al archivo `https://d111111abcdef8.cloudfront.net/game_download.zip` desde las direcciones IP incluidas en el intervalo `192.0.2.0/24` hasta el 1 de enero de 2023 a las 10:00 UTC:

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/game_download.zip",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.0/24"
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1767290400
                }
            }
        }
    ]
}
```

### Ejemplo de instrucción de política: acceso a todos los archivos de un directorio desde un intervalo de direcciones IP
<a name="private-content-custom-policy-statement-signed-cookies-example-all-objects"></a>

La siguiente política personalizada de ejemplo le permite crear cookies firmadas para cualquier archivo del directorio `training`, tal y como indica el carácter comodín \$1 del parámetro `Resource`. Los usuarios podrán obtener acceso al archivo desde una dirección IP incluida en el rango `192.0.2.0/24` hasta el 1 de enero de 2013 a las 10:00 h UTC:

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/training/*",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.0/24"
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1767290400
                }
            }
        }
    ]
}
```

Cada cookie firmada en la que utilice esta política tendrá una URL base que identificará un archivo específico; por ejemplo:

`https://d111111abcdef8.cloudfront.net/training/orientation.pdf`

### Ejemplo de instrucción de política: acceso a todos los archivos asociados con un ID de par de claves desde una dirección IP
<a name="private-content-custom-policy-statement-signed-cookies-example-one-ip"></a>

La siguiente política personalizada de ejemplo le permite establecer cookies firmadas para cualquier archivo asociado a cualquier distribución, tal y como indica el carácter comodín \$1 del parámetro `Resource`. El usuario debe utilizar la dirección IP `192.0.2.10/32`. (El valor `192.0.2.10/32` en notación CIDR se refiere a la dirección IP individual `192.0.2.10`). Los archivos solo van a estar disponibles desde el 1 de enero de 2013 a las 10:00 h UTC hasta el 2 de enero de 2013 a las 10:00 h UTC:

```
{
    "Statement": [
        {
            "Resource": "https://*",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.10/32"
                },
                "DateGreaterThan": {
                    "AWS:EpochTime": 1767290400
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1767376800
                }
            }
        }
    ]
}
```

Cada cookie firmada en la que utiliza esta política incluye una URL base que identifica un archivo específico de una distribución de CloudFront específica; por ejemplo:

`https://d111111abcdef8.cloudfront.net/training/orientation.pdf`

La cookie firmada también incluye un ID de par de claves que se debe asociar con un grupo de claves de confianza en la distribución (d111111abcdef8.cloudfront.net) que se especifica en la URL base.

## Creación de una firma para una cookie firmada que utiliza una política personalizada
<a name="private-content-custom-policy-signature-cookies"></a>

La firma de una cookie firmada que utiliza una política personalizada es una versión de la instrucción de política a la que se le ha aplicado una función hash, firmada y codificada con base64. 

Para obtener más información y ejemplos de cómo resumir, aplicar una función hash y codificar la instrucción de política, consulte:
+ [Comandos de Linux y OpenSSL para codificación y cifrado base64](private-content-linux-openssl.md)
+ [Ejemplos de código para la creación de una firma para una URL firmada](PrivateCFSignatureCodeAndExamples.md)<a name="private-content-custom-policy-signature-cookies-procedure"></a>

**Para crear una firma para una cookie firmada con una política personalizada**

1. Use la función hash SHA-1 y RSA para resumir y firmar la instrucción de política JSON creada en el procedimiento [Para crear una instrucción de política para una URL firmada que use una política personalizada](private-content-creating-signed-url-custom-policy.md#private-content-custom-policy-creating-policy-procedure). Utilice la versión de la instrucción de política que ya no incluye espacios vacíos pero que aún no se ha codificado con base64.

   Para la clave privada requerida por la función hash, utilice una clave privada cuya clave pública esté en un grupo de claves de confianza activo para la distribución.
**nota**  
El método que utilice para resumir y aplicar una función hash la instrucción de política depende de su lenguaje de programación y plataforma. Para ver código de muestra, consulte [Ejemplos de código para la creación de una firma para una URL firmada](PrivateCFSignatureCodeAndExamples.md).

1. Elimine los espacios vacíos (incluidos tabuladores y caracteres de línea nueva) de la cadena a la que se le ha aplicado una función hash y firmada.

1. Codifique la cadena con codificación base64 de MIME. Para obtener más información, consulte la [Section 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) de *RFC 2045, MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies*.

1. Sustituya caracteres no válidos en una cadena de consulta de URL por caracteres válidos. En la siguiente tabla se muestran los caracteres válidos y no válidos.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonCloudFront/latest/DeveloperGuide/private-content-setting-signed-cookie-custom-policy.html)

1. Incluya el valor resultante en el encabezado `Set-Cookie`, en el par nombre-valor `CloudFront-Signature=`, y vuelva a [Para establecer cookies firmadas mediante una política personalizada](#private-content-setting-signed-cookie-custom-policy-procedure) para añadir el encabezado `Set-Cookie` en `CloudFront-Key-Pair-Id`.

# Create signed cookies using PHP
<a name="signed-cookies-PHP"></a>

El siguiente ejemplo de código es similar al ejemplo de [Crear una firma de URL con PHP](CreateURL_PHP.md) en el sentido de que crea un enlace a un video. Sin embargo, en lugar de firmar la URL en el código, en este ejemplo se firman las cookies con la función `create_signed_cookies()`. El reproductor del cliente utiliza las cookies para autenticar cada solicitud a la distribución de CloudFront.

Este enfoque resulta útil para transmitir contenido, como HTTP Live Streaming (HLS) o la transmisión dinámica adaptativa a través de HTTP (DASH), donde el cliente debe realizar varias solicitudes para recuperar el manifiesto, los segmentos y los activos de reproducción relacionados. Al usar cookies firmadas, el cliente puede autenticar cada solicitud sin necesidad de generar una nueva URL firmada para cada segmento. 

**nota**  
Crear una firma de URL es solo una parte del proceso de entrega de contenido privado mediante cookies firmadas. Para obtener más información, consulte [Uso de cookies firmadas](private-content-signed-cookies.md).



**Topics**
+ [Creación de la firma RSA SHA-1](#create-rsa-sha-1signature-cookies)
+ [Creación de cookies firmadas](#create-the-signed-cookie)
+ [Código completo](#full-code-signed-cookies)

En las siguientes secciones, se desglosa el ejemplo de código en partes individuales. A continuación, encontrará el [ejemplo de código](#full-code-signed-cookies) completo.

## Creación de la firma RSA SHA-1
<a name="create-rsa-sha-1signature-cookies"></a>

Este ejemplo de código hace lo siguiente:

1. La función `rsa_sha1_sign` proporciona hashes y firma la instrucción de política. Los argumentos requeridos son una instrucción de política y la clave privada que corresponde a una clave pública que está en un grupo de claves de confianza para la distribución.

1. A continuación, la función `url_safe_base64_encode` crea una versión de la firma de URL segura.

   ```
   function rsa_sha1_sign($policy, $private_key_filename) {
       $signature = "";
       $fp = fopen($private_key_filename, "r");
       $priv_key = fread($fp, 8192);
       fclose($fp);
       $pkeyid = openssl_get_privatekey($priv_key);
       openssl_sign($policy, $signature, $pkeyid);
       openssl_free_key($pkeyid);
       return $signature;
   }
   
   function url_safe_base64_encode($value) {
       $encoded = base64_encode($value);
       return str_replace(
           array('+', '=', '/'),
           array('-', '_', '~'),
           $encoded);
   }
   ```

## Creación de cookies firmadas
<a name="create-the-signed-cookie"></a>

El siguiente código crea las cookies firmadas con los siguientes atributos de cookie: `CloudFront-Expires`, `CloudFront-Signature` y `CloudFront-Key-Pair-Id`. El código usa una política personalizada.

```
function create_signed_cookies($resource, $private_key_filename, $key_pair_id, $expires, $client_ip = null) {
    $policy = array(
        'Statement' => array(
            array(
                'Resource' => $resource,
                'Condition' => array(
                    'DateLessThan' => array('AWS:EpochTime' => $expires)
                )
            )
        )
    );

    if ($client_ip) {
        $policy['Statement'][0]['Condition']['IpAddress'] = array('AWS:SourceIp' => $client_ip . '/32');
    }

    $policy = json_encode($policy);
    $encoded_policy = url_safe_base64_encode($policy);
    $signature = rsa_sha1_sign($policy, $private_key_filename);
    $encoded_signature = url_safe_base64_encode($signature);

    return array(
        'CloudFront-Policy' => $encoded_policy,
        'CloudFront-Signature' => $encoded_signature,
        'CloudFront-Key-Pair-Id' => $key_pair_id
    );
}
```

Para obtener más información, consulte [Establecimiento de cookies firmadas mediante una política personalizada](private-content-setting-signed-cookie-custom-policy.md).

## Código completo
<a name="full-code-signed-cookies"></a>

El siguiente ejemplo de código proporciona una demostración completa de la creación de cookies firmadas de CloudFront con PHP. Puede descargar el ejemplo completo desde el archivo [demo-php.zip](samples/demo-php.zip).

En el siguiente ejemplo, puede modificar el elemento `$policy Condition` para permitir los rangos de direcciones IPv4 e IPv6. Para ver un ejemplo, consulte [Uso de direcciones IPv6 en políticas de IAM](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ipv6-access.html#ipv6-access-iam) en la *Guía del usuario de Amazon Simple Storage Service*.

```
<?php

function rsa_sha1_sign($policy, $private_key_filename) {
    $signature = "";
    $fp = fopen($private_key_filename, "r");
    $priv_key = fread($fp, 8192);
    fclose($fp);
    $pkeyid = openssl_get_privatekey($priv_key);
    openssl_sign($policy, $signature, $pkeyid);
    openssl_free_key($pkeyid);
    return $signature;
}

function url_safe_base64_encode($value) {
    $encoded = base64_encode($value);
    return str_replace(
        array('+', '=', '/'),
        array('-', '_', '~'),
        $encoded);
}

function create_signed_cookies($resource, $private_key_filename, $key_pair_id, $expires, $client_ip = null) {
    $policy = array(
        'Statement' => array(
            array(
                'Resource' => $resource,
                'Condition' => array(
                    'DateLessThan' => array('AWS:EpochTime' => $expires)
                )
            )
        )
    );

    if ($client_ip) {
        $policy['Statement'][0]['Condition']['IpAddress'] = array('AWS:SourceIp' => $client_ip . '/32');
    }

    $policy = json_encode($policy);
    $encoded_policy = url_safe_base64_encode($policy);
    $signature = rsa_sha1_sign($policy, $private_key_filename);
    $encoded_signature = url_safe_base64_encode($signature);

    return array(
        'CloudFront-Policy' => $encoded_policy,
        'CloudFront-Signature' => $encoded_signature,
        'CloudFront-Key-Pair-Id' => $key_pair_id
    );
}



$private_key_filename = '/home/test/secure/example-priv-key.pem';
$key_pair_id = 'K2JCJMDEHXQW5F';
$base_url = 'https://d1234.cloudfront.net';

$expires = time() + 3600; // 1 hour from now

// Get the viewer real IP from the x-forward-for header as $_SERVER['REMOTE_ADDR'] will return viewer facing IP. An alternative option is to use CloudFront-Viewer-Address header. Note that this header is a trusted CloudFront immutable header. Example format: IP:PORT ("CloudFront-Viewer-Address": "1.2.3.4:12345")
$client_ip = $_SERVER['HTTP_X_FORWARDED_FOR'];


// For HLS manifest and segments (using wildcard)
$hls_resource = $base_url . '/sign/*';
$signed_cookies = create_signed_cookies($hls_resource, $private_key_filename, $key_pair_id, $expires, $client_ip);

// Set the cookies
$cookie_domain = parse_url($base_url, PHP_URL_HOST);
foreach ($signed_cookies as $name => $value) {
    setcookie($name, $value, $expires, '/', $cookie_domain, true, true);
}

?>

<!DOCTYPE html>
<html>
<head>
    <title>CloudFront Signed HLS Stream with Cookies</title>
</head>
<body>
    <h1>Amazon CloudFront Signed HLS Stream with Cookies</h1>
    <h2>Expires at <?php echo gmdate('Y-m-d H:i:s T', $expires); ?> only viewable by IP <?php echo $client_ip; ?></h2>
    
    <div id='hls-video'>
        <video id="video" width="640" height="360" controls></video>
    </div>

    <script src="https://cdn.jsdelivr.net/npm/hls.js@latest"></script>
    <script>
        var video = document.getElementById('video');
        var manifestUrl = '<?php echo $base_url; ?>/sign/manifest.m3u8';
        
        if (Hls.isSupported()) {
            var hls = new Hls();
            hls.loadSource(manifestUrl);
            hls.attachMedia(video);
        }
        else if (video.canPlayType('application/vnd.apple.mpegurl')) {
            video.src = manifestUrl;
        }
    </script>
</body>
</html>
```

En lugar de utilizar cookies firmadas, puede utilizar URL firmadas. Para obtener más información, consulte [Crear una firma de URL con PHP](CreateURL_PHP.md).

# Comandos de Linux y OpenSSL para codificación y cifrado base64
<a name="private-content-linux-openssl"></a>

Utilice los siguientes comandos de línea de comandos de Linux y OpenSSL para aplicar una función hash y firmar la instrucción de política, codificar la firma con base64 y sustituir caracteres que no sean válidos en los parámetros de cadenas de consulta de URL por caracteres válidos.

Para obtener información acerca de OpenSSL, consulte [https://www.openssl.org](https://www.openssl.org).

```
cat policy | tr -d "\n" | tr -d " \t\n\r" | openssl sha1 -sign private_key.pem | openssl base64 -A | tr -- '+=/' '-_~'
```

En el comando anterior:
+ `cat` lee el archivo `policy`.
+ `tr -d "\n" | tr -d " \t\n\r"` elimina los espacios vacíos y el carácter de nueva línea agregados por `cat`.
+ OpenSSL codifica el archivo con el hash SHA-1 y lo firma con el archivo de clave privada `private_key.pem`. La firma de clave privada puede ser RSA 2048 o ECDSA 256.
+ OpenSSL codifica en base64 la instrucción de política a la que se le ha aplicado una función hash y que se ha firmado.
+ `tr` sustituye los caracteres no válidos de los parámetros de cadenas de consulta de URL por caracteres válidos.

Para consultar más ejemplos de código que demuestren la creación de una firma, consulte [Ejemplos de código para la creación de una firma para una URL firmada](PrivateCFSignatureCodeAndExamples.md).

# Ejemplos de código para la creación de una firma para una URL firmada
<a name="PrivateCFSignatureCodeAndExamples"></a>

En esta sección se incluyen ejemplos de aplicación descargables en los que se muestra cómo crear firmas para URL firmadas. Los ejemplos están disponibles en Perl, PHP, C \$1 y Java. Puede utilizar cualquiera de los ejemplos para crear URL firmadas. El script Perl se ejecuta en plataformas Linux y macOS. El ejemplo de PHP funcionará en cualquier servidor que ejecute PHP. El ejemplo de C \$1 utiliza .NET Framework.

Para obtener un código de ejemplo en JavaScript (Node.js), consulte [Creación de URL firmadas de Amazon CloudFront en Node.js](https://aws.amazon.com/blogs/developer/creating-amazon-cloudfront-signed-urls-in-node-js/) en el blog para desarrolladores de AWS.

Para obtener un código de ejemplo en Python, consulte [Generar una URL firmada para Amazon CloudFront](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/cloudfront.html#examples) en la *Referencia de la API de AWS SDK para Python (Boto3)* y [este código de ejemplo](https://github.com/boto/boto3/blob/develop/boto3/examples/cloudfront.rst) en el repositorio GitHub de Boto3.

**Topics**
+ [Crear una firma de URL con Perl](CreateURLPerl.md)
+ [Crear una firma de URL con PHP](CreateURL_PHP.md)
+ [Crear una firma de URL mediante C\$1 y .NET Framework](CreateSignatureInCSharp.md)
+ [Crear una firma de URL con Java](CFPrivateDistJavaDevelopment.md)

# Crear una firma de URL con Perl
<a name="CreateURLPerl"></a>

Esta sección incluye un script Perl para plataformas Linux/Mac que puede utilizar para crear la firma para contenido privado. Para crear la firma, ejecute el script con argumentos de línea de comandos que especifiquen la URL de CloudFront, la ruta a la clave privada del signatario, el ID de la clave y una fecha de vencimiento de la URL. La herramienta también puede decodificar URL firmadas. 

**nota**  
Crear una firma de URL es solo una parte del proceso de entrega de contenido privado mediante una URL firmada. Para obtener más información acerca del proceso completo, consulte [Uso de URL firmadas](private-content-signed-urls.md). 

**Topics**
+ [Código fuente del script Perl para crear una URL firmada](#CreateURLPerlScriptSource)

## Código fuente del script Perl para crear una URL firmada
<a name="CreateURLPerlScriptSource"></a>

El siguiente código fuente Perl puede utilizarse para crear una URL firmada para CloudFront. Los comentarios del código incluyen información acerca de los conmutadores de las líneas de comandos y las características de la herramienta.

```
#!/usr/bin/perl -w

# Copyright 2008 Amazon Technologies, Inc.  Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License. You may obtain a copy of the License at:
#
# https://aws.amazon.com/apache2.0
#
# This file is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and limitations under the License.

=head1 cfsign.pl

cfsign.pl - A tool to generate and verify Amazon CloudFront signed URLs

=head1 SYNOPSIS

This script uses an existing RSA key pair to sign and verify Amazon CloudFront signed URLs

View the script source for details as to which CPAN packages are required beforehand. 

For help, try:

cfsign.pl --help

URL signing examples:

cfsign.pl --action encode --url https://images.my-website.com/gallery1.zip --policy sample_policy.json --private-key privkey.pem --key-pair-id mykey

cfsign.pl --action encode --url https://images.my-website.com/gallery1.zip --expires 1257439868 --private-key privkey.pem --key-pair-id mykey

URL decode example:

cfsign.pl --action decode --url "http//mydist.cloudfront.net/?Signature=AGO-PgxkYo99MkJFHvjfGXjG1QDEXeaDb4Qtzmy85wqyJjK7eKojQWa4BCRcow__&Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cDovLypicmFkbS5qcGciLCJDb25kaXRpb24iOnsiSXBBZGRyZXNzIjp7IkFXUzpTb3VyY2VJcCI6IjEwLjUyLjE3LjkvMCJ9LCJEYXRlR3JlYXRlclRoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTI1MjUyMDgzMH19fV19Cg__&Key-Pair-Id=mykey"


To generate an RSA key pair, you can use openssl and the following commands:

# Generate a 2048 bit key pair
openssl genrsa -out private-key.pem 2048
openssl rsa -in private-key.pem -pubout -out public-key.pem


=head1 OPTIONS

=over 8

=item B<--help>

Print a help message and exits.

=item B<--action> [action]

The action to execute.  action can be one of:

  encode - Generate a signed URL (using a canned policy or a user policy)
  decode - Decode a signed URL

=item B<--url>

The URL to en/decode

=item B<--stream>

The stream to en/decode

=item B<--private-key>

The path to your private key.

=item B<--key-pair-id>

The key pair identifier.

=item B<--policy>

The CloudFront policy document.

=item B<--expires>

The Unix epoch time when the URL is to expire. If both this option and
the --policy option are specified, --policy will be used. Otherwise, this 
option alone will use a canned policy.

=back

=cut

use strict;
use warnings;

# you might need to use CPAN to get these modules.
# run perl -MCPAN -e "install <module>" to get them.
# The openssl command line will also need to be in your $PATH.
use File::Temp qw/tempfile/;
use File::Slurp;
use Getopt::Long;
use IPC::Open2;
use MIME::Base64 qw(encode_base64 decode_base64);
use Pod::Usage;
use URI;

my $CANNED_POLICY 
    = '{"Statement":[{"Resource":"<RESOURCE>","Condition":{"DateLessThan":{"AWS:EpochTime":<EXPIRES>}}}]}';

my $POLICY_PARAM      = "Policy";
my $EXPIRES_PARAM     = "Expires";
my $SIGNATURE_PARAM   = "Signature";
my $KEY_PAIR_ID_PARAM = "Key-Pair-Id";

my $verbose = 0;
my $policy_filename = "";
my $expires_epoch = 0;
my $action = "";
my $help = 0;
my $key_pair_id = "";
my $url = "";
my $stream = "";
my $private_key_filename = "";

my $result = GetOptions("action=s"      => \$action,
                        "policy=s"      => \$policy_filename,
                        "expires=i"     => \$expires_epoch,
                        "private-key=s" => \$private_key_filename,
                        "key-pair-id=s" => \$key_pair_id,
                        "verbose"       => \$verbose,
                        "help"          => \$help,
                        "url=s"         => \$url,
                        "stream=s"      => \$stream,
                    );

if ($help or !$result) {
    pod2usage(1);
    exit;
}

if ($url eq "" and $stream eq "") {
    print STDERR "Must include a stream or a URL to encode or decode with the --stream or --url option\n";
    exit;
}

if ($url ne "" and $stream ne "") {
    print STDERR "Only one of --url and --stream may be specified\n";
    exit;
}

if ($url ne "" and !is_url_valid($url)) {
    exit;
}

if ($stream ne "") {
    exit unless is_stream_valid($stream);

    # The signing mechanism is identical, so from here on just pretend we're
    # dealing with a URL
    $url = $stream;
} 

if ($action eq "encode") {
    # The encode action will generate a private content URL given a base URL, 
    # a policy file (or an expires timestamp) and a key pair id parameter
    my $private_key;
    my $public_key;
    my $public_key_file;
    
    my $policy;
    if ($policy_filename eq "") {
        if ($expires_epoch == 0) {
            print STDERR "Must include policy filename with --policy argument or an expires" . 
                          "time using --expires\n";            
        }
        
        $policy = $CANNED_POLICY;
        $policy =~ s/<EXPIRES>/$expires_epoch/g;
        $policy =~ s/<RESOURCE>/$url/g;
    } else {
        if (! -e $policy_filename) {
            print STDERR "Policy file $policy_filename does not exist\n";
            exit;
        }
        $expires_epoch = 0; # ignore if set
        $policy = read_file($policy_filename);
    }

    if ($private_key_filename eq "") {
        print STDERR "You must specific the path to your private key file with --private-key\n";
        exit;
    }

    if (! -e $private_key_filename) {
        print STDERR "Private key file $private_key_filename does not exist\n";
        exit;
    }

    if ($key_pair_id eq "") {
        print STDERR "You must specify a key pair id with --key-pair-id\n";
        exit;
    }

    my $encoded_policy = url_safe_base64_encode($policy);
    my $signature = rsa_sha1_sign($policy, $private_key_filename);
    my $encoded_signature = url_safe_base64_encode($signature);

    my $generated_url = create_url($url, $encoded_policy, $encoded_signature, $key_pair_id, $expires_epoch);


    if ($stream ne "") {
        print "Encoded stream (for use within a swf):\n" . $generated_url . "\n";
        print "Encoded and escaped stream (for use on a webpage):\n" .  escape_url_for_webpage($generated_url) . "\n"; 
    } else {
        print "Encoded URL:\n" . $generated_url . "\n";
    }
} elsif ($action eq "decode") {
    my $decoded = decode_url($url);
    if (!$decoded) {
        print STDERR "Improperly formed URL\n";
        exit;
    }

    print_decoded_url($decoded);
} else {
    # No action specified, print help.  But only if this is run as a program (caller will be empty)
    pod2usage(1) unless caller();
}

# Decode a private content URL into its component parts
sub decode_url {
    my $url = shift;

    if ($url =~ /(.*)\?(.*)/) {
        my $base_url = $1;
        my $params = $2;

        my @unparsed_params = split(/&/, $params);
        my %params = ();
        foreach my $param (@unparsed_params) {
            my ($key, $val) = split(/=/, $param);
            $params{$key} = $val;
        }

        my $encoded_signature = "";
        if (exists $params{$SIGNATURE_PARAM}) {
            $encoded_signature = $params{"Signature"};
        } else {
            print STDERR "Missing Signature URL parameter\n";
            return 0;
        }

        my $encoded_policy = "";
        if (exists $params{$POLICY_PARAM}) {
            $encoded_policy = $params{$POLICY_PARAM};
        } else {
            if (!exists $params{$EXPIRES_PARAM}) {
                print STDERR "Either the Policy or Expires URL parameter needs to be specified\n";
                return 0;    
            }
            
            my $expires = $params{$EXPIRES_PARAM};
            
            my $policy = $CANNED_POLICY;
            $policy =~ s/<EXPIRES>/$expires/g;
            
            my $url_without_cf_params = $url;
            $url_without_cf_params =~ s/$SIGNATURE_PARAM=[^&]*&?//g;
            $url_without_cf_params =~ s/$POLICY_PARAM=[^&]*&?//g;
            $url_without_cf_params =~ s/$EXPIRES_PARAM=[^&]*&?//g;
            $url_without_cf_params =~ s/$KEY_PAIR_ID_PARAM=[^&]*&?//g;
            
            if ($url_without_cf_params =~ /(.*)\?$/) {
                $url_without_cf_params = $1;
            }
            
            $policy =~ s/<RESOURCE>/$url_without_cf_params/g;
            
            $encoded_policy = url_safe_base64_encode($policy);
        }

        my $key = "";
        if (exists $params{$KEY_PAIR_ID_PARAM}) {
            $key = $params{$KEY_PAIR_ID_PARAM};
        } else {
            print STDERR "Missing $KEY_PAIR_ID_PARAM parameter\n";
            return 0;
        }

        my $policy = url_safe_base64_decode($encoded_policy);

        my %ret = ();
        $ret{"base_url"} = $base_url;
        $ret{"policy"} = $policy;
        $ret{"key"} = $key;

        return \%ret;
    } else {
        return 0;
    }
}

# Print a decoded URL out
sub print_decoded_url {
    my $decoded = shift;

    print "Base URL: \n" . $decoded->{"base_url"} . "\n";
    print "Policy: \n" . $decoded->{"policy"} . "\n";
    print "Key: \n" . $decoded->{"key"} . "\n";
}

# Encode a string with base 64 encoding and replace some invalid URL characters
sub url_safe_base64_encode {
    my ($value) = @_;

    my $result = encode_base64($value);
    $result =~ tr|+=/|-_~|;

    return $result;
}

# Decode a string with base 64 encoding.  URL-decode the string first
# followed by reversing any special character ("+=/") translation.
sub url_safe_base64_decode {
    my ($value) = @_;

    $value =~ s/%([0-9A-Fa-f]{2})/chr(hex($1))/eg;
    $value =~ tr|-_~|+=/|;

    my $result = decode_base64($value);

    return $result;
}

# Create a private content URL
sub create_url {
    my ($path, $policy, $signature, $key_pair_id, $expires) = @_;
    
    my $result;
    my $separator = $path =~ /\?/ ? '&' : '?';
    if ($expires) {
        $result = "$path$separator$EXPIRES_PARAM=$expires&$SIGNATURE_PARAM=$signature&$KEY_PAIR_ID_PARAM=$key_pair_id";
    } else {
        $result = "$path$separator$POLICY_PARAM=$policy&$SIGNATURE_PARAM=$signature&$KEY_PAIR_ID_PARAM=$key_pair_id";
    }
    $result =~ s/\n//g;

    return $result;
}

# Sign a document with given private key file.
# The first argument is the document to sign
# The second argument is the name of the private key file
sub rsa_sha1_sign {
    my ($to_sign, $pvkFile) = @_;
    print "openssl sha1 -sign $pvkFile $to_sign\n";

    return write_to_program($pvkFile, $to_sign);
}

# Helper function to write data to a program
sub write_to_program {
my ($keyfile, $data) = @_;
unlink "temp_policy.dat" if (-e "temp_policy.dat");
unlink "temp_sign.dat" if (-e "temp_sign.dat");

write_file("temp_policy.dat", $data);

system("openssl dgst -sha1 -sign \"$keyfile\" -out temp_sign.dat temp_policy.dat");

my $output = read_file("temp_sign.dat");

    return $output;
}

# Read a file into a string and return the string
sub read_file {
    my ($file) = @_;

    open(INFILE, "<$file") or die("Failed to open $file: $!");
    my $str = join('', <INFILE>);
    close INFILE;

    return $str;
}

sub is_url_valid {
    my ($url) = @_;

    # HTTP distributions start with http[s]:// and are the correct thing to sign
    if ($url =~ /^https?:\/\//) {
        return 1;
    } else {
        print STDERR "CloudFront requires absolute URLs for HTTP distributions\n";
        return 0;
    }
}

sub is_stream_valid {
    my ($stream) = @_;

    if ($stream =~ /^rtmp:\/\// or $stream =~ /^\/?cfx\/st/) {
        print STDERR "Streaming distributions require that only the stream name is signed.\n";
        print STDERR "The stream name is everything after, but not including, cfx/st/\n";
        return 0;
    } else {
        return 1;
    }
}

# flash requires that the query parameters in the stream name are url
# encoded when passed in through javascript, etc.  This sub handles the minimal
# required url encoding.
sub escape_url_for_webpage {
    my ($url) = @_;

    $url =~ s/\?/%3F/g;
    $url =~ s/=/%3D/g;
    $url =~ s/&/%26/g;

    return $url;
}

1;
```

# Crear una firma de URL con PHP
<a name="CreateURL_PHP"></a>

Cualquier servidor web que ejecute PHP puede utilizar este código de ejemplo de PHP para crear instrucciones de política y firmas para distribuciones de CloudFront privadas. El ejemplo completo crea una página web que funciona con enlaces de URL firmadas que reproducen una secuencia de vídeo mediante streaming de CloudFront. Puede descargar el ejemplo completo desde el archivo [demo-php.zip](samples/demo-php.zip).

**Notas**  
Crear una firma de URL es solo una parte del proceso de entrega de contenido privado mediante una URL firmada. Para obtener más información acerca de todo el proceso, consulte [Uso de URL firmadas](private-content-signed-urls.md). 
También puede crear URL firmadas mediante la clase `UrlSigner` en AWS SDK para PHP. Para obtener más información, consulte [Class UrlSigner](https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.CloudFront.UrlSigner.html) en la *Referencia de la API de AWS SDK para PHP*.

**Topics**
+ [Creación de la firma RSA SHA-1](#sample-rsa-sign)
+ [Creación de una política predefinida](#sample-canned-policy)
+ [Crear una política personalizada](#sample-custom-policy)
+ [Ejemplo de código completo](#full-example)

En las siguientes secciones, se desglosa el ejemplo de código en partes individuales. A continuación, puede encontrar [Ejemplo de código completo](#full-example).

## Creación de la firma RSA SHA-1
<a name="sample-rsa-sign"></a>

Este ejemplo de código hace lo siguiente:
+ La función `rsa_sha1_sign` proporciona hashes y firma la instrucción de política. Los argumentos requeridos son una instrucción de política y la clave privada que corresponde a una clave pública que está en un grupo de claves de confianza para la distribución. 
+ A continuación, la función `url_safe_base64_encode` crea una versión de la firma de URL segura.

```
function rsa_sha1_sign($policy, $private_key_filename) {
    $signature = "";

    // load the private key
    $fp = fopen($private_key_filename, "r");
    $priv_key = fread($fp, 8192);
    fclose($fp);
    $pkeyid = openssl_get_privatekey($priv_key);

    // compute signature
    openssl_sign($policy, $signature, $pkeyid);

    // free the key from memory
    openssl_free_key($pkeyid);

    return $signature;
}

function url_safe_base64_encode($value) {
    $encoded = base64_encode($value);
    // replace unsafe characters +, = and / with 
    // the safe characters -, _ and ~
    return str_replace(
        array('+', '=', '/'),
        array('-', '_', '~'),
        $encoded);
}
```

El siguiente fragmento de código utiliza las funciones `get_canned_policy_stream_name()` y `get_custom_policy_stream_name()` para crear una política predefinida y personalizada. CloudFront utiliza las políticas para crear la URL para el streaming del video, incluida la especificación de la hora de vencimiento. 

A continuación, puede utilizar una política predefinida o una política personalizada para determinar cómo administrar el acceso a su contenido. Para obtener información sobre cuál elegir, consulte la sección [Decisión de utilizar políticas predefinidas o personalizadas para URL firmadas](private-content-signed-urls.md#private-content-choosing-canned-custom-policy).

## Creación de una política predefinida
<a name="sample-canned-policy"></a>

El siguiente código de ejemplo crea una instrucción de política *predefinida* para la firma. 

**nota**  
La variable `$expires` es una marca temporal fecha/hora que debe ser un número entero, no una cadena.

```
function get_canned_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $expires) {
    // this policy is well known by CloudFront, but you still need to sign it, since it contains your parameters
    $canned_policy = '{"Statement":[{"Resource":"' . $video_path . '","Condition":{"DateLessThan":{"AWS:EpochTime":'. $expires . '}}}]}';
    // the policy contains characters that cannot be part of a URL, so we base64 encode it
    $encoded_policy = url_safe_base64_encode($canned_policy);
    // sign the original policy, not the encoded version
    $signature = rsa_sha1_sign($canned_policy, $private_key_filename);
    // make the signature safe to be included in a URL
    $encoded_signature = url_safe_base64_encode($signature);

    // combine the above into a stream name
    $stream_name = create_stream_name($video_path, null, $encoded_signature, $key_pair_id, $expires);
    // URL-encode the query string characters
    return $stream_name;
}
```

Para obtener más información acerca de políticas predefinidas, consulte [Creación de una URL firmada mediante una política predefinida](private-content-creating-signed-url-canned-policy.md).

## Crear una política personalizada
<a name="sample-custom-policy"></a>

El siguiente código de ejemplo crea una instrucción de política *personalizada* para la firma. 

```
function get_custom_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $policy) {
    // the policy contains characters that cannot be part of a URL, so we base64 encode it
    $encoded_policy = url_safe_base64_encode($policy);
    // sign the original policy, not the encoded version
    $signature = rsa_sha1_sign($policy, $private_key_filename);
    // make the signature safe to be included in a URL
    $encoded_signature = url_safe_base64_encode($signature);

    // combine the above into a stream name
    $stream_name = create_stream_name($video_path, $encoded_policy, $encoded_signature, $key_pair_id, null);
    // URL-encode the query string characters
    return $stream_name;
}
```

Para obtener más información acerca de políticas personalizadas, consulte [Creación de una URL firmada mediante una política personalizada](private-content-creating-signed-url-custom-policy.md).

## Ejemplo de código completo
<a name="full-example"></a>

El siguiente código de muestra proporciona una demostración completa de la creación de URL firmadas de CloudFront con PHP. Puede descargar el ejemplo completo desde el archivo [demo-php.zip](samples/demo-php.zip).

En el siguiente ejemplo, puede modificar el elemento `$policy` de `Condition` para permitir los rangos de direcciones IPv4 () e IPv6. Para ver un ejemplo, consulte [Uso de direcciones IPv6 en políticas de IAM](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ipv6-access.html#ipv6-access-iam) en la *Guía del usuario de Amazon Simple Storage Service*.

```
<?php

function rsa_sha1_sign($policy, $private_key_filename) {
    $signature = "";

    // load the private key
    $fp = fopen($private_key_filename, "r");
    $priv_key = fread($fp, 8192);
    fclose($fp);
    $pkeyid = openssl_get_privatekey($priv_key);

    // compute signature
    openssl_sign($policy, $signature, $pkeyid);

    // free the key from memory
    openssl_free_key($pkeyid);

    return $signature;
}

function url_safe_base64_encode($value) {
    $encoded = base64_encode($value);
    // replace unsafe characters +, = and / with the safe characters -, _ and ~
    return str_replace(
        array('+', '=', '/'),
        array('-', '_', '~'),
        $encoded);
}

function create_stream_name($stream, $policy, $signature, $key_pair_id, $expires) {
    $result = $stream;
    // if the stream already contains query parameters, attach the new query parameters to the end
    // otherwise, add the query parameters
    $separator = strpos($stream, '?') == FALSE ? '?' : '&';
    // the presence of an expires time means we're using a canned policy
    if($expires) {
        $result .= $separator . "Expires=" . $expires . "&Signature=" . $signature . "&Key-Pair-Id=" . $key_pair_id;
    }
    // not using a canned policy, include the policy itself in the stream name
    else {
        $result .= $separator . "Policy=" . $policy . "&Signature=" . $signature . "&Key-Pair-Id=" . $key_pair_id;
    }

    // new lines would break us, so remove them
    return str_replace('\n', '', $result);
}


function get_canned_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $expires) {
    // this policy is well known by CloudFront, but you still need to sign it, since it contains your parameters
    $canned_policy = '{"Statement":[{"Resource":"' . $video_path . '","Condition":{"DateLessThan":{"AWS:EpochTime":'. $expires . '}}}]}';
    // the policy contains characters that cannot be part of a URL, so we base64 encode it
    $encoded_policy = url_safe_base64_encode($canned_policy);
    // sign the original policy, not the encoded version
    $signature = rsa_sha1_sign($canned_policy, $private_key_filename);
    // make the signature safe to be included in a URL
    $encoded_signature = url_safe_base64_encode($signature);

    // combine the above into a stream name
    $stream_name = create_stream_name($video_path, null, $encoded_signature, $key_pair_id, $expires);
    // URL-encode the query string characters
    return $stream_name;
}

function get_custom_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $policy) {
    // the policy contains characters that cannot be part of a URL, so we base64 encode it
    $encoded_policy = url_safe_base64_encode($policy);
    // sign the original policy, not the encoded version
    $signature = rsa_sha1_sign($policy, $private_key_filename);
    // make the signature safe to be included in a URL
    $encoded_signature = url_safe_base64_encode($signature);

    // combine the above into a stream name
    $stream_name = create_stream_name($video_path, $encoded_policy, $encoded_signature, $key_pair_id, null);
    // URL-encode the query string characters
    return $stream_name;
}


// Path to your private key.  Be very careful that this file is not accessible
// from the web!

$private_key_filename = '/home/test/secure/example-priv-key.pem';
$key_pair_id = 'K2JCJMDEHXQW5F';

// Make sure you have "Restrict viewer access" enabled on this path behaviour and using the above Trusted key groups (recommended).
$video_path = 'https://example.com/secure/example.mp4';

$expires = time() + 300; // 5 min from now
$canned_policy_stream_name = get_canned_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $expires);

// Get the viewer real IP from the x-forward-for header as $_SERVER['REMOTE_ADDR'] will return viewer facing IP. An alternative option is to use CloudFront-Viewer-Address header. Note that this header is a trusted CloudFront immutable header. Example format: IP:PORT ("CloudFront-Viewer-Address": "1.2.3.4:12345")
$client_ip = $_SERVER['HTTP_X_FORWARDED_FOR'];
$policy =
'{'.
    '"Statement":['.
        '{'.
            '"Resource":"'. $video_path . '",'.
            '"Condition":{'.
                '"IpAddress":{"AWS:SourceIp":"' . $client_ip . '/32"},'.
                '"DateLessThan":{"AWS:EpochTime":' . $expires . '}'.
            '}'.
        '}'.
    ']' .
    '}';
$custom_policy_stream_name = get_custom_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $policy);

?>

<html>

<head>
    <title>CloudFront</title>
</head>

<body>
    <h1>Amazon CloudFront</h1>
    <h2>Canned Policy</h2>
    <h3>Expires at <?php echo gmdate('Y-m-d H:i:s T', $expires); ?></h3>
    <br />

    <div id='canned'>The canned policy video will be here: <br>
    
        <video width="640" height="360" autoplay muted controls>
        <source src="<?php echo $canned_policy_stream_name; ?>" type="video/mp4">
        Your browser does not support the video tag.
        </video>
    </div>

    <h2>Custom Policy</h2>
    <h3>Expires at <?php echo gmdate('Y-m-d H:i:s T', $expires); ?> only viewable by IP <?php echo $client_ip; ?></h3>
    <div id='custom'>The custom policy video will be here: <br>

         <video width="640" height="360" autoplay muted controls>
         <source src="<?php echo $custom_policy_stream_name; ?>" type="video/mp4">
         Your browser does not support the video tag.
        </video>
    </div> 

</body>

</html>
```

Para obtener ejemplos adicionales de firmas de URL, consulte los siguientes temas:
+ [Crear una firma de URL con Perl](CreateURLPerl.md)
+ [Crear una firma de URL mediante C\$1 y .NET Framework](CreateSignatureInCSharp.md)
+ [Crear una firma de URL con Java](CFPrivateDistJavaDevelopment.md)

En lugar de utilizar URL firmadas para crear la firma, puede utilizar cookies firmadas. Para obtener más información, consulte [Create signed cookies using PHP](signed-cookies-PHP.md).

# Crear una firma de URL mediante C\$1 y .NET Framework
<a name="CreateSignatureInCSharp"></a>

Los ejemplos de C\$1 de esta sección implementan una aplicación de ejemplo que muestra cómo crear las firmas para distribuciones privadas de CloudFront mediante instrucciones de políticas predefinidas y personalizadas. Los ejemplos incluyen funciones de utilidad basadas en el [AWS SDK para .NET](https://aws.amazon.com/sdkfornet) que pueden resultar útiles en aplicaciones .NET.

También puede crear URL firmadas y cookies firmadas mediante SDK para .NET. En la *Referencia de la API SDK para .NET*, consulte los siguientes temas:
+ **URL firmadas**: [AmazonCloudFrontUrlSigner](https://docs.aws.amazon.com/sdkfornet/v3/apidocs/items/CloudFront/TCloudFrontUrlSigner.html) 
+ **Cookies firmadas**: [AmazonCloudFrontCookieSigner](https://docs.aws.amazon.com/sdkfornet/v3/apidocs/items/CloudFront/TCloudFrontCookieSigner.html) 

Para descargar el código, diríjase a [Código de firma en C\$1](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/samples/AWS_PrivateCF_Distributions.zip).

**Notas**  
Las clases `AmazonCloudFrontUrlSigner` y `AmazonCloudFrontCookieSigner` se han trasladado a un paquete independiente. Para obtener más información sobre su uso, consulte [CookieSigner and UrlSigner](https://docs.aws.amazon.com/sdk-for-net/v4/developer-guide/net-dg-v4.html#net-dg-v4-CookieSigner-UrlSigner) en la *Guía para desarrolladores de AWS SDK para .NET (V4)*. 
Crear una firma de URL es solo una parte del proceso de entrega de contenido privado mediante una URL firmada. Para obtener más información, consulte [Uso de URL firmadas](private-content-signed-urls.md). Para obtener más información sobre el uso de cookies firmadas, consulte [Uso de cookies firmadas](private-content-signed-cookies.md).

## Uso de una clave RSA en .NET Framework
<a name="rsa-key-sdk-net"></a>

Para utilizar una clave RSA en .NET Framework, debe convertir el archivo.pem suministrado por AWS al formato XML que utiliza el .NET Framework.

Después de la conversión, el archivo de clave privada RSA estará en el siguiente formato:

**Example Clave privada RSA en formato XML de .NET Framework**  <a name="RSAPrivateKeyXML.NETFrameworkFormat"></a>

```
<RSAKeyValue>
  <Modulus>
    wO5IvYCP5UcoCKDo1dcspoMehWBZcyfs9QEzGi6Oe5y+ewGr1oW+vB2GPB
    ANBiVPcUHTFWhwaIBd3oglmF0lGQljP/jOfmXHUK2kUUnLnJp+oOBL2NiuFtqcW6h/L5lIpD8Yq+NRHg
    Ty4zDsyr2880MvXv88yEFURCkqEXAMPLE=
  </Modulus>
  <Exponent>AQAB</Exponent>
  <P>
    5bmKDaTz
    npENGVqz4Cea8XPH+sxt+2VaAwYnsarVUoSBeVt8WLloVuZGG9IZYmH5KteXEu7fZveYd9UEXAMPLE==
  </P>
  <Q>
    1v9l/WN1a1N3rOK4VGoCokx7kR2SyTMSbZgF9IWJNOugR/WZw7HTnjipO3c9dy1Ms9pUKwUF4
    6d7049EXAMPLE==
  </Q>
  <DP>
    RgrSKuLWXMyBH+/l1Dx/I4tXuAJIrlPyo+VmiOc7b5NzHptkSHEPfR9s1
    OK0VqjknclqCJ3Ig86OMEtEXAMPLE==
  </DP>
  <DQ>
    pjPjvSFw+RoaTu0pgCA/jwW/FGyfN6iim1RFbkT4
    z49DZb2IM885f3vf35eLTaEYRYUHQgZtChNEV0TEXAMPLE==
  </DQ>
  <InverseQ>
    nkvOJTg5QtGNgWb9i
    cVtzrL/1pFEOHbJXwEJdU99N+7sMK+1066DL/HSBUCD63qD4USpnf0myc24in0EXAMPLE==</InverseQ>
  <D>
      Bc7mp7XYHynuPZxChjWNJZIq+A73gm0ASDv6At7F8Vi9r0xUlQe/v0AQS3ycN8QlyR4XMbzMLYk
      3yjxFDXo4ZKQtOGzLGteCU2srANiLv26/imXA8FVidZftTAtLviWQZBVPTeYIA69ATUYPEq0a5u5wjGy
      UOij9OWyuEXAMPLE=
   </D>
</RSAKeyValue>
```

## Método de firma de políticas predefinidas en C\$1
<a name="canned-policy-signed-url-net"></a>

El siguiente código C\$1 crea una URL firmada que utiliza una política predefinida siguiendo los pasos que se indican a continuación:
+ Crea una instrucción de política.
+ La instrucción de política aplica la función hash mediante SHA1 y firma el resultado con RSA y la clave privada cuya clave pública correspondiente se encuentra en un grupo de claves de confianza.
+ Codifica con base64 la instrucción de política a la que se le ha aplicado una función hash y firmada y sustituye caracteres especiales para que la cadena se pueda usar tranquilamente como parámetro de solicitud de URL.
+ Encadena los valores.

Para ver la implementación completa, consulte el ejemplo disponible en [Código de firma en C\$1](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/samples/AWS_PrivateCF_Distributions.zip). 

**nota**  
Se devuelve `keyId` al cargar una clave pública a CloudFront. Para obtener más información, consulte ![\[6\]](http://docs.aws.amazon.com/es_es/AmazonCloudFront/latest/DeveloperGuide/images/callouts/6.png)[&Key-Pair-Id](private-content-creating-signed-url-canned-policy.md).

**Example : método de firma de políticas predefinidas en C\$1**  <a name="ExampleCannedPolicySigningMethod-CSharp"></a>

```
public static string ToUrlSafeBase64String(byte[] bytes)
{
    return System.Convert.ToBase64String(bytes)
        .Replace('+', '-')
        .Replace('=', '_')
        .Replace('/', '~');
}

public static string CreateCannedPrivateURL(string urlString, 
    string durationUnits, string durationNumber, string pathToPolicyStmnt, 
    string pathToPrivateKey, string keyId)
{
    // args[] 0-thisMethod, 1-resourceUrl, 2-seconds-minutes-hours-days 
    // to expiration, 3-numberOfPreviousUnits, 4-pathToPolicyStmnt, 
    // 5-pathToPrivateKey, 6-keyId

    TimeSpan timeSpanInterval = GetDuration(durationUnits, durationNumber);

    // Create the policy statement.
    string strPolicy = CreatePolicyStatement(pathToPolicyStmnt,
        urlString, 
        DateTime.Now, 
        DateTime.Now.Add(timeSpanInterval), 
        "0.0.0.0/0");
    if ("Error!" == strPolicy) return "Invalid time frame." + 
        "Start time cannot be greater than end time.";

    // Copy the expiration time defined by policy statement.
    string strExpiration = CopyExpirationTimeFromPolicy(strPolicy);

    // Read the policy into a byte buffer.
    byte[] bufferPolicy = Encoding.ASCII.GetBytes(strPolicy);

    // Initialize the SHA1CryptoServiceProvider object and hash the policy data.
    using (SHA1CryptoServiceProvider 
        cryptoSHA1 = new SHA1CryptoServiceProvider())
    {
        bufferPolicy = cryptoSHA1.ComputeHash(bufferPolicy);

        // Initialize the RSACryptoServiceProvider object.
        RSACryptoServiceProvider providerRSA = new RSACryptoServiceProvider();
        XmlDocument xmlPrivateKey = new XmlDocument();

        // Load your private key, which you created by converting your 
        // .pem file to the XML format that the .NET framework uses.  
        // Several tools are available. 
        xmlPrivateKey.Load(pathToPrivateKey);

        // Format the RSACryptoServiceProvider providerRSA and 
        // create the signature.
        providerRSA.FromXmlString(xmlPrivateKey.InnerXml);
        RSAPKCS1SignatureFormatter rsaFormatter = 
            new RSAPKCS1SignatureFormatter(providerRSA);
        rsaFormatter.SetHashAlgorithm("SHA1");
        byte[] signedPolicyHash = rsaFormatter.CreateSignature(bufferPolicy);

        // Convert the signed policy to URL-safe base64 encoding and 
        // replace unsafe characters + = / with the safe characters - _ ~
        string strSignedPolicy = ToUrlSafeBase64String(signedPolicyHash);

        // Concatenate the URL, the timestamp, the signature, 
        // and the key pair ID to form the signed URL.
        return urlString + 
            "?Expires=" + 
            strExpiration + 
            "&Signature=" + 
            strSignedPolicy + 
            "&Key-Pair-Id=" + 
            keyId;
    }
}
```

## Método de firma de políticas personalizadas en C\$1
<a name="custom-policy-signed-url-net"></a>

El siguiente código C\$1 crea una URL firmada que utiliza una política personalizada siguiendo los pasos que se indican a continuación:

1. Crea una instrucción de política.

1. Codifica con base64 la instrucción de política y sustituye caracteres especiales para que la cadena se pueda usar tranquilamente como parámetro de solicitud de URL.

1. La instrucción de política aplica la función hash mediante SHA1 y cifra el resultado mediante RSA y la clave privada cuya clave pública correspondiente se encuentra en un grupo de claves de confianza.

1. Codifica con base64 la instrucción de política a la que se le ha aplicado una función hash y sustituye caracteres especiales para que la cadena se pueda usar tranquilamente como parámetro de solicitud de URL.

1. Encadena los valores.

Para ver la implementación completa, consulte el ejemplo disponible en [Código de firma en C\$1](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/samples/AWS_PrivateCF_Distributions.zip). 

**nota**  
Se devuelve `keyId` al cargar una clave pública a CloudFront. Para obtener más información, consulte ![\[6\]](http://docs.aws.amazon.com/es_es/AmazonCloudFront/latest/DeveloperGuide/images/callouts/6.png)[&Key-Pair-Id](private-content-creating-signed-url-canned-policy.md).

**Example : método de firma de políticas personalizadas en C\$1**  <a name="ExampleCustomPolicySigningMethod-CSharp"></a>

```
public static string ToUrlSafeBase64String(byte[] bytes)
{
    return System.Convert.ToBase64String(bytes)
        .Replace('+', '-')
        .Replace('=', '_')
        .Replace('/', '~');
}

public static string CreateCustomPrivateURL(string urlString, 
    string durationUnits, string durationNumber, string startIntervalFromNow, 
    string ipaddress, string pathToPolicyStmnt, string pathToPrivateKey, 
    string keyId)
{
    // args[] 0-thisMethod, 1-resourceUrl, 2-seconds-minutes-hours-days 
    // to expiration, 3-numberOfPreviousUnits, 4-starttimeFromNow, 
    // 5-ip_address, 6-pathToPolicyStmt, 7-pathToPrivateKey, 8-keyId

    TimeSpan timeSpanInterval = GetDuration(durationUnits, durationNumber);
    TimeSpan timeSpanToStart = GetDurationByUnits(durationUnits, 
        startIntervalFromNow);
    if (null == timeSpanToStart) 
        return "Invalid duration units." + 
            "Valid options: seconds, minutes, hours, or days";
            
    string strPolicy = CreatePolicyStatement(
        pathToPolicyStmnt, urlString, DateTime.Now.Add(timeSpanToStart), 
        DateTime.Now.Add(timeSpanInterval), ipaddress);

    // Read the policy into a byte buffer.
    byte[] bufferPolicy = Encoding.ASCII.GetBytes(strPolicy);

    // Convert the policy statement to URL-safe base64 encoding and 
    // replace unsafe characters + = / with the safe characters - _ ~

    string urlSafePolicy = ToUrlSafeBase64String(bufferPolicy);

    // Initialize the SHA1CryptoServiceProvider object and hash the policy data.
    byte[] bufferPolicyHash;
    using (SHA1CryptoServiceProvider cryptoSHA1 = 
        new SHA1CryptoServiceProvider())
    {
        bufferPolicyHash = cryptoSHA1.ComputeHash(bufferPolicy);

        // Initialize the RSACryptoServiceProvider object.
        RSACryptoServiceProvider providerRSA = new RSACryptoServiceProvider();
        XmlDocument xmlPrivateKey = new XmlDocument();

        // Load your private key, which you created by converting your 
        // .pem file to the XML format that the .NET framework uses.  
        // Several tools are available. 
        xmlPrivateKey.Load(pathToPrivateKey);

        // Format the RSACryptoServiceProvider providerRSA 
        // and create the signature.
        providerRSA.FromXmlString(xmlPrivateKey.InnerXml);
        RSAPKCS1SignatureFormatter RSAFormatter = 
            new RSAPKCS1SignatureFormatter(providerRSA);
        RSAFormatter.SetHashAlgorithm("SHA1");
        byte[] signedHash = RSAFormatter.CreateSignature(bufferPolicyHash);

        // Convert the signed policy to URL-safe base64 encoding and 
        // replace unsafe characters + = / with the safe characters - _ ~
        string strSignedPolicy = ToUrlSafeBase64String(signedHash);

        return urlString + 
            "?Policy=" + 
            urlSafePolicy + 
            "&Signature=" + 
            strSignedPolicy + 
            "&Key-Pair-Id=" + 
            keyId;
    }
}
```

## Métodos de utilidades para generar firmas
<a name="utility-methods-signed-url"></a>

Los siguientes métodos obtienen la instrucción de política de un archivo y analizan intervalos de tiempo para generar firmas.

**Example : métodos de utilidades para generar firmas**  <a name="UtilityMethodsForSignatureGeneration"></a>

```
public static string CreatePolicyStatement(string policyStmnt, 
   string resourceUrl, 
   DateTime startTime, 
   DateTime endTime, 
   string ipAddress)
   
{
   // Create the policy statement.
   FileStream streamPolicy = new FileStream(policyStmnt, FileMode.Open, FileAccess.Read);
   using (StreamReader reader = new StreamReader(streamPolicy))
   {
      string strPolicy = reader.ReadToEnd();

      TimeSpan startTimeSpanFromNow = (startTime - DateTime.Now);
      TimeSpan endTimeSpanFromNow = (endTime - DateTime.Now);
      TimeSpan intervalStart = 
         (DateTime.UtcNow.Add(startTimeSpanFromNow)) - 
         new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);
      TimeSpan intervalEnd = 
         (DateTime.UtcNow.Add(endTimeSpanFromNow)) - 
         new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);

      int startTimestamp = (int)intervalStart.TotalSeconds; // START_TIME
      int endTimestamp = (int)intervalEnd.TotalSeconds;  // END_TIME

      if (startTimestamp > endTimestamp)
         return "Error!";

      // Replace variables in the policy statement.
      strPolicy = strPolicy.Replace("RESOURCE", resourceUrl);
      strPolicy = strPolicy.Replace("START_TIME", startTimestamp.ToString());
      strPolicy = strPolicy.Replace("END_TIME", endTimestamp.ToString());
      strPolicy = strPolicy.Replace("IP_ADDRESS", ipAddress);
      strPolicy = strPolicy.Replace("EXPIRES", endTimestamp.ToString());
      return strPolicy;
   }   
}

public static TimeSpan GetDuration(string units, string numUnits)
{
   TimeSpan timeSpanInterval = new TimeSpan();
   switch (units)
   {
      case "seconds":
         timeSpanInterval = new TimeSpan(0, 0, 0, int.Parse(numUnits));
         break;
      case "minutes":
         timeSpanInterval = new TimeSpan(0, 0, int.Parse(numUnits), 0);
         break;
      case "hours":
         timeSpanInterval = new TimeSpan(0, int.Parse(numUnits), 0 ,0);
         break;
      case "days":
         timeSpanInterval = new TimeSpan(int.Parse(numUnits),0 ,0 ,0);
         break;
      default:
         Console.WriteLine("Invalid time units;" + 
            "use seconds, minutes, hours, or days");
         break;
   }
   return timeSpanInterval;
}

private static TimeSpan GetDurationByUnits(string durationUnits, 
   string startIntervalFromNow)
{
   switch (durationUnits)
   {
      case "seconds":
         return new TimeSpan(0, 0, int.Parse(startIntervalFromNow));
      case "minutes":
         return new TimeSpan(0, int.Parse(startIntervalFromNow), 0);
      case "hours":
         return new TimeSpan(int.Parse(startIntervalFromNow), 0, 0);
      case "days":
         return new TimeSpan(int.Parse(startIntervalFromNow), 0, 0, 0);
      default:
         return new TimeSpan(0, 0, 0, 0);
   }
}

public static string CopyExpirationTimeFromPolicy(string policyStatement)
{
   int startExpiration = policyStatement.IndexOf("EpochTime");
   string strExpirationRough = policyStatement.Substring(startExpiration + 
      "EpochTime".Length);
   char[] digits = { '0', '1', '2', '3', '4', '5', '6', '7', '8', '9' };
         
   List<char> listDigits = new List<char>(digits);
   StringBuilder buildExpiration = new StringBuilder(20);
         
   foreach (char c in strExpirationRough)
   {
      if (listDigits.Contains(c))
         buildExpiration.Append(c);
   }
   return buildExpiration.ToString();   
}
```

Véase también
+ [Crear una firma de URL con Perl](CreateURLPerl.md)
+ [Crear una firma de URL con PHP](CreateURL_PHP.md)
+ [Crear una firma de URL con Java](CFPrivateDistJavaDevelopment.md)

# Crear una firma de URL con Java
<a name="CFPrivateDistJavaDevelopment"></a>

Además del siguiente ejemplo de código, puede utilizar [la clase de utilidad `CloudFrontUrlSigner` de AWS SDK para Java (versión 1)](https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/cloudfront/CloudFrontUrlSigner.html) para crear [URL firmadas de CloudFront](private-content-signed-urls.md).

Para ver más ejemplos, consulte [Create signed URLs and cookies using an AWS SDK](https://docs.aws.amazon.com/code-library/latest/ug/cloudfront_example_cloudfront_CloudFrontUtilities_section.html) en la *biblioteca de códigos de ejemplos de códigos de AWS SDK*. 

**nota**  
La creación de una URL firmada es solo una parte del proceso de [entrega de contenido privado con CloudFront](PrivateContent.md). Para obtener más información acerca de todo el proceso, consulte [Uso de URL firmadas](private-content-signed-urls.md).

En el ejemplo siguiente se muestra cómo crear una URL firmada de CloudFront.

**Example Política de Java y métodos de cifrado de firma**  <a name="ExampleJavaPolicyAndSignatureEncryptionMethods"></a>

```
package org.example;

import java.time.Instant;
import java.time.temporal.ChronoUnit;
import software.amazon.awssdk.services.cloudfront.CloudFrontUtilities;
import software.amazon.awssdk.services.cloudfront.model.CannedSignerRequest;
import software.amazon.awssdk.services.cloudfront.url.SignedUrl;

public class Main {

    public static void main(String[] args) throws Exception {
        CloudFrontUtilities cloudFrontUtilities = CloudFrontUtilities.create();
        Instant expirationDate = Instant.now().plus(7, ChronoUnit.DAYS);
        String resourceUrl = "https://a1b2c3d4e5f6g7.cloudfront.net";
        String keyPairId = "K1UA3WV15I7JSD";
        CannedSignerRequest cannedRequest = CannedSignerRequest.builder()
                .resourceUrl(resourceUrl)
                .privateKey(new java.io.File("/path/to/private_key.pem").toPath())
                .keyPairId(keyPairId)
                .expirationDate(expirationDate)
                .build();
        SignedUrl signedUrl = cloudFrontUtilities.getSignedUrlWithCannedPolicy(cannedRequest);
        String url = signedUrl.url();
        System.out.println(url);

    }
}
```

Véase también:
+ [Crear una firma de URL con Perl](CreateURLPerl.md)
+ [Crear una firma de URL con PHP](CreateURL_PHP.md)
+ [Crear una firma de URL mediante C\$1 y .NET Framework](CreateSignatureInCSharp.md)

# Restricción del acceso a un origen de AWS
<a name="private-content-restricting-access-to-origin"></a>

Puede configurar CloudFront y algunos orígenes de AWS de forma que se obtengan los siguientes beneficios:
+ Restringe el acceso al origen de AWS para que no sea accesible al público.
+ Se asegura de que los espectadores (usuarios) puedan acceder al contenido en el origen de AWS solo a través de la distribución de CloudFront especificada. Esto impide que los espectadores accedan al contenido directamente desde el origen o a través de una distribución no deseada de CloudFront.

Para ello, configure CloudFront para que envíe solicitudes autenticadas al origen de AWS y configure el origen de AWS para que solo permita el acceso a las solicitudes autenticadas de CloudFront. Para obtener más información, consulte los siguientes temas para ver los tipos de orígenes de AWS compatibles.

**Topics**
+ [Restricción del acceso a un origen de AWS Elemental MediaPackage v2](private-content-restricting-access-to-mediapackage.md)
+ [Restricción del acceso a un origen de AWS Elemental MediaStore](private-content-restricting-access-to-mediastore.md)
+ [Restricción del acceso a un origen de URL de función de AWS Lambda](private-content-restricting-access-to-lambda.md)
+ [Restricción del acceso a un origen de Amazon S3](private-content-restricting-access-to-s3.md)
+ [Restricción del acceso con orígenes de la VPC](private-content-vpc-origins.md)

# Restricción del acceso a un origen de AWS Elemental MediaPackage v2
<a name="private-content-restricting-access-to-mediapackage"></a>

CloudFront proporciona *control de acceso de origen* (OAC) para restringir el acceso a un origen de MediaPackage v2.

**nota**  
CloudFront OAC solo admite MediaPackage v2. MediaPackage v1 no se admite.

**Topics**
+ [Creación de un nuevo OAC](#create-oac-overview-mediapackage)
+ [Configuración avanzada para el control de acceso de origen](#oac-advanced-settings-mediapackage)

## Creación de un nuevo OAC
<a name="create-oac-overview-mediapackage"></a>

Complete los pasos que se describen en los siguientes temas para configurar un nuevo OAC en CloudFront.

**Topics**
+ [Requisitos previos](#oac-prerequisites-mediapackage)
+ [Concesión del permiso de CloudFront para acceder al origen de MediaPackage v2](#oac-permission-to-access-mediapackage)
+ [Creación del OAC](#create-oac-mediapackage)

### Requisitos previos
<a name="oac-prerequisites-mediapackage"></a>

Antes de crear y configurar el OAC, debe tener una distribución de CloudFront con un origen de MediaPackage v2. Para obtener más información, consulte [Uso de un contenedor de MediaStore o un canal de MediaPackage](DownloadDistS3AndCustomOrigins.md#concept_AWS_Media).

### Concesión del permiso de CloudFront para acceder al origen de MediaPackage v2
<a name="oac-permission-to-access-mediapackage"></a>

Antes de crear un OAC o configurarlo en una distribución de CloudFront, asegúrese de que CloudFront tiene permiso para acceder al origen de MediaPackage v2. Realice esta acción después de crear una distribución de CloudFront, pero antes de agregar el OAC al origen de MediaPackage v2 en la configuración de distribución.

Utilice una política de IAM para permitir que la entidad principal del servicio de CloudFront (`cloudfront.amazonaws.com`) acceda al origen. Utilice un elemento `Condition` en la política para permitir que CloudFront acceda al origen de MediaPackage v2 *solo* cuando la solicitud sea en nombre de la distribución de CloudFront que contiene el origen de MediaPackage v2. Esta es la distribución con el origen de MediaPackage v2 a la que desea agregar OAC.

**Example : política de IAM que permite el acceso de solo lectura a una distribución de CloudFront con OAC habilitado**  
La siguiente política permite que la distribución de CloudFront (`E1PDK09ESKHJWT`) acceda al origen de MediaPackage v2. El origen es el ARN especificado para el elemento `Resource`.    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowCloudFrontServicePrincipal",
            "Effect": "Allow",
            "Principal": {"Service": "cloudfront.amazonaws.com"},
            "Action": "mediapackagev2:GetObject",
            "Resource": "arn:aws:mediapackagev2:us-east-1:123456789012:channelGroup/channel-group-name/channel/channel-name/originEndpoint/origin_endpoint_name",
            "Condition": {
                "StringEquals": {"AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/E1PDK09ESKHJWT"}
            }
        }
    ]
}
```

**Notas**  
Si ha activado la característica MQAR y el control de acceso de origen (OAC), agregue la acción `mediapackagev2:GetHeadObject` a la política de IAM. MQAR requiere este permiso para enviar solicitudes `HEAD` al origen de MediaPackage v2. Para obtener más información acerca de MQAR, consulte [Resiliencia basada en la calidad multimedia](media-quality-score.md).
Si crea una distribución que no tiene permiso para el origen de MediaPackage v2, puede elegir **Copiar política** en la consola de CloudFront y, a continuación, elegir **Actualizar permisos de punto de conexión**. Después, puede adjuntar el permiso copiado al dispositivo de punto de conexión. Para obtener más información, consulte [Endpoint policy fields](https://docs.aws.amazon.com/mediapackage/latest/userguide/endpoints-policy.html) en la *Guía del usuario de AWS Elemental MediaPackage*. 

### Creación del OAC
<a name="create-oac-mediapackage"></a>

Para crear un OAC, puede utilizar la Consola de administración de AWS, CloudFormation, la AWS CLI o la API de CloudFront.

------
#### [ Console ]

**Creación de un OAC**

1. Inicie sesión en la Consola de administración de AWS y abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. En el panel de navegación, elija **Origin access** (Acceso de origen).

1. Elija **Crear configuración de control**.

1. En el formulario **Crear nuevo OAC**, haga lo siguiente:

   1. Indique un **Nombre** y, opcionalmente, una **Descripción** para el OAC.

   1. En el panel **Configuración**, le recomendamos que deje la predeterminada, **Firmar solicitudes (recomendado)**. Para obtener más información, consulte [Configuración avanzada para el control de acceso de origen](#oac-advanced-settings-mediapackage).

1. Para **Tipo de origen**, elija **MediaPackage V2**. 

1. Seleccione **Crear**.
**sugerencia**  
Después de crear el OAC, anote el **Nombre**. Lo necesita en el siguiente procedimiento.

**Cómo agregar un OAC a un origen de MediaPackage v2 en una distribución**

1. Abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Elija una distribución con un origen de MediaPackage V2 a la que desee agregar el OAC y, a continuación, elija la pestaña **Orígenes**.

1. Seleccione el origen de MediaPackage v2 al que desea agregar el OAC y, a continuación, elija **Editar**.

1. Seleccione **Solo HTTP** para el **Protocolo** de origen.

1. En el menú desplegable **Control de acceso de origen**, elija el nombre de OAC que desee utilizar.

1. Seleccione **Save changes (Guardar cambios)**.

La distribución comienza a implementarse en todas las ubicaciones periféricas de CloudFront. Cuando una ubicación periférica recibe la nueva configuración, firma todas las solicitudes que envía al origen de MediaPackage v2.

------
#### [ CloudFormation ]

Para crear un OAC con CloudFormation, utilice el tipo de recurso `AWS::CloudFront::OriginAccessControl`. En el siguiente ejemplo se muestra la sintaxis de plantilla de CloudFormation, en formato YAML, para crear un OAC.

```
Type: AWS::CloudFront::OriginAccessControl
Properties: 
  OriginAccessControlConfig: 
      Description: An optional description for the origin access control
      Name: ExampleOAC
      OriginAccessControlOriginType: mediapackagev2
      SigningBehavior: always
      SigningProtocol: sigv4
```

Para obtener más información, consulte [AWS::CloudFront::OriginAccessControl](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-originaccesscontrol.html) en la *Guía del usuario de AWS CloudFormation*.

------
#### [ CLI ]

Para crear un control de acceso de origen con la AWS Command Line Interface (AWS CLI), utilice el comando **aws cloudfront create-origin-access-control**. Puede utilizar un archivo de entrada para proporcionar los parámetros de entrada del comando, en lugar de especificar cada parámetro individual como entrada de la línea de comandos.

**Para crear un control de acceso de origen (CLI con archivo de entrada)**

1. Utilice el siguiente comando para crear un archivo llamado `origin-access-control.yaml`. Este archivo contiene todos los parámetros de entrada para el comando **create-origin-access-control**.

   ```
   aws cloudfront create-origin-access-control --generate-cli-skeleton yaml-input > origin-access-control.yaml
   ```

1. Abra el archivo `origin-access-control.yaml` que acaba de crear. Edite el archivo para agregar un nombre para el OAC, una descripción (opcional) y cambie `SigningBehavior` por `always`. A continuación, guarde el archivo.

   Para obtener información sobre otras configuraciones de OAC, consulte [Configuración avanzada para el control de acceso de origen](#oac-advanced-settings-mediapackage).

1. Utilice el siguiente comando para crear el control de acceso de origen mediante los parámetros de entrada del archivo `origin-access-control.yaml`.

   ```
   aws cloudfront create-origin-access-control --cli-input-yaml file://origin-access-control.yaml
   ```

   Anote el valor de `Id` en la salida del comando. Lo necesita para agregar el OAC a un origen de MediaPackage v2 en una distribución de CloudFront.

**Cómo adjuntar un OAC a un origen de MediaPackage v2 en una distribución existente (CLI con archivo de entrada)**

1. Utilice el comando siguiente para guardar la configuración de distribución de la distribución de CloudFront a la que desea agregar el OAC. La distribución debe tener un origen de MediaPackage v2.

   ```
   aws cloudfront get-distribution-config --id <CloudFront distribution ID> --output yaml > dist-config.yaml
   ```

1. Abra el archivo llamado `dist-config.yaml` que acaba de crear. Edite el archivo y realice los siguientes cambios:
   + En el objeto `Origins`, agregue el ID de OAC al campo que se llama `OriginAccessControlId`.
   + Elimine el valor del campo que se llama `OriginAccessIdentity`, si existe.
   + Cambie el nombre del campo `ETag` a `IfMatch`, pero no cambie el valor del campo.

   Guarde el archivo cuando haya terminado.

1. Utilice el siguiente comando para actualizar la distribución y utilizar el control de acceso de origen.

   ```
   aws cloudfront update-distribution --id <CloudFront distribution ID> --cli-input-yaml file://dist-config.yaml
   ```

La distribución comienza a implementarse en todas las ubicaciones periféricas de CloudFront. Cuando una ubicación periférica recibe la nueva configuración, firma todas las solicitudes que envía al origen de MediaPackage v2.

------
#### [ API ]

Para crear un OAC con la API de CloudFront, utilice [CreateOriginAccessControl](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateOriginAccessControl.html). Para obtener más información sobre los campos que especifique en esta llamada a la API, consulte la documentación de referencia de la API para el SDK de AWS u otro cliente de la API.

Después de crear un OAC, puede adjuntarlo a un origen de MediaPackage v2 en una distribución, mediante una de las siguientes llamadas a la API:
+ Para asociarlo a una distribución existente, utilice [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html).
+ Para asociarlo a una nueva distribución, utilice [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html).

Para estas dos llamadas a la API, proporcione el ID de OAC en el campo `OriginAccessControlId`, dentro de un origen. Para obtener más información sobre los otros campos que especifique en estas llamadas a la API, consulte [Referencia de toda la configuración de distribución](distribution-web-values-specify.md) y la documentación de referencia de la API para el SDK de AWS u otro cliente de la API.

------

## Configuración avanzada para el control de acceso de origen
<a name="oac-advanced-settings-mediapackage"></a>

La característica de OAC de CloudFront incluye configuraciones avanzadas que están pensadas solo para casos de uso específicos. Utilice la configuración recomendada a menos que tenga una necesidad específica de la configuración avanzada.

El OAC contiene una configuración denominada **Comportamiento de firma** (en la consola) o `SigningBehavior` (en la API, CLI y CloudFormation). Esta configuración proporciona las siguientes opciones:

**Firmar siempre las solicitudes de origen (configuración recomendada)**  
Recomendamos utilizar esta configuración, denominada **Firmar solicitudes (recomendado)** en la consola o `always` en la API, la CLI y CloudFormation. Con esta configuración, CloudFront siempre firma todas las solicitudes que envía al origen de MediaPackage v2.

**Nunca firmar solicitudes de origen**  
Esta configuración se denomina **No firmar solicitudes** en la consola o `never` en la API, la CLI y CloudFormation. Utilice esta configuración con el fin de desactivar el OAC para todos los orígenes en todas las distribuciones que utilizan este OAC. Esto puede ahorrar tiempo y esfuerzo en comparación con la eliminación de un OAC de todos los orígenes y distribuciones que lo utilizan, uno por uno. Con esta configuración, CloudFront no firma las solicitudes que envía al origen de MediaPackage v2.  
Para utilizar esta configuración, el origen de MediaPackage v2 debe ser de acceso público. Si utiliza esta configuración con un origen de MediaPackage v2 que no es de acceso público, CloudFront no podrá acceder al origen. El origen de MediaPackage v2 devuelve errores a CloudFront y CloudFront pasa esos errores a los lectores. Para obtener más información, consulte el ejemplo de política de MediaPackage v2 para [Policies and Permissions in MediaPackage](https://docs.aws.amazon.com/mediapackage/latest/userguide/policies-permissions.html) en la *Guía del usuario de AWS Elemental MediaPackage*.

**No anular el encabezado `Authorization` del lector (cliente)**  
Esta configuración se denomina **Do not override authorization header** (No anular el encabezado authorization en la consola o `no-override` en la API, la CLI y CloudFormation. Utilice esta configuración cuando desee que CloudFront firme las solicitudes de origen solo cuando la solicitud del lector correspondiente no incluya un encabezado `Authorization`. Con esta configuración, CloudFront pasa el encabezado `Authorization` de la solicitud del lector cuando hay uno, pero firma la solicitud de origen (agrega su propio encabezado `Authorization`) cuando la solicitud del lector no incluye un encabezado `Authorization`.  
Para pasar el encabezado `Authorization` de la solicitud del lector, *debe* agregar el encabezado `Authorization` a una [política de caché](controlling-the-cache-key.md) para todos los comportamientos de caché que utilizan los orígenes de MediaPackage v2 asociados con este control de acceso de origen.

# Restricción del acceso a un origen de AWS Elemental MediaStore
<a name="private-content-restricting-access-to-mediastore"></a>

CloudFront proporciona un *control de acceso de origen* (OAC) para restringir el acceso a un origen de AWS Elemental MediaStore.

**Topics**
+ [Creación de un nuevo control de acceso de origen](#create-oac-overview-mediastore)
+ [Configuración avanzada para el control de acceso de origen](#oac-advanced-settings-mediastore)

## Creación de un nuevo control de acceso de origen
<a name="create-oac-overview-mediastore"></a>

Complete los pasos que se describen en los siguientes temas para configurar un nuevo control de acceso de origen en CloudFront.

**Topics**
+ [Requisitos previos](#oac-prerequisites-mediastore)
+ [Concesión del permiso de CloudFront para acceder al origen de MediaStore](#oac-permission-to-access-mediastore)
+ [Creación del control de acceso de origen](#create-oac-mediastore)

### Requisitos previos
<a name="oac-prerequisites-mediastore"></a>

Antes de crear y configurar el control de acceso de origen (OAC), debe tener una distribución de CloudFront con un origen de MediaStore. 

### Concesión del permiso de CloudFront para acceder al origen de MediaStore
<a name="oac-permission-to-access-mediastore"></a>

Antes de crear un control de acceso de origen o configurarlo en una distribución de CloudFront, asegúrese de que CloudFront tiene permiso para acceder al origen de MediaStore. Realice esta acción después de crear una distribución de CloudFront, pero antes de agregar el OAC al origen de MediaStore en la configuración de distribución. 

Utilice una política de contenedor de MediaStore para permitir que la entidad principal del servicio de CloudFront (`cloudfront.amazonaws.com`) acceda al origen. Utilice un elemento `Condition` en la política para permitir que CloudFront acceda al contenedor de MediaStore solo cuando la solicitud sea en nombre de la distribución de CloudFront que contiene el origen de MediaStore. Esta es la distribución con el origen de MediaStore al que desea agregar OAC.

A continuación, se muestran ejemplos de políticas de contenedor de MediaStore que permiten a una distribución de CloudFront acceder a un origen de MediaStore.

**Example Política de contenedor de MediaStore que permite el acceso de solo lectura a una distribución de CloudFront con OAC habilitado**    
****  

```
{
        "Version":"2012-10-17",		 	 	 
        "Statement": [
            {
                "Sid": "AllowCloudFrontServicePrincipalReadOnly",
                "Effect": "Allow",
                "Principal": {
                  "Service": "cloudfront.amazonaws.com"
                },
                "Action": [ 
                  "mediastore:GetObject"
                ],
                "Resource": "arn:aws:mediastore:us-east-1:111122223333:container/<container name>/*",
                "Condition": {
                    "StringEquals": {
                      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/CloudFront-distribution-ID"
                    },
                    "Bool": {
                      "aws:SecureTransport": "true"
                    }
                }
            }
        ]
}
```

**Example Política de contenedor de MediaStore que permite el acceso de lectura y escritura a una distribución de CloudFront con OAC habilitado**    
****  

```
{
        "Version":"2012-10-17",		 	 	 
        "Statement": [
            {
                "Sid": "AllowCloudFrontServicePrincipalReadWrite",
                "Effect": "Allow",
                "Principal": {
                  "Service": "cloudfront.amazonaws.com"
                },
                "Action": [ 
                  "mediastore:GetObject",
                  "mediastore:PutObject"
                ],
                "Resource": "arn:aws:mediastore:us-east-1:111122223333:container/container-name/*",
                "Condition": {
                    "StringEquals": {
                      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/CloudFront-distribution-ID"
                    },
                    "Bool": {
                      "aws:SecureTransport": "true"
                    }
                }
            }
        ]
}
```

**nota**  
Para permitir el acceso de escritura, debe configurar los **Allowed HTTP methods** (Métodos HTTP permitidos) para incluir `PUT` en la configuración de comportamiento de la distribución de CloudFront.

### Creación del control de acceso de origen
<a name="create-oac-mediastore"></a>

Para crear un OAC, puede utilizar Consola de administración de AWS, CloudFormation, AWS CLI o la API de CloudFront.

------
#### [ Console ]

**Para crear un control de acceso de origen**

1. Inicie sesión en la Consola de administración de AWS y abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. En el panel de navegación, elija **Origin access** (Acceso de origen).

1. Elija **Create control setting** (Crear configuración de control).

1. En el formulario **Create control setting** (Crear configuración de control), haga lo siguiente:

   1. En el panel **Details** (Detalles), ingrese un valor para **Name** (Nombre) y (opcionalmente) para **Description** (Descripción) para el control de acceso de origen.

   1. En el panel **Settings** (Configuración), le recomendamos que deje la configuración predeterminada **Sign requests (recommended)** (Firmar solicitudes [recomendado]). Para obtener más información, consulte [Configuración avanzada para el control de acceso de origen](#oac-advanced-settings-mediastore).

1. Elija MediaStore en el menú desplegable de **Origin type** (Tipo de origen).

1. Seleccione **Crear**.

   Una vez creado el OAC, anote el valor de **Name** (Nombre). Lo necesita en el siguiente procedimiento.

**Para agregar un control de acceso de origen a un origen de MediaStore en una distribución**

1. Abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Elija una distribución con un origen de MediaStore a la que desee agregar el OAC y, a continuación, elija la pestaña **Origins** (Orígenes).

1. Seleccione el origen de MediaStore al que desea agregar el OAC y, a continuación, elija **Edit** (Editar).

1. Seleccione **HTTPS only** (Solo HTTP) para el **Protocol** (Protocolo) de origen.

1. En el menú desplegable **Origin access control** (Control de acceso de origen), elija el OAC que desee utilizar.

1. Seleccione **Save changes (Guardar cambios)**.

La distribución comienza a implementarse en todas las ubicaciones periféricas de CloudFront. Cuando una ubicación periférica recibe la nueva configuración, firma todas las solicitudes que envía al origen de bucket de MediaStore.

------
#### [ CloudFormation ]

Para crear un control de acceso de origen (OAC) con CloudFormation, utilice el tipo de recurso `AWS::CloudFront::OriginAccessControl`. El siguiente ejemplo se muestra la sintaxis de plantilla de CloudFormation, en formato YAML, para crear un control de acceso de origen.

```
Type: AWS::CloudFront::OriginAccessControl
Properties: 
  OriginAccessControlConfig: 
      Description: An optional description for the origin access control
      Name: ExampleOAC
      OriginAccessControlOriginType: mediastore
      SigningBehavior: always
      SigningProtocol: sigv4
```

Para obtener más información, consulte [AWS::CloudFront::OriginAccessControl](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-originaccesscontrol.html) en la *Guía del usuario de AWS CloudFormation*.

------
#### [ CLI ]

Para crear un control de acceso de origen con la AWS Command Line Interface (AWS CLI), utilice el comando **aws cloudfront create-origin-access-control**. Puede utilizar un archivo de entrada para proporcionar los parámetros de entrada del comando, en lugar de especificar cada parámetro individual como entrada de la línea de comandos.

**Para crear un control de acceso de origen (CLI con archivo de entrada)**

1. Utilice el siguiente comando para crear un archivo llamado `origin-access-control.yaml`. Este archivo contiene todos los parámetros de entrada para el comando **create-origin-access-control**.

   ```
   aws cloudfront create-origin-access-control --generate-cli-skeleton yaml-input > origin-access-control.yaml
   ```

1. Abra el archivo `origin-access-control.yaml` que acaba de crear. Edite el archivo para agregar un nombre para el OAC, una descripción (opcional) y cambie `SigningBehavior` por `always`. A continuación, guarde el archivo.

   Para obtener información sobre otras configuraciones de OAC, consulte [Configuración avanzada para el control de acceso de origen](#oac-advanced-settings-mediastore).

1. Utilice el siguiente comando para crear el control de acceso de origen mediante los parámetros de entrada del archivo `origin-access-control.yaml`.

   ```
   aws cloudfront create-origin-access-control --cli-input-yaml file://origin-access-control.yaml
   ```

   Anote el valor de `Id` en la salida del comando. Lo necesita para agregar el OAC a un origen de MediaStore en una distribución de CloudFront.

**Para adjuntar un OAC a un origen de MediaStore en una distribución existente (CLI con archivo de entrada)**

1. Utilice el comando siguiente para guardar la configuración de distribución de la distribución de CloudFront a la que desea agregar el OAC. La distribución debe tener un origen de MediaStore.

   ```
   aws cloudfront get-distribution-config --id <CloudFront distribution ID> --output yaml > dist-config.yaml
   ```

1. Abra el archivo llamado `dist-config.yaml` que acaba de crear. Edite el archivo y realice los siguientes cambios:
   + En el objeto `Origins`, agregue el ID de OAC al campo que se llama `OriginAccessControlId`.
   + Elimine el valor del campo que se llama `OriginAccessIdentity`, si existe.
   + Cambie el nombre del campo `ETag` a `IfMatch`, pero no cambie el valor del campo.

   Guarde el archivo cuando haya terminado.

1. Utilice el siguiente comando para actualizar la distribución y utilizar el control de acceso de origen.

   ```
   aws cloudfront update-distribution --id <CloudFront distribution ID> --cli-input-yaml file://dist-config.yaml
   ```

La distribución comienza a implementarse en todas las ubicaciones periféricas de CloudFront. Cuando una ubicación periférica recibe la nueva configuración, firma todas las solicitudes que envía al origen de MediaStore.

------
#### [ API ]

Para crear un control de acceso de origen con la API de CloudFront, utilice [CreateOriginAccessControl](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateOriginAccessControl.html). Para obtener más información sobre los campos que especifique en esta llamada a la API, consulte la documentación de referencia de la API para el SDK de AWS u otro cliente de la API.

Después de crear un control de acceso de origen, puede adjuntarlo a un origen de MediaStore en una distribución, mediante una de las siguientes llamadas a la API:
+ Para asociarlo a una distribución existente, utilice [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html).
+ Para asociarlo a una nueva distribución, utilice [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html).

Para estas dos llamadas a la API, proporcione el ID de control de acceso de origen en el campo `OriginAccessControlId`, dentro de un origen. Para obtener más información sobre los otros campos que especifique en estas llamadas a la API, consulte [Referencia de toda la configuración de distribución](distribution-web-values-specify.md) y la documentación de referencia de la API para el SDK de AWS u otro cliente de la API.

------

## Configuración avanzada para el control de acceso de origen
<a name="oac-advanced-settings-mediastore"></a>

La característica de control de acceso de origen de CloudFront incluye configuraciones avanzadas que están pensadas solo para casos de uso específicos. Utilice la configuración recomendada a menos que tenga una necesidad específica de la configuración avanzada.

El control de acceso de origen contiene una configuración denominada **Signing behavior** (Comportamiento de firma) (en la consola) o `SigningBehavior` (en la API, CLI y CloudFormation). Esta configuración proporciona las siguientes opciones:

**Firmar siempre las solicitudes de origen (configuración recomendada)**  
Recomendamos utilizar esta configuración, denominada **Firmar solicitudes (recomendado)** en la consola o `always` en la API, la CLI y CloudFormation. Con esta configuración, CloudFront siempre firma todas las solicitudes que envía al origen de MediaStore.

**Nunca firmar solicitudes de origen**  
Esta configuración se denomina **Do not sign requests** (No firmar solicitudes) en la consola o `never` en la API, la CLI y CloudFormation. Utilice esta configuración para desactivar el control de acceso de origen para todos los orígenes en todas las distribuciones que utilizan este control de acceso de origen. Esto puede ahorrar tiempo y esfuerzo en comparación con la eliminación de un control de acceso de origen de todos los orígenes y distribuciones que lo utilizan, uno por uno. Con esta configuración, CloudFront no firma las solicitudes que envía al origen de MediaStore.  
Para utilizar esta configuración, el origen de MediaStore debe ser de acceso público. Si utiliza esta configuración con un origen de MediaStore que no es de acceso público, CloudFront no podrá acceder al origen. El origen de MediaStore devuelve errores a CloudFront y CloudFront pasa esos errores a los lectores. Para obtener más información, consulte el ejemplo de política de contenedores de MediaStore para el [acceso público de lectura a través de HTTPS](https://docs.aws.amazon.com/mediastore/latest/ug/policies-examples-public-https.html).

**No anular el encabezado `Authorization` del lector (cliente)**  
Esta configuración se denomina **Do not override authorization header** (No anular el encabezado authorization en la consola o `no-override` en la API, la CLI y CloudFormation. Utilice esta configuración cuando desee que CloudFront firme las solicitudes de origen solo cuando la solicitud del lector correspondiente no incluya un encabezado `Authorization`. Con esta configuración, CloudFront pasa el encabezado `Authorization` de la solicitud del lector cuando hay uno, pero firma la solicitud de origen (agrega su propio encabezado `Authorization`) cuando la solicitud del lector no incluye un encabezado `Authorization`.  
Para pasar el encabezado `Authorization` de la solicitud del lector, *debe* agregar el encabezado `Authorization` a una [política de caché](controlling-the-cache-key.md) para todos los comportamientos de caché que utilizan los orígenes de MediaStore asociados con este control de acceso de origen.

# Restricción del acceso a un origen de URL de función de AWS Lambda
<a name="private-content-restricting-access-to-lambda"></a>

CloudFront proporciona un *control de acceso de origen* (OAC) para restringir el acceso a un origen de URL de función de Lambda.

**Topics**
+ [Creación de un nuevo OAC](#create-oac-overview-lambda)
+ [Configuración avanzada para el control de acceso de origen](#oac-advanced-settings-lambda)
+ [Código de plantilla de ejemplo](#example-template-code-lambda-oac)

## Creación de un nuevo OAC
<a name="create-oac-overview-lambda"></a>

Complete los pasos que se describen en los siguientes temas para configurar un nuevo OAC en CloudFront.

**importante**  
Si utiliza los métodos `PUT` o `POST` con la URL de función de Lambda, los usuarios deben calcular el SHA256 del cuerpo e incluir el valor del hash de carga útil del cuerpo de la solicitud en el encabezado `x-amz-content-sha256` al enviar la solicitud a CloudFront. Lambda no admite las cargas sin firmar.

**Topics**
+ [Requisitos previos](#oac-prerequisites-lambda)
+ [Concesión de permiso de CloudFront para acceder a la URL de función de Lambda](#oac-permission-to-access-lambda)
+ [Creación del OAC](#create-oac-lambda)

### Requisitos previos
<a name="oac-prerequisites-lambda"></a>

Antes de crear y configurar OAC, debe tener una distribución de CloudFront con una URL de función de Lambda como el origen. Para usar OAC, debe especificar `AWS_IAM` como valor para el parámetro `AuthType`. Para obtener más información, consulte [Uso de una URL de función de Lambda](DownloadDistS3AndCustomOrigins.md#concept_lambda_function_url).

### Concesión de permiso de CloudFront para acceder a la URL de función de Lambda
<a name="oac-permission-to-access-lambda"></a>

Antes de crear un OAC o configurarlo en una distribución de CloudFront, asegúrese de que CloudFront tiene permiso para acceder a la URL de función de Lambda. Realice esta acción después de crear una distribución de CloudFront, pero antes de agregar el OAC a la URL de función de Lambda en la configuración de distribución.

**nota**  
Para actualizar la política de IAM para la URL de función de Lambda, debe usar la AWS Command Line Interface (AWS CLI). En este momento, no se admite la edición de la política de IAM en la consola de Lambda.

El siguiente comando de la AWS CLI concede a la entidad principal de servicio de CloudFront (`cloudfront.amazonaws.com`) acceso a la URL de función de Lambda. El elemento `Condition` en la política permite que CloudFront acceda a Lambda *solo* cuando la solicitud sea en nombre de la distribución de CloudFront que contiene la URL de función de Lambda. Esta es la distribución con el origen de URL de función de Lambda a la que desea agregar OAC.

**Example : comando de la AWS CLI para actualizar una política con el fin de permitir el acceso de solo lectura a una distribución de CloudFront con OAC habilitado**  
Los siguientes comandos de la AWS CLI permiten que la distribución de CloudFront (`E1PDK09ESKHJWT`) acceda a su *`FUNCTION_URL_NAME`* de Lambda.

```
aws lambda add-permission \
--statement-id "AllowCloudFrontServicePrincipal" \
--action "lambda:InvokeFunctionUrl" \
--principal "cloudfront.amazonaws.com" \
--source-arn "arn:aws:cloudfront::123456789012:distribution/E1PDK09ESKHJWT" \
--function-name FUNCTION_URL_NAME
```

```
aws lambda add-permission \
--statement-id "AllowCloudFrontServicePrincipalInvokeFunction" \
--action "lambda:InvokeFunction" \
--principal "cloudfront.amazonaws.com" \
--source-arn "arn:aws:cloudfront::123456789012:distribution/E1PDK09ESKHJWT" \
--function-name FUNCTION_URL_NAME
```

**nota**  
Si crea una distribución y no tiene permiso para la URL de función de Lambda, puede elegir el **comando de copia de la CLI** en la consola de CloudFront y, a continuación, introducir este comando desde el terminal de la línea de comandos. Para obtener más información, consulte [Concesión de acceso a las funciones a los Servicios de AWS](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html#permissions-resource-serviceinvoke) en la *Guía para desarrolladores de AWS Lambda*. 

### Creación del OAC
<a name="create-oac-lambda"></a>

Para crear un OAC, puede utilizar la Consola de administración de AWS, CloudFormation, la AWS CLI o la API de CloudFront.

------
#### [ Console ]

**Creación de un OAC**

1. Inicie sesión en la Consola de administración de AWS y abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. En el panel de navegación, elija **Origin access** (Acceso de origen).

1. Elija **Crear configuración de control**.

1. En el formulario **Crear nuevo OAC**, haga lo siguiente:

   1. Indique un **Nombre** y, opcionalmente, una **Descripción** para el OAC.

   1. En el panel **Configuración**, le recomendamos que deje la predeterminada, **Firmar solicitudes (recomendado)**. Para obtener más información, consulte [Configuración avanzada para el control de acceso de origen](#oac-advanced-settings-lambda).

1. En **Tipo de origen**, elija **Lambda**. 

1. Seleccione **Crear**.
**sugerencia**  
Después de crear el OAC, anote el **Nombre**. Lo necesita en el siguiente procedimiento.

**Cómo agregar un control de acceso de origen a la URL de una función de Lambda en una distribución**

1. Abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Elija una distribución con una URL de función de Lambda a la que desee agregar el OAC y, a continuación, elija la pestaña **Orígenes**.

1. Seleccione la URL de función de Lambda a la que desea agregar el OAC y, a continuación, elija **Editar**.

1. Seleccione **Solo HTTP** para el **Protocolo** de origen.

1. En el menú desplegable **Control de acceso de origen**, elija el nombre de OAC que desee utilizar.

1. Seleccione **Save changes (Guardar cambios)**.

La distribución comienza a implementarse en todas las ubicaciones periféricas de CloudFront. Cuando una ubicación periférica recibe la nueva configuración, firma todas las solicitudes que envía a la URL de función de Lambda.

------
#### [ CloudFormation ]

Para crear un OAC con CloudFormation, utilice el tipo de recurso `AWS::CloudFront::OriginAccessControl`. En el siguiente ejemplo se muestra la sintaxis de plantilla de CloudFormation, en formato YAML, para crear un OAC.

```
Type: AWS::CloudFront::OriginAccessControl
Properties: 
  OriginAccessControlConfig: 
      Description: An optional description for the origin access control
      Name: ExampleOAC
      OriginAccessControlOriginType: lambda
      SigningBehavior: always
      SigningProtocol: sigv4
```

Para obtener más información, consulte [AWS::CloudFront::OriginAccessControl](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-originaccesscontrol.html) en la *Guía del usuario de AWS CloudFormation*.

------
#### [ CLI ]

Para crear un control de acceso de origen con la AWS Command Line Interface (AWS CLI), utilice el comando **aws cloudfront create-origin-access-control**. Puede utilizar un archivo de entrada para proporcionar los parámetros de entrada del comando, en lugar de especificar cada parámetro individual como entrada de la línea de comandos.

**Para crear un control de acceso de origen (CLI con archivo de entrada)**

1. Utilice el siguiente comando para crear un archivo llamado `origin-access-control.yaml`. Este archivo contiene todos los parámetros de entrada para el comando **create-origin-access-control**.

   ```
   aws cloudfront create-origin-access-control --generate-cli-skeleton yaml-input > origin-access-control.yaml
   ```

1. Abra el archivo `origin-access-control.yaml` que acaba de crear. Edite el archivo para agregar un nombre para el OAC, una descripción (opcional) y cambie `SigningBehavior` por `always`. A continuación, guarde el archivo.

   Para obtener información sobre otras configuraciones de OAC, consulte [Configuración avanzada para el control de acceso de origen](#oac-advanced-settings-lambda).

1. Utilice el siguiente comando para crear el control de acceso de origen mediante los parámetros de entrada del archivo `origin-access-control.yaml`.

   ```
   aws cloudfront create-origin-access-control --cli-input-yaml file://origin-access-control.yaml
   ```

   Anote el valor de `Id` en la salida del comando. Se necesita para agregar el OAC a una URL de función de Lambda en una distribución de CloudFront.

**Cómo adjuntar un OAC a una URL de función de Lambda en una distribución existente (CLI con archivo de entrada)**

1. Utilice el comando siguiente para guardar la configuración de distribución de la distribución de CloudFront a la que desea agregar el OAC. La distribución debe tener una URL de función de Lambda como el origen.

   ```
   aws cloudfront get-distribution-config --id <CloudFront distribution ID> --output yaml > dist-config.yaml
   ```

1. Abra el archivo llamado `dist-config.yaml` que acaba de crear. Edite el archivo y realice los siguientes cambios:
   + En el objeto `Origins`, agregue el ID de OAC al campo que se llama `OriginAccessControlId`.
   + Elimine el valor del campo que se llama `OriginAccessIdentity`, si existe.
   + Cambie el nombre del campo `ETag` a `IfMatch`, pero no cambie el valor del campo.

   Guarde el archivo cuando haya terminado.

1. Utilice el siguiente comando para actualizar la distribución y utilizar el control de acceso de origen.

   ```
   aws cloudfront update-distribution --id <CloudFront distribution ID> --cli-input-yaml file://dist-config.yaml
   ```

La distribución comienza a implementarse en todas las ubicaciones periféricas de CloudFront. Cuando una ubicación periférica recibe la nueva configuración, firma todas las solicitudes que envía a la URL de función de Lambda.

------
#### [ API ]

Para crear un OAC con la API de CloudFront, utilice [CreateOriginAccessControl](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateOriginAccessControl.html). Para obtener más información sobre los campos que especifique en esta llamada a la API, consulte la documentación de referencia de la API para el SDK de AWS u otro cliente de la API.

Después de crear un OAC, puede adjuntarlo a una URL de función de Lambda en una distribución, mediante una de las siguientes llamadas a la API:
+ Para asociarlo a una distribución existente, utilice [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html).
+ Para asociarlo a una nueva distribución, utilice [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html).

Para estas dos llamadas a la API, proporcione el ID de OAC en el campo `OriginAccessControlId`, dentro de un origen. Para obtener más información sobre los otros campos que especifique en estas llamadas a la API, la documentación de referencia de la API para AWS SDK u otro cliente de la API.

------

## Configuración avanzada para el control de acceso de origen
<a name="oac-advanced-settings-lambda"></a>

La característica de OAC de CloudFront incluye configuraciones avanzadas que están pensadas solo para casos de uso específicos. Utilice la configuración recomendada a menos que tenga una necesidad específica de la configuración avanzada.

El OAC contiene una configuración denominada **Comportamiento de firma** (en la consola) o `SigningBehavior` (en la API, CLI y CloudFormation). Esta configuración proporciona las siguientes opciones:

**Firmar siempre las solicitudes de origen (configuración recomendada)**  
Recomendamos utilizar esta configuración, denominada **Firmar solicitudes (recomendado)** en la consola o `always` en la API, la CLI y CloudFormation. Con esta configuración, CloudFront siempre firma todas las solicitudes que envía a la URL de función de Lambda.

**Nunca firmar solicitudes de origen**  
Esta configuración se denomina **No firmar solicitudes** en la consola o `never` en la API, la CLI y CloudFormation. Utilice esta configuración con el fin de desactivar el OAC para todos los orígenes en todas las distribuciones que utilizan este OAC. Esto puede ahorrar tiempo y esfuerzo en comparación con la eliminación de un OAC de todos los orígenes y distribuciones que lo utilizan, uno por uno. Con esta configuración, CloudFront no ninguna solicitud que envía a la URL de función de Lambda.  
Para utilizar esta configuración, la URL de función de Lambda debe ser de acceso público. Si utiliza esta configuración con una URL de función de Lambda que no es de acceso público, CloudFront no podrá acceder al origen. La URL de función de Lambda devuelve errores a CloudFront y CloudFront pasa esos errores a los lectores. Para obtener más información, consulte [Modelo de seguridad y autenticación para URL de funciones de Lambda](https://docs.aws.amazon.com/lambda/latest/dg/urls-auth.html) en la *Guía del usuario de AWS Lambda*.

**No anular el encabezado `Authorization` del lector (cliente)**  
Esta configuración se denomina **Do not override authorization header** (No anular el encabezado authorization en la consola o `no-override` en la API, la CLI y CloudFormation. Utilice esta configuración cuando desee que CloudFront firme las solicitudes de origen solo cuando la solicitud del lector correspondiente no incluya un encabezado `Authorization`. Con esta configuración, CloudFront pasa el encabezado `Authorization` de la solicitud del lector cuando hay uno, pero firma la solicitud de origen (agrega su propio encabezado `Authorization`) cuando la solicitud del lector no incluye un encabezado `Authorization`.  
+ Si usa esta configuración, debe especificar la firma de Signature Version 4 para la URL de la función de Lambda en lugar del nombre o CNAME de la distribución de CloudFront. Cuando CloudFront reenvíe el encabezado `Authorization` de la solicitud del lector a la URL de la función de Lambda, Lambda validará la firma con respecto al host del dominio de la URL de Lambda. Si la firma no se basa en el dominio de la URL de Lambda, el host de la firma no coincidirá con el host utilizado por el origen de la URL de Lambda. Esto significa que la solicitud producirá un error, lo que provocará un error de validación de firma.
+ Para pasar el encabezado `Authorization` de la solicitud del lector, *debe* agregar el encabezado `Authorization` a una [política de caché](controlling-the-cache-key.md) para todos los comportamientos de caché que utilizan las URL de función de Lambda asociadas con este control de acceso de origen.

## Código de plantilla de ejemplo
<a name="example-template-code-lambda-oac"></a>

Si el origen de CloudFront es la URL de una función de Lambda asociada a un OAC, puede utilizar el siguiente script de Python para cargar archivos en la función de Lambda con el método `POST`. 

Este código asume que configuró el OAC con el comportamiento de firma predeterminado establecido en **Firmar siempre las solicitudes de origen** y que no seleccionó la configuración **No anular el encabezado authorization**.

Esta configuración permite al OAC administrar correctamente la autorización de SigV4 con Lambda mediante el nombre de host de Lambda. La carga útil se firma mediante SigV4 desde la identidad de IAM autorizada para la URL de la función de Lambda, que se designa como tipo `IAM_AUTH`. 

La plantilla muestra cómo administrar los valores hash de la carga útil firmados en el encabezado x-amz-content-sha256 de las solicitudes `POST` del lado del cliente. En concreto, esta plantilla está diseñada para administrar las cargas útiles de datos de los formularios. La plantilla permite cargar archivos de forma segura a una URL de la función de Lambda a través de CloudFront y utiliza mecanismos de autenticación de AWS para garantizar que solo las solicitudes autorizadas puedan acceder a la función de Lambda.

**El código incluye las siguientes funcionalidades:**  
Cumple con el requisito de incluir el hash de carga útil en el encabezado x-amz-content-sha256.
Utiliza la autenticación SigV4 para un acceso seguro de Servicio de AWS.
Admite la carga de archivos mediante el uso de datos de formularios multiparte
Incluye la gestión de errores para las excepciones de las solicitudes.

```
import boto3
from botocore.auth import SigV4Auth
from botocore.awsrequest import AWSRequest
import requests
import hashlib
import os


def calculate_body_hash(body):
    return hashlib.sha256(body).hexdigest()


def sign_request(request, credentials, region, service):
    sigv4 = SigV4Auth(credentials, service, region)
    sigv4.add_auth(request)


def upload_file_to_lambda(cloudfront_url, file_path, region):
    # AWS credentials
    session = boto3.Session()
    credentials = session.get_credentials()

    # Prepare the multipart form-data
    boundary = "------------------------boundary"

    # Read file content
    with open(file_path, 'rb') as file:
        file_content = file.read()

    # Get the filename from the path
    filename = os.path.basename(file_path)

    # Prepare the multipart body
    body = (
        f'--{boundary}\r\n'
        f'Content-Disposition: form-data; name="file"; filename="{filename}"\r\n'
        f'Content-Type: application/octet-stream\r\n\r\n'
    ).encode('utf-8')
    body += file_content
    body += f'\r\n--{boundary}--\r\n'.encode('utf-8')

    # Calculate SHA256 hash of the entire body
    body_hash = calculate_body_hash(body)

    # Prepare headers
    headers = {
        'Content-Type': f'multipart/form-data; boundary={boundary}',
        'x-amz-content-sha256': body_hash
    }

    # Create the request
    request = AWSRequest(
        method='POST',
        url=cloudfront_url,
        data=body,
        headers=headers
    )

    # Sign the request
    sign_request(request, credentials, region, 'lambda')

    # Get the signed headers
    signed_headers = dict(request.headers)

    # Print request headers before sending
    print("Request Headers:")
    for header, value in signed_headers.items():
        print(f"{header}: {value}")

    try:
        # Send POST request with signed headers
        response = requests.post(
            cloudfront_url,
            data=body,
            headers=signed_headers
        )

        # Print response status and content
        print(f"\nStatus code: {response.status_code}")
        print("Response:", response.text)

        # Print response headers
        print("\nResponse Headers:")
        for header, value in response.headers.items():
            print(f"{header}: {value}")

    except requests.exceptions.RequestException as e:
        print(f"An error occurred: {e}")


# Usage
cloudfront_url = "https://d111111abcdef8.cloudfront.net"
file_path = r"filepath"
region = "us-east-1"  # example: "us-west-2"

upload_file_to_lambda(cloudfront_url, file_path, region)
```

# Restricción del acceso a un origen de Amazon S3
<a name="private-content-restricting-access-to-s3"></a>

CloudFront proporciona dos formas de enviar solicitudes autenticadas a un origen de Amazon S3: *control de acceso de origen (OAC)* e *identidad de acceso de origen (OAI)*. OAC lo ayuda a proteger los orígenes, como en el caso de Amazon S3. 

*Le recomendamos* que utilice OAC en su lugar porque es compatible con las siguientes características:
+ Todos los buckets de Amazon S3 en todas las Regiones de AWS, incluidas las regiones opcionales lanzadas después de diciembre de 2022
+ [Cifrado del servidor con AWS KMS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) de Amazon S3 (SSE-KMS)
+ Solicitudes dinámicas (`PUT` y `DELETE`) en Amazon S3

OAI no es compatible con estas características o requiere soluciones alternativas adicionales en esos escenarios. Si ya utiliza OAI y desea migrar, consulte [Migración de la identidad de acceso de origen (OAI) al control de acceso de origen (OAC)](#migrate-from-oai-to-oac).

**Notas**  
Si utiliza CloudFront OAC con orígenes de buckets de Amazon S3, debe establecer **Propiedad de objetos de Amazon S3** como **Aplicada al propietario del bucket**, que es el valor predeterminado para los nuevos buckets de Amazon S3. Si necesita ACL, utilice la configuración **Preferida del propietario del bucket** para mantener el control de los objetos cargados mediante CloudFront.
Si su origen es un bucket de Amazon S3 configurado como [punto de conexión de sitio web](https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteEndpoints.html), debe configurarlo con CloudFront como un origen personalizado. Esto significa que no puede utilizar OAC (nila OAI). OAC no admite el redireccionamiento de origen mediante Lambda@Edge.

En los temas siguientes se describe cómo utilizar la OAC con un origen de Amazon S3. 

**Temas**
+ [Creación de un nuevo control de acceso de origen](#create-oac-overview-s3)
+ [Eliminación de una distribución con un OAC adjunto a un bucket de S3](#delete-oac-distribution-s3)
+ [Migración de la identidad de acceso de origen (OAI) al control de acceso de origen (OAC)](#migrate-from-oai-to-oac)
+ [Configuración avanzada para el control de acceso de origen](#oac-advanced-settings-s3)

## Creación de un nuevo control de acceso de origen
<a name="create-oac-overview-s3"></a>

Complete los pasos que se describen en los siguientes temas para configurar un nuevo control de acceso de origen en CloudFront.

**Topics**
+ [Requisitos previos](#oac-prerequisites-s3)
+ [Concesión de permiso de CloudFront para acceder al bucket de S3](#oac-permission-to-access-s3)
+ [Creación del control de acceso de origen](#create-oac-s3)

### Requisitos previos
<a name="oac-prerequisites-s3"></a>

Antes de crear y configurar el control de acceso de origen (OAC), debe tener una distribución de CloudFront con un bucket de origen de Amazon S3. Este origen debe ser un bucket S3 normal, no un bucket configurado como [punto de conexión de sitio web](https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteEndpoints.html). Para obtener más información sobre la configuración de una distribución de CloudFront con un origen de bucket de S3, consulte [Introducción a una distribución estándar de CloudFront](GettingStarted.SimpleDistribution.md).

**importante**  
Cuando utiliza OAC para proteger el origen de Amazon S3, la comunicación entre CloudFront y Amazon S3 es *siempre* a través de HTTPS, pero solo cuando elige *firmar siempre las solicitudes*. Debe elegir **Firmar solicitudes (recomendado)** en la consola o especificar `always` en la API de CloudFront, AWS CLI o CloudFormation.   
Si, en su lugar, elige la opción **No firmar solicitudes** o **No invalidar el encabezado de autorización**, CloudFront utiliza el protocolo de conexión que especificó en las siguientes políticas:  
[Política de protocolo para lectores](using-https-viewers-to-cloudfront.md) 
[Política de protocolo de origen](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy) (solo orígenes personalizados)
Por ejemplo, si elige **No invalidar el encabezado de autorización** y desea utilizar HTTPS entre CloudFront y el origen de Amazon S3, utilice **Redirigir HTTP a HTTPS** o **Solo HTTPS** para la [política de protocolo del lector](using-https-viewers-to-cloudfront.md).

### Concesión de permiso de CloudFront para acceder al bucket de S3
<a name="oac-permission-to-access-s3"></a>

Antes de crear un control de acceso de origen (OAC) o configurarlo en una distribución de CloudFront, asegúrese de que CloudFront tiene permiso para acceder al origen del bucket de S3. Realice esta acción después de crear una distribución de CloudFront, pero antes de agregar el OAC al origen de S3 en la configuración de distribución.

Utilice una [política de bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html) de S3 para permitir a la entidad principal de servicio de CloudFront (`cloudfront.amazonaws.com`) acceder al bucket. Utilice un elemento `Condition` en la política para permitir que CloudFront acceda al bucket solo cuando la solicitud sea en nombre de la distribución de CloudFront que contiene el origen de S3. Esta es la distribución con el origen de S3 al que desea agregar OAC.

Para obtener información sobre cómo agregar o modificar una política de bucket, consulte [Agregar una política de bucket mediante la consola de Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html) en la *Guía del usuario de Amazon S3*.

A continuación, se muestran ejemplos de políticas de bucket de S3 que permiten a una distribución de CloudFront con OAC habilitado el acceso a un origen de S3.

**Example Política de bucket de S3 que permite el acceso de solo lectura a una distribución de CloudFront con OAC habilitado**    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "AllowCloudFrontServicePrincipalReadOnly",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/<CloudFront distribution ID>"
        }
      }
    }
  ]
}
```

**Example Política de bucket de S3 que permite el acceso de lectura y escritura a una distribución de CloudFront con OAC habilitado**    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "AllowCloudFrontServicePrincipalReadWrite",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/CloudFront-distribution-ID>"
        }
      }
    }
  ]
}
```

#### SSE-KMS
<a name="oac-permissions-sse-kms"></a>

Si los objetos del origen de bucket de S3 están cifrados mediante el [cifrado del servidor con AWS Key Management Service (SSE-KMS)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html), debe asegurarse de que la distribución de CloudFront tiene permiso para utilizar la clave de AWS KMS. Para conceder permiso de distribución de CloudFront para utilizar la clave de KMS, agregue una declaración a la [política de claves de KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html). Para obtener información sobre cómo modificar una política de claves, consulte [Modificación de una política de claves](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html) en la *Guía del desarrollador de AWS Key Management Service*.

**Example Instrucción de política de claves de KMS**  
El siguiente ejemplo muestra una declaración de política de AWS KMS que permite a la distribución de CloudFront con OAC acceder a una clave de KMS para SSE-KMS.  

```
{
    "Sid": "AllowCloudFrontServicePrincipalSSE-KMS",
    "Effect": "Allow",
    "Principal": {
        "Service": [
            "cloudfront.amazonaws.com"
        ]
     },
    "Action": [
        "kms:Decrypt",
        "kms:Encrypt",
        "kms:GenerateDataKey*"
    ],
    "Resource": "*",
    "Condition": {
            "StringEquals": {
                "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/<CloudFront distribution ID>"
            }
        }
}
```

### Creación del control de acceso de origen
<a name="create-oac-s3"></a>

Para crear un control de acceso de origen (OAC), puede utilizar la Consola de administración de AWS, CloudFormation, la AWS CLI o la API de CloudFront.

------
#### [ Console ]

**Para crear un control de acceso de origen**

1. Inicie sesión en la Consola de administración de AWS y abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. En el panel de navegación, elija **Origin access** (Acceso de origen).

1. Elija **Create control setting** (Crear configuración de control).

1. En el formulario **Create control setting** (Crear configuración de control), haga lo siguiente:

   1. En el panel **Details** (Detalles), ingrese un valor para **Name** (Nombre) y (opcionalmente) para **Description** (Descripción) para el control de acceso de origen.

   1. En el panel **Settings** (Configuración), le recomendamos que deje la configuración predeterminada **Sign requests (recommended)** (Firmar solicitudes [recomendado]). Para obtener más información, consulte [Configuración avanzada para el control de acceso de origen](#oac-advanced-settings-s3).

1. Elija S3 en el menú desplegable de **Origin type** (Tipo de origen).

1. Seleccione **Crear**.

   Una vez creado el OAC, anote el valor de **Name** (Nombre). Lo necesita en el siguiente procedimiento.

**Para agregar un control de acceso de origen a un origen de S3 en una distribución**

1. Abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Elija una distribución con un origen de S3 a la que desee agregar el OAC y, a continuación, elija la pestaña **Origins** (Orígenes).

1. Seleccione el origen de S3 al que desea agregar el OAC y, a continuación, elija **Edit** (Editar).

1. En la sección **Acceso de origen**, elija **(Configuración del control de acceso de origen (recomendado)**.

1. En el menú desplegable **Origin access control** (Control de acceso de origen), elija el OAC que desee utilizar.

1. Seleccione **Save changes (Guardar cambios)**.

La distribución comienza a implementarse en todas las ubicaciones periféricas de CloudFront. Cuando una ubicación periférica recibe la nueva configuración, firma todas las solicitudes que envía al origen de bucket de S3.

------
#### [ CloudFormation ]

Para crear un control de acceso de origen (OAC) con CloudFormation, utilice el tipo de recurso `AWS::CloudFront::OriginAccessControl`. El siguiente ejemplo se muestra la sintaxis de plantilla de CloudFormation, en formato YAML, para crear un control de acceso de origen.

```
Type: AWS::CloudFront::OriginAccessControl
Properties: 
  OriginAccessControlConfig: 
      Description: An optional description for the origin access control
      Name: ExampleOAC
      OriginAccessControlOriginType: s3
      SigningBehavior: always
      SigningProtocol: sigv4
```

Para obtener más información, consulte [AWS::CloudFront::OriginAccessControl](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-originaccesscontrol.html) en la *Guía del usuario de AWS CloudFormation*.

------
#### [ CLI ]

Para crear un control de acceso de origen con la AWS Command Line Interface (AWS CLI), utilice el comando **aws cloudfront create-origin-access-control**. Puede utilizar un archivo de entrada para proporcionar los parámetros de entrada del comando, en lugar de especificar cada parámetro individual como entrada de la línea de comandos.

**Para crear un control de acceso de origen (CLI con archivo de entrada)**

1. Utilice el siguiente comando para crear un archivo llamado `origin-access-control.yaml`. Este archivo contiene todos los parámetros de entrada para el comando **create-origin-access-control**.

   ```
   aws cloudfront create-origin-access-control --generate-cli-skeleton yaml-input > origin-access-control.yaml
   ```

1. Abra el archivo `origin-access-control.yaml` que acaba de crear. Edite el archivo para agregar un nombre para el OAC, una descripción (opcional) y cambie `SigningBehavior` por `always`. A continuación, guarde el archivo.

   Para obtener información sobre otras configuraciones de OAC, consulte [Configuración avanzada para el control de acceso de origen](#oac-advanced-settings-s3).

1. Utilice el siguiente comando para crear el control de acceso de origen mediante los parámetros de entrada del archivo `origin-access-control.yaml`.

   ```
   aws cloudfront create-origin-access-control --cli-input-yaml file://origin-access-control.yaml
   ```

   Anote el valor de `Id` en la salida del comando. Lo necesita para agregar el OAC a un origen de bucket de S3 en una distribución de CloudFront.

**Para adjuntar un OAC a un origen de bucket de S3 en una distribución existente (CLI con archivo de entrada)**

1. Utilice el comando siguiente para guardar la configuración de distribución de la distribución de CloudFront a la que desea agregar el OAC. La distribución debe tener un origen de bucket de S3.

   ```
   aws cloudfront get-distribution-config --id <CloudFront distribution ID> --output yaml > dist-config.yaml
   ```

1. Abra el archivo llamado `dist-config.yaml` que acaba de crear. Edite el archivo y realice los siguientes cambios:
   + En el objeto `Origins`, agregue el ID de OAC al campo que se llama `OriginAccessControlId`.
   + Elimine el valor del campo que se llama `OriginAccessIdentity`, si existe.
   + Cambie el nombre del campo `ETag` a `IfMatch`, pero no cambie el valor del campo.

   Guarde el archivo cuando haya terminado.

1. Utilice el siguiente comando para actualizar la distribución y utilizar el control de acceso de origen.

   ```
   aws cloudfront update-distribution --id <CloudFront distribution ID> --cli-input-yaml file://dist-config.yaml
   ```

La distribución comienza a implementarse en todas las ubicaciones periféricas de CloudFront. Cuando una ubicación periférica recibe la nueva configuración, firma todas las solicitudes que envía al origen de bucket de S3.

------
#### [ API ]

Para crear un control de acceso de origen con la API de CloudFront, utilice [CreateOriginAccessControl](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateOriginAccessControl.html). Para obtener más información sobre los campos que especifique en esta llamada a la API, consulte la documentación de referencia de la API para el SDK de AWS u otro cliente de la API.

Después de crear un control de acceso de origen, puede adjuntarlo a un origen de bucket de S3 en una distribución, mediante una de las siguientes llamadas a la API:
+ Para asociarlo a una distribución existente, utilice [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html).
+ Para asociarlo a una nueva distribución, utilice [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html).

Para estas dos llamadas a la API, proporcione el ID de control de acceso de origen en el campo `OriginAccessControlId`, dentro de un origen. Para obtener más información sobre los otros campos que especifique en estas llamadas a la API, consulte [Referencia de toda la configuración de distribución](distribution-web-values-specify.md) y la documentación de referencia de la API para el SDK de AWS u otro cliente de la API.

------

## Eliminación de una distribución con un OAC adjunto a un bucket de S3
<a name="delete-oac-distribution-s3"></a>

Si necesita eliminar una distribución con un OAC adjunto a un bucket de S3, debe eliminarla antes de eliminar el origen del bucket de S3. También puede incluir la región en el nombre de dominio de origen. Si no es posible, puede eliminar el OAC de la distribución mediante el cambio a público antes de la eliminación. Para obtener más información, consulte [Eliminar una distribución](HowToDeleteDistribution.md).

## Migración de la identidad de acceso de origen (OAI) al control de acceso de origen (OAC)
<a name="migrate-from-oai-to-oac"></a>

Para migrar de una identidad de acceso de origen (OAI) heredada a un control de acceso de origen (OAC), actualice primero el origen del bucket de S3 para permitir que OAI y la distribución con OAC habilitado accedan al contenido del bucket. De este modo se garantiza que CloudFront nunca pierda el acceso al bucket durante la transición. Para permitir que OAI y la distribución con OAC habilitado accedan a un bucket de S3, actualice la [política de bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html) para incluir dos declaraciones, una para cada tipo de entidad principal.

El siguiente ejemplo de política de bucket de S3 permite que una OAI y una distribución con OAC habilitado accedan a un origen de S3.

**Example Política de bucket de S3 que permite el acceso de solo lectura para una OAI y una distribución de CloudFront con OAC habilitado**    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowCloudFrontServicePrincipalReadOnly",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<S3 bucket name>/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/<CloudFront distribution ID>"
                }
            }
        },
        {
            "Sid": "AllowLegacyOAIReadOnly",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity <origin access identity ID>"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<S3 bucket name>/*"
        }
    ]
}
```

Después de actualizar la política de buckets del origen de S3 para permitir el acceso tanto a OAI como a OAC, puede actualizar la configuración de la distribución para utilizar OAC en lugar de OAI. Para obtener más información, consulte [Creación de un nuevo control de acceso de origen](#create-oac-overview-s3).

Una vez implementada por completo la distribución, puede eliminar la declaración de la política de buckets que permite el acceso a la OAI. Para obtener más información, consulte [Concesión de permiso de CloudFront para acceder al bucket de S3](#oac-permission-to-access-s3).

## Configuración avanzada para el control de acceso de origen
<a name="oac-advanced-settings-s3"></a>

La característica de control de acceso de origen de CloudFront incluye configuraciones avanzadas que están pensadas solo para casos de uso específicos. Utilice la configuración recomendada a menos que tenga una necesidad específica de la configuración avanzada.

El control de acceso de origen contiene una configuración denominada **Signing behavior** (Comportamiento de firma) (en la consola) o `SigningBehavior` (en la API, CLI y CloudFormation). Esta configuración proporciona las siguientes opciones:

**Firmar siempre las solicitudes de origen (configuración recomendada)**  
Recomendamos utilizar esta configuración, denominada **Sign requests (recommended)** (Firmar solicitudes [recomendado]) en la consola o `always` en la API, la CLI y CloudFormation. Con esta configuración, CloudFront siempre firma todas las solicitudes que envía al origen de bucket de S3.

**Nunca firmar solicitudes de origen**  
Esta configuración se denomina **Do not sign requests** (No firmar solicitudes) en la consola o `never` en la API, la CLI y CloudFormation. Utilice esta configuración para desactivar el control de acceso de origen para todos los orígenes en todas las distribuciones que utilizan este control de acceso de origen. Esto puede ahorrar tiempo y esfuerzo en comparación con la eliminación de un control de acceso de origen de todos los orígenes y distribuciones que lo utilizan, uno por uno. Con esta configuración, CloudFront no firma las solicitudes que envía al origen de bucket de S3.  
Para utilizar esta configuración, el origen de bucket de S3 debe ser de acceso público. Si utiliza esta configuración con un origen de bucket de S3 que no es de acceso público, CloudFront no podrá acceder al origen. El origen de bucket de S3 devuelve errores a CloudFront y CloudFront pasa esos errores a los lectores.

**No anular el encabezado `Authorization` del lector (cliente)**  
Esta configuración se denomina **Do not override authorization header** (No anular el encabezado authorization en la consola o `no-override` en la API, la CLI y CloudFormation. Utilice esta configuración cuando desee que CloudFront firme las solicitudes de origen solo cuando la solicitud del lector correspondiente no incluya un encabezado `Authorization`. Con esta configuración, CloudFront pasa el encabezado `Authorization` de la solicitud del lector cuando hay uno, pero firma la solicitud de origen (agrega su propio encabezado `Authorization`) cuando la solicitud del lector no incluye un encabezado `Authorization`.  
Para pasar el encabezado `Authorization` de la solicitud del lector, *debe* agregar el encabezado `Authorization` a una [política de caché](controlling-the-cache-key.md) para todos los comportamientos de caché que utilizan los orígenes de buckets de S3 asociados con este control de acceso de origen.

## Uso de una identidad de acceso de origen (heredado, no recomendado)
<a name="private-content-restricting-access-to-s3-oai"></a>

### Descripción de la identidad de acceso de origen
<a name="private-content-restricting-access-to-s3-overview"></a>

La *identidad de acceso de origen* (OAI) de CloudFront proporciona una funcionalidad similar a la del *control de acceso de origen* (OAC), pero no funciona en todos los escenarios. En concreto, OAI no admite:
+ Buckets de Amazon S3 en todas las Regiones de AWS, incluidas las regiones opcionales
+ [Cifrado del servidor con AWS KMS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) de Amazon S3 (SSE-KMS)
+ Solicitudes dinámicas (`PUT`, `POST` o `DELETE`) en Amazon S3
+ Regiones de AWS nuevas lanzadas después de enero de 2023

**sugerencia**  
Le recomendamos que utilice OAC en su lugar. Para configurar OAC, consulte [Creación de un nuevo control de acceso de origen](#create-oac-overview-s3). Para obtener información acerca de cómo migrar de OAI a OAC, consulte [Migración de la identidad de acceso de origen (OAI) al control de acceso de origen (OAC)](#migrate-from-oai-to-oac).

### Concesión de un permiso de identidad de acceso de origen para leer archivos en el bucket de Amazon S3
<a name="private-content-granting-permissions-to-oai"></a>

Cuando crea una OAI o agrega una a una distribución con la consola de CloudFront, puede actualizar automáticamente la política de bucket de Amazon S3 para conceder a la OAI permiso de acceso al bucket. Como alternativa, puede elegir crear o actualizar manualmente la política del bucket. Sea cual sea el método que utilice, debe revisar los permisos para asegurarse de que:
+ La OAI de CloudFront puede acceder a los archivos del bucket en nombre de los lectores que los soliciten a través de CloudFront.
+ Los lectores no pueden utilizar las URL de Amazon S3 para acceder a los archivos fuera de CloudFront.

**importante**  
Si configura CloudFront para que acepte y reenvíe todos los métodos HTTP compatibles con CloudFront, asegúrese de conceder a la OAI de CloudFront los permisos deseados. Por ejemplo, si configura CloudFront para aceptar y reenviar solicitudes que utilizan el método `DELETE`, configure la política de bucket para que gestionen las solicitudes `DELETE` de forma adecuada para que los lectores solo puedan eliminar archivos que desee que eliminen.

#### Uso de políticas de buckets de Amazon S3
<a name="private-content-updating-s3-bucket-policies"></a>

Puede conceder a la OAI de CloudFront acceso a los archivos de un bucket de Amazon S3 mediante la creación o actualización de la política de bucket de las siguientes maneras:
+ Mediante la pestaña **Permissions** (Permisos) del bucket de Amazon S3 en la [consola de Amazon S3](https://console.aws.amazon.com/s3/home).
+ Mediante [PutBucketPolicy](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketPolicy.html) en la API de Amazon S3.
+ Mediante la [consola de CloudFront](https://console.aws.amazon.com/cloudfront/v4/home). Cuando agrega una OAI a la configuración de origen en la consola de CloudFront, puede elegir **Yes, update the bucket policy** (Sí, actualizar política de bucket) para indicar a CloudFront que actualice la política del bucket en su nombre.

Si actualiza la política del bucket manualmente, asegúrese de:
+ Especificar la OAI correcta como `Principal` en la política.
+ Conceder a la OAI los permisos que necesita para obtener acceso a los objetos en nombre de los lectores.

Para obtener más información, consulte las siguientes secciones.

##### Cómo especificar una OAI como `Principal` en una política de bucket
<a name="private-content-updating-s3-bucket-policies-principal"></a>

Para especificar una OAI como `Principal` en una política de bucket de Amazon S3, utilice el nombre de recurso de Amazon (ARN) de la OAI, que incluye el ID de la OAI. Por ejemplo:

```
"Principal": {
    "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity <origin access identity ID>"
}
```

Busque el ID de OAI en la consola de CloudFront, en **Seguridad**, **Acceso de origen**, **Identidades (heredado)**. Como alternativa, utilice [ListCloudFrontOriginAccessIdentities](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListCloudFrontOriginAccessIdentities.html) en la API de CloudFront.

##### Conceda permisos a una OAI
<a name="private-content-updating-s3-bucket-policies-permissions"></a>

Para conceder a la OAI permisos para acceder a los objetos del bucket de Amazon S3, utilice acciones de la política relacionadas con operaciones específicas de la API de Amazon S3. Por ejemplo, la acción `s3:GetObject` permite a la OAI leer objetos del bucket. Para obtener más información, consulte los ejemplos de la siguiente sección o consulte [acciones de Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/using-with-s3-actions.html) en la *Guía del usuario de Amazon Simple Storage Service*.

##### Ejemplos de políticas de bucket de Amazon S3
<a name="private-content-updating-s3-bucket-policies-examples"></a>

En los siguientes ejemplos se muestran las políticas de buckets de Amazon S3 que permiten a la OAI de CloudFront acceder a un bucket de S3.

Busque el ID de OAI en la consola de CloudFront, en **Seguridad**, **Acceso de origen**, **Identidades (heredado)**. Como alternativa, utilice [ListCloudFrontOriginAccessIdentities](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListCloudFrontOriginAccessIdentities.html) en la API de CloudFront.

**Example Política de bucket de Amazon S3 que concede acceso de lectura a la OAI**  
El siguiente ejemplo permite a la OAI leer objetos del bucket especificado (`s3:GetObject`).    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity <origin access identity ID>"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<S3 bucket name>/*"
        }
    ]
}
```

**Example Política de bucket de Amazon S3 que concede acceso de lectura y escritura a la OAI**  
El siguiente ejemplo permite a la OAI leer y escribir objetos en el bucket (`s3:GetObject` y `s3:PutObject`) especificado. Esto permite a los lectores cargar archivos en el bucket de Amazon S3 a través de CloudFront.    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity <origin access identity ID>"
            },
            "Action": [
                "s3:GetObject",
                "s3:PutObject"
            ],
            "Resource": "arn:aws:s3:::<S3 bucket name>/*"
        }
    ]
}
```

#### Uso de ACL de objetos de Amazon S3 (no recomendado)
<a name="private-content-updating-s3-acls"></a>

**importante**  
Recomendamos el [uso de las políticas de bucket de Amazon S3](#private-content-updating-s3-bucket-policies) para conceder a una OAI acceso a un bucket de S3. Puede utilizar listas de control de acceso (ACL) como se describe en esta sección, pero no lo recomendamos.  
Amazon S3 recomienda configurar [Propiedad de objetos de S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html) como **propietario del bucket forzado**, lo que significa que las ACL están desactivadas para el bucket y los objetos que contiene. Al aplicar esta configuración para Propiedad de objetos, debe utilizar políticas de bucket para dar acceso a la OAI (consulte la sección anterior).  
La sección siguiente es solo para casos de uso heredados que requieren ACL.

Puede conceder a una OAI de CloudFront acceso a los archivos de un bucket de Amazon S3 creando o actualizando la ACL de archivos de las siguientes maneras:
+ Mediante la pestaña **Permissions** (Permisos) del objeto de Amazon S3 en la [consola de Amazon S3](https://console.aws.amazon.com/s3/home).
+ Mediante [PutObjectAcl](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObjectAcl.html) en la API de Amazon S3.

Cuando concede acceso a una OAI mediante una ACL, debe especificar la OAI mediante el ID de usuario canónico de Amazon S3. En la consola de CloudFront, puede encontrar este ID en **Seguridad**, **Acceso de origen**, **Identidades (heredado)**. Si utiliza la API de CloudFront, use el valor del elemento `S3CanonicalUserId` devuelto al crear la OAI o llame a [ListCloudFrontOriginAccessIdentities](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListCloudFrontOriginAccessIdentities.html) en la API de CloudFront.

### Uso de una identidad de acceso de origen en las regiones de Amazon S3 que solo admiten la autenticación de Signature Version 4
<a name="private-content-origin-access-identity-signature-version-4"></a>

Las regiones de Amazon S3 más recientes requieren que utilice Signature Version 4 para solicitudes autenticadas. (Para ver las versiones de firma admitidas en cada región de Amazon S3, consulte [Puntos de conexión y cuotas de Amazon Simple Storage Service](https://docs.aws.amazon.com/general/latest/gr/s3.html) en la *Referencia general de AWS*). Si utiliza una identidad de acceso de origen y si su bucket se encuentra en una de las regiones que requiere firma versión 4, tenga en cuenta lo siguiente:
+ Las solicitudes `DELETE`, `GET`, `HEAD`, `OPTIONS` y `PATCH` se admiten sin cualificación.
+ `POST`Las solicitudes no están admitidas.

# Restricción del acceso con orígenes de la VPC
<a name="private-content-vpc-origins"></a>

Puede utilizar CloudFront para entregar contenido de las aplicaciones que se alojan en las subredes privadas de la nube privada virtual (VPC). Puede usar equilibradores de carga de aplicación, equilibradores de carga de red e instancias de EC2 en subredes privadas como orígenes de la VPC.

A continuación, se indican algunos de los motivos por los que es posible que desee utilizar Orígenes de la VPC:
+ **Seguridad**: Orígenes de la VPC se ha diseñado para mejorar el estado de seguridad de su aplicación porque coloca sus equilibradores de carga e instancias de EC2 en subredes privadas, lo que convierte a CloudFront en el único punto de entrada. Las solicitudes de los usuarios van de CloudFront a los orígenes de la VPC a través de una conexión privada y segura, lo que proporciona seguridad adicional a las aplicaciones.
+ **Administración**: Orígenes de la VPC reduce la sobrecarga operativa necesaria para una conectividad segura entre CloudFront y los orígenes. Puede trasladar sus orígenes a subredes privadas sin acceso público y no tiene que implementar listas de control de acceso (ACL) ni otros mecanismos para restringir el acceso a sus orígenes. De esta forma, no tiene que invertir en un trabajo de desarrollo indiferenciado para proteger sus aplicaciones web con CloudFront. 
+ **Escalabilidad y rendimiento**: orígenes de la VPC le ayuda a proteger sus aplicaciones web, lo que le permite dedicar tiempo a centrarse en el crecimiento de sus aplicaciones empresariales fundamentales y, al mismo tiempo, mejorar la seguridad y mantener el alto rendimiento y la escalabilidad global con CloudFront. Orígenes de la VPC optimiza la administración de la seguridad y reduce la complejidad operativa para que pueda usar CloudFront como punto de entrada único para sus aplicaciones.

**sugerencia**  
CloudFront permite compartir los orígenes de las VPC compartidos en Cuentas de AWS, estén o no en la organización. Puede compartir los orígenes de la VPC desde la consola de CloudFront o usar AWS Resource Access Manager (AWS RAM). Para obtener más información, consulte [Trabajo con recursos compartidos en CloudFront](sharing-resources.md).

## Requisitos previos
<a name="vpc-origin-prerequisites"></a>

Antes de crear un origen de la VPC para la distribución de CloudFront, debe completar los siguientes pasos:

### Configuración de VPC
<a name="vpc-configuration"></a>

**Cree una nube privada virtual (VPC) en Amazon VPC** en uno de las Regiones de AWS compatibles con los orígenes de VPC. Para obtener información sobre la creación de una VPC, consulte [Creación de una VPC y otros recursos de la VPC](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html#create-vpc-and-other-resources) en la *Guía del usuario de Amazon VPC*. Para obtener una lista de las regiones de admitidas, consulte [Regiones de AWS admitidas para Orígenes de la VPC](#vpc-origins-supported-regions).

Su VPC debe incluir lo siguiente:
+ **Puerta de enlace de Internet**: debe agregar una puerta de enlace de Internet a la VPC que tiene los recursos de origen de la VPC. La puerta de enlace de Internet es necesaria para indicar que la VPC pueda recibir tráfico de Internet. La puerta de enlace de Internet no se usa para enrutar el tráfico a los orígenes dentro de la subred y no es necesario actualizar las políticas de enrutamiento.
+ **Subred privada con al menos una dirección IPv4 disponible**: CloudFront se dirige a la subred mediante una interfaz de red elástica (ENI) administrada por un servicio que CloudFront crea después de definir el recurso de origen de la VPC con CloudFront. Debe tener al menos una dirección IPv4 disponible en su subred privada para que el proceso de creación de la ENI se lleve a cabo correctamente. La dirección IPv4 puede ser privada y no conlleva ningún coste adicional. No se admiten subredes solo de IPv6.

### Recursos de origen
<a name="origin-resources"></a>

En la subred privada, lance un equilibrador de carga de aplicación, un equilibrador de carga de red o una instancia de EC2 para utilizarlos como origen. El recurso que lance debe estar completamente implementado y en estado Activo antes de poder usarlo para un origen de la VPC.

**Restricciones de origen:**
+ Los equilibradores de carga de puerta de enlace no se pueden añadir como orígenes
+ Los equilibradores de carga de red de doble pila no se pueden añadir como orígenes
+ Los equilibradores de carga de red con oyentes de TLS no se pueden añadir como orígenes
+ Para que se utilice como un origen de la VPC, un equilibrador de carga de red debe tener un grupo de seguridad asociado.

### Configuración del grupo de seguridad
<a name="security-group-configuration"></a>

Los recursos de origen de su VPC (Equilibrador de carga de aplicación, Equilibrador de carga de red o instancia de EC2) deben tener asociado un grupo de seguridad. Al crear un origen de VPC, CloudFront crea automáticamente un grupo de seguridad administrado por el servicio con el patrón de nomenclatura `CloudFront-VPCOrigins-Service-SG`. Este grupo de seguridad está totalmente administrado por AWS y no debe modificarse.

Para permitir que el tráfico procedente de CloudFront llegue a su origen de VPC, actualice el grupo de seguridad asociado a su recurso de origen (ALB, NLB o instancia de EC2) para permitir el tráfico entrante utilizando uno de los siguientes métodos:
+ **Opción 1:** permitir el tráfico de la lista de prefijos administrados de CloudFront. Para obtener más información, consulte [Utilizar la lista de prefijos administrados de CloudFront](LocationsOfEdgeServers.md#managed-prefix-list). Esto también se puede hacer antes de crear el origen de VPC.
+ **Opción 2:** permitir el tráfico del grupo de seguridad administrado por el servicio de CloudFront (`CloudFront-VPCOrigins-Service-SG`). Esto solo se puede hacer una vez que se haya creado el origen de la VPC y el grupo de seguridad administrado por el servicio. Esta configuración es aún más restrictiva, ya que limita el tráfico solo a sus distribuciones de CloudFront.

**importante**  
No cree su propio grupo de seguridad cuyo nombre comience por `CloudFront-VPCOrigins-Service-SG`. Este es un patrón de nomenclatura reservado de AWS para grupos de seguridad administrados por el servicio. Para obtener más información, consulte [Creación de un grupo de seguridad](https://docs.aws.amazon.com/vpc/latest/userguide/creating-security-groups.html).

### Restricciones de protocolos y características
<a name="protocol-feature-restrictions"></a>

Los orígenes de VPC no admiten lo siguiente:
+ WebSockets
+ Tráfico de gRPC
+ Desencadenadores de solicitud de origen y respuesta de origen con Lambda@Edge

## Creación de un origen de la VPC (nueva distribución)
<a name="new-vpc-origin"></a>

El siguiente procedimiento muestra cómo crear un origen de la VPC para la nueva distribución de CloudFront en la consola de CloudFront. También puede usar las operaciones de la API [CreateVpcOrigin](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateVpcOrigin.html) y [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html) con la AWS CLI o un SDK de AWS.

**Para crear un origen de la VPC para una nueva distribución de CloudFront**

1. Abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Elija **Orígenes de la VPC**, **Crear origen de la VPC**.

1. Rellene los campos obligatorios. En **ARN de origen**, seleccione el ARN del equilibrador de carga de aplicación, equilibrador de carga de red o la instancia de EC2. Si no ve el ARN, puede copiar el ARN de recurso específico y pegarlo aquí.

1. Elija **Crear origen de la VPC**.

1. Espere a que el estado del origen de la VPC cambie a **Implementado**. Este proceso puede tardar hasta 15 minutos.

1. Elija **Distribuciones**, **Crear distribución**.

1. En **Dominio de origen**, seleccione su recurso de orígenes de la VPC en la lista desplegable.

   Si el origen la VPC es una instancia de EC2, copie y pegue el **nombre DNS de IP privada** de la instancia en el campo **Dominio de origen**.

1. Termine de crear su distribución. Para obtener más información, consulte [Creación de una distribución de CloudFront en la consola](distribution-web-creating-console.md#create-console-distribution).

## Creación de un origen de la VPC (distribución existente)
<a name="existing-vpc-origin"></a>

El siguiente procedimiento muestra cómo crear un origen de la VPC para una distribución de CloudFront existente en la consola de CloudFront, lo que ayuda a garantizar una disponibilidad continua de sus aplicaciones. También puede usar las operaciones de la API [CreateVpcOrigin](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateVpcOrigin.html) y [UpdateDistributionWithStagingConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistributionWithStagingConfig.html) con la AWS CLI o un SDK de AWS.

Si lo desea, puede agregar el origen de la VPC a la distribución existente sin crear una distribución provisional.

**Para crear un origen de la VPC para una distribución existente de CloudFront**

1. Abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Elija **Orígenes de la VPC**, **Crear origen de la VPC**.

1. Rellene los campos obligatorios. En **ARN de origen**, seleccione el ARN del equilibrador de carga de aplicación, equilibrador de carga de red o la instancia de EC2. Si no ve el ARN, puede copiar el ARN de recurso específico y pegarlo aquí.

1. Elija **Crear origen de la VPC**.

1. Espere a que el estado del origen de la VPC cambie a **Implementado**. Este proceso puede tardar hasta 15 minutos.

1. En el panel de navegación, elija **Distribuciones**.

1. Elija el ID de su distribución.

1. En la pestaña **General**, en **Implementación continua**, elija **Crear distribución provisional**. Para obtener más información, consulte [Uso de la implementación continua de CloudFront para probar de forma segura los cambios en la configuración de la CDN](continuous-deployment.md).

1. Siga los pasos del asistente **Crear distribución provisional** para crear una distribución provisional. Incluya los pasos siguientes:
   + En **Orígenes**, seleccione **Crear origen**.
   + En **Dominio de origen**, seleccione su recurso de orígenes de la VPC en el menú desplegable.

     Si el origen la VPC es una instancia de EC2, copie y pegue el **nombre DNS de IP privada** de la instancia en el campo **Dominio de origen**.
   + Elija **Crear origen**.

1. En la distribución provisional, pruebe el origen de la VPC.

1. Promueva la configuración de la distribución provisional a su distribución principal. Para obtener más información, consulte [Promoción de una configuración de distribución provisional](working-with-staging-distribution-continuous-deployment-policy.md#promote-staging-distribution-configuration).

1. Elimine el acceso público al origen de la VPC haciendo la subred privada. Una vez hecho esto, el origen de la VPC no se podrá detectar en Internet, pero CloudFront seguirá teniendo acceso privado a él. Para obtener más información, consulte [Asociación o desvinculación de una subred y una tabla de enrutamiento](https://docs.aws.amazon.com/vpc/latest/userguide/WorkWithRouteTables.html#AssociateSubnet) en la *Guía del usuario de Amazon VPC*.

## Actualización de un origen de la VPC
<a name="update-vpc-origin"></a>

El siguiente procedimiento muestra cómo actualizar un origen de la VPC para la distribución de CloudFront en la consola de CloudFront. También puede usar las operaciones de la API [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) y [UpdateVpcOrigin](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateVpcOrigin.html) con la AWS CLI o un SDK de AWS.

**Para actualizar un origen de la VPC de una distribución existente de CloudFront**

1. Abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. En el panel de navegación, elija **Distribuciones**.

1. Elija el ID de su distribución.

1. Elija la pestaña **Comportamientos**.

1. Asegúrese de que el origen de la VPC no sea el origen predeterminado del comportamiento de la caché. 

1. Elija la pestaña **Orígenes**.

1. Seleccione el origen de la VPC que va a actualizar y elija **Eliminar**. Esto desvincula el origen de la VPC de la distribución. Repita los pasos 2 a 7 para desvincular el origen de la VPC de cualquier otra distribución.

1. Elija **Orígenes de la VPC**.

1. Seleccione el origen de la VPC y elija **Editar**.

1. Realice las actualizaciones y elija **Actualizar origen de la VPC**.

1. Espere a que el estado del origen de la VPC cambie a **Implementado**. Este proceso puede tardar hasta 15 minutos.

1. En el panel de navegación, elija **Distribuciones**.

1. Elija el ID de su distribución.

1. Elija la pestaña **Orígenes**.

1. Elija **Crear origen**.

1. En **Dominio de origen**, seleccione su recurso de orígenes de la VPC en el menú desplegable.

   Si el origen la VPC es una instancia de EC2, copie y pegue el **nombre DNS de IP privada** de la instancia en el campo **Dominio de origen**.

1. Elija **Crear origen**. Esto vuelve a asociar el origen de la VPC a su distribución. Repita los pasos 12 a 17 para asociar el origen de la VPC actualizada a cualquier otra distribución.

## Regiones de AWS admitidas para Orígenes de la VPC
<a name="vpc-origins-supported-regions"></a>

Actualmente, los orígenes de la VPC se admiten en las siguientes Regiones de AWS comerciales. Se indican las excepciones a la zona de disponibilidad (AZ).

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonCloudFront/latest/DeveloperGuide/private-content-vpc-origins.html)

# Restricción del acceso a Application Load Balancer
<a name="restrict-access-to-load-balancer"></a>

Puede utilizar equilibradores de carga de aplicaciones internos y orientados a Internet con Amazon CloudFront. Puede usar equilibradores de carga de aplicaciones internos dentro de subredes privadas con CloudFront mediante orígenes de la VPC. Los orígenes de VPC de CloudFront le permiten ofrecer contenido de aplicaciones alojadas en subredes de VPC privadas sin exponerlas a Internet pública. Para obtener más información, consulte [Restricción del acceso con orígenes de la VPC](private-content-vpc-origins.md).

Si utiliza un equilibrador de carga de aplicaciones orientado a Internet con CloudFront, puede usar las siguientes mitigaciones de seguridad para evitar que los usuarios accedan directamente a un equilibrador de carga de aplicaciones y permitir el acceso solo a través de CloudFront.

1. Configure CloudFront para agregar un encabezado HTTP personalizado a las solicitudes que envía al balanceador de carga de aplicaciones.

1. Configure el balanceador de carga de aplicaciones para que solo reenvíe solicitudes que contengan el encabezado HTTP personalizado.

1. Requiera HTTPS para mejorar la seguridad de esta solución.

CloudFront también puede ayudar a reducir la latencia e incluso absorber algunos ataques de denegación de servicio distribuido (DDoS).

Si el caso de uso requiere un acceso dual a las aplicaciones web desde CloudFront y el equilibrador de carga de aplicaciones directamente a través de Internet, considere dividir las API de la aplicación web de la siguiente manera:
+ API que deben pasar a través de CloudFront. En este caso, considere la posibilidad de utilizar un equilibrador de carga de aplicaciones privado independiente como origen.
+ API que requieren acceso a través del equilibrador de carga de aplicaciones. En este caso, se omite CloudFront.

Para una aplicación web u otro contenido que proporciona un equilibrador de carga de aplicación expuesto a Internet en Elastic Load Balancing, CloudFront puede almacenar en caché objetos y proporcionárselos directamente a los usuarios (espectadores), lo que reduce la carga en el equilibrador de carga de aplicación. Un equilibrador de carga expuesto a Internet tiene un nombre de DNS que se puede resolver públicamente y direcciona las solicitudes de los clientes a través de Internet hasta los destinos.

Para obtener más información, consulte los siguientes temas. Después de completar estos pasos, los usuarios solo pueden acceder a su balanceador de carga de aplicaciones a través de CloudFront.

**Topics**
+ [Configuración de CloudFront para agregar un encabezado HTTP personalizado a solicitudes](#restrict-alb-add-custom-header)
+ [Configuración de un equilibrador de carga de aplicaciones para que solo reenvíe solicitudes que contengan un encabezado específico](#restrict-alb-route-based-on-header)
+ [(Opcional) Mejore la seguridad de esta solución](#restrict-alb-improve-security)
+ [(Opcional) Limitación del acceso al origen mediante la lista de prefijos administrados por AWS para CloudFront](#limit-access-to-origin-using-aws-managed-prefixes)

## Configuración de CloudFront para agregar un encabezado HTTP personalizado a solicitudes
<a name="restrict-alb-add-custom-header"></a>

Puede configurar CloudFront para agregar un encabezado HTTP personalizado a las solicitudes que envía a su origen (en este caso, un balanceador de carga de aplicaciones).

**importante**  
Este caso de uso se basa en mantener el nombre del encabezado personalizado y el valor en secreto. Si el nombre y el valor del encabezado no son secretos, otros clientes HTTP podrían incluirlos en las solicitudes que envían directamente al balanceador de carga de aplicaciones. Esto puede hacer que el balanceador de carga de aplicaciones se comporte como si las solicitudes vinieran de CloudFront cuando no lo hacen. Para evitar esto, mantenga el nombre del encabezado personalizado y el valor en secreto.

Puede configurar CloudFront para agregar un encabezado HTTP personalizado a las solicitudes de origen con la consola de CloudFront, CloudFormation o la API de CloudFront.

**Para agregar un encabezado HTTP personalizado (consola de CloudFront)**  
En la consola de CloudFront, utilice la configuración **Origin Custom Headers** (Encabezados personalizados de origen) **Origin Settings** (Configuración de origen). Introduzca el **Nombre del encabezado** y el **Valor**.  
En producción, use nombres de encabezado y valores generados aleatoriamente. Trate los nombres y valores de los encabezados como credenciales seguras, como nombres de usuario y contraseñas.
Puede editar la configuración **Origin Custom Headers** (Encabezados personalizados de origen) cuando crea o edita un origen para una distribución existente de CloudFront y crea una distribución nueva. Para obtener más información, consulte [Actualizar una distribución](HowToUpdateDistribution.md) y [Creación de una distribución](distribution-web-creating-console.md).

**Para agregar un encabezado HTTP personalizado (CloudFormation)**  
En una plantilla de CloudFormation, utilice la propiedad `OriginCustomHeaders`, como se muestra en el siguiente ejemplo.  
El nombre del encabezado y el valor de este ejemplo son solo para demostración. En producción, use valores generados aleatoriamente. Trate el nombre y el valor del encabezado como una credencial segura, como un nombre de usuario y una contraseña.

```
AWSTemplateFormatVersion: '2010-09-09'
Resources:
  TestDistribution:
    Type: 'AWS::CloudFront::Distribution'
    Properties:
      DistributionConfig:
        Origins:
          - DomainName: app-load-balancer.example.com
            Id: Example-ALB
            CustomOriginConfig:
              OriginProtocolPolicy: https-only
              OriginSSLProtocols:
                - TLSv1.2
            OriginCustomHeaders:
               - HeaderName: X-Custom-Header
                 HeaderValue: random-value-1234567890
        Enabled: 'true'
        DefaultCacheBehavior:
          TargetOriginId: Example-ALB
          ViewerProtocolPolicy: allow-all
          CachePolicyId: 658327ea-f89d-4fab-a63d-7e88639e58f6
        PriceClass: PriceClass_All
        ViewerCertificate:
          CloudFrontDefaultCertificate: 'true'
```
Para obtener más información, consulte las propiedades [Origen](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-origin.html) y [OriginCustomHeader](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-origincustomheader.html) en la *Guía del usuario de AWS CloudFormation*.

**Para agregar un encabezado HTTP personalizado (API de CloudFront)**  
En la API de CloudFront, utilice el `CustomHeaders` objeto interior `Origin`. Para obtener más información, consulte [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html) and [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) en la *Referencia de la API de Amazon CloudFront* y la documentación del SDK u otro cliente de API.

Hay algunos nombres de encabezados que no se pueden especificar como encabezados personalizados de origen. Para obtener más información, consulte [Encabezados personalizados que CloudFront no puede agregar a solicitudes de origen](add-origin-custom-headers.md#add-origin-custom-headers-denylist).

## Configuración de un equilibrador de carga de aplicaciones para que solo reenvíe solicitudes que contengan un encabezado específico
<a name="restrict-alb-route-based-on-header"></a>

Después de configurar CloudFront para agregar un encabezado HTTP personalizado a las solicitudes que envía al balanceador de carga de aplicaciones (consulte [la sección anterior](#restrict-alb-add-custom-header)), puede configurar el balanceador de carga para que solo reenvíe solicitudes que contengan este encabezado personalizado. Para ello, agregue una nueva regla y modifique la regla predeterminada en el agente de escucha del balanceador de carga.

**Requisitos previos**  
Para utilizar los siguientes procedimientos, necesita un balanceador de carga de aplicaciones con al menos un agente de escucha. Si aún no ha creado uno, consulte [Crear un balanceador de carga de aplicaciones](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html) en la *Guía del usuario de balanceadores de carga de aplicaciones*.

Los siguientes procedimientos modifican un agente de escucha HTTPS. Puede utilizar el mismo proceso para modificar un agente de escucha HTTP.

**Para actualizar las reglas en un agente de escucha del balanceador de carga de aplicaciones**

1. Agregue una nueva regla. Siga las instrucciones de [Agregar una regla](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-update-rules.html#add-rule), con las siguientes modificaciones:
   + Agregue la regla al equilibrador de carga que es el origen de la distribución de CloudFront.
   + Para **Agregar condición**, elija **Encabezado Http**. Especifique el nombre del encabezado HTTP y el valor que agregó como encabezado personalizado de origen en CloudFront.
   + Para **Agregar acción**, elija **Reenviar a**. Elija el grupo de destino al que desea reenviar las solicitudes.

1. Edite la regla predeterminada en el oyente del equilibrador de carga. Siga las instrucciones de [Editar una regla](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-update-rules.html#edit-rule), con las siguientes modificaciones:
   + Edite la regla predeterminada del equilibrador de carga que es el origen de la distribución de CloudFront.
   + Elimine la acción predeterminada y, a continuación, en **Agregar acción**, elija **Devolver respuesta fija**. 
   + En **Response code** (Código de respuesta), escriba **403**.
   + En **Response body** (Cuerpo de respuesta), escriba **Access denied**.

Después de completar estos pasos, el oyente del equilibrador de carga tiene dos reglas. Una regla reenvía las solicitudes que contienen el encabezado HTTP (solicitudes que provienen de CloudFront). La otra regla envía una respuesta fija a todas las demás solicitudes (solicitudes que no provienen de CloudFront).

Puede verificar que la solución funcione si envía una solicitud a su distribución de CloudFront y una a su balanceador de carga de aplicaciones. La solicitud a CloudFront devuelve su aplicación web o contenido y la que se envía directamente al balanceador de carga de aplicaciones devuelve una respuesta `403` con el mensaje de texto sin formato `Access denied`.

## (Opcional) Mejore la seguridad de esta solución
<a name="restrict-alb-improve-security"></a>

Para mejorar la seguridad de esta solución, puede configurar su distribución de CloudFront para que utilice siempre HTTPS cuando envíe solicitudes a su balanceador de carga de aplicaciones. Recuerde, esta solución solo funciona si mantiene el nombre del encabezado personalizado y el valor en secreto. El uso de HTTPS puede ayudar a evitar que un espía descubra el nombre y el valor del encabezado. También recomendamos cambiar periódicamente el nombre y el valor del encabezado.

**Usar HTTPS para solicitudes de origen**  
Para configurar CloudFront a fin de que utilice HTTPS para solicitudes de origen, establezca la configuración **Origin Protocol Policy** (Política de protocolo de origen) en **HTTPS Only** (Solo HTTPS). Esta configuración está disponible en la consola de CloudFront, CloudFormation y la API de CloudFront. Para obtener más información, consulte [Protocolo (solo orígenes personalizados)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy).

Lo siguiente también se aplica al configurar CloudFront con el fin de que utilice HTTPS para solicitudes de origen:
+ Debe configurar CloudFront para que reenvíe el encabezado `Host` al origen con la política de solicitud de origen. Puede utilizar la [política de solicitud de origen administrada por AllViewer](using-managed-origin-request-policies.md#managed-origin-request-policy-all-viewer).
+ Asegúrese de que el Equilibrador de carga de aplicación dispone de un oyente HTTPS (como se muestra en [la sección anterior](#restrict-alb-route-based-on-header)). Para obtener más información, consulte [Crear un agente de escucha HTTPS](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html) en la *Guía del usuario de balanceadores de carga de aplicaciones*. Utilizar un oyente HTTPS requiere disponer de un certificado SSL/TLS que coincida con el nombre de dominio enrutado al Equilibrador de carga de aplicación.
+ Los certificados SSL/TLS para CloudFront solo se pueden solicitar (o importar) en la Región de AWS de `us-east-1` en AWS Certificate Manager (ACM). Como CloudFront es un servicio global, distribuye automáticamente el certificado de la región de `us-east-1` a todas las regiones asociadas a la distribución de CloudFront.
  + Por ejemplo, si tiene un Equilibrador de carga de aplicación (ALB) en la región de `ap-southeast-2`, debe configurar certificados SSL/TLS tanto en la región de `ap-southeast-2` (para utilizar HTTPS entre CloudFront y el origen de ALB) como en la región de `us-east-1` (para utilizar HTTPS entre los lectores y CloudFront). Ambos certificados deben coincidir con el nombre de dominio que se enruta al Equilibrador de carga de aplicación. Para obtener más información, consulte [Región de AWS para AWS Certificate Manager](cnames-and-https-requirements.md#https-requirements-aws-region).
+ Si los usuarios finales (también conocidos como *lectores*o *clientes*) de su aplicación web pueden usar HTTPS, también puede configurar CloudFront para que prefiera (o incluso requiera) conexiones HTTPS de los usuarios finales. Para ello, utilice la configuración **Viewer Protocol Policy** (Política de protocolo del lector). Puede configurarla para redirigir a los usuarios finales de HTTP a HTTPS o rechazar las solicitudes que utilizan HTTP. Esta configuración está disponible en la consola de CloudFront, CloudFormation y la API de CloudFront. Para obtener más información, consulte [Política de protocolo para lectores](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy).

**Cambiar el nombre y el valor del encabezado**  
Además de usar HTTPS, también recomendamos cambiar el nombre y el valor del encabezado periódicamente. Los pasos de alto nivel para hacerlo son los siguientes:

1. Configure CloudFront para agregar un encabezado HTTP personalizado adicional a las solicitudes que envía al balanceador de carga de aplicaciones.

1. Actualice la regla del agente de escucha del balanceador de carga de aplicaciones para reenviar solicitudes que contengan este encabezado HTTP personalizado adicional.

1. Configure CloudFront para dejar de agregar el encabezado HTTP personalizado original a las solicitudes que envía al balanceador de carga de aplicaciones.

1. Actualice la regla del agente de escucha del balanceador de carga de aplicaciones para detener el reenvío de solicitudes que contengan el encabezado HTTP personalizado original.

Para obtener más información sobre cómo realizar estos pasos, consulte las secciones anteriores.

## (Opcional) Limitación del acceso al origen mediante la lista de prefijos administrados por AWS para CloudFront
<a name="limit-access-to-origin-using-aws-managed-prefixes"></a>

Para restringir aún más el acceso al Equilibrador de carga de aplicación, puede configurar el grupo de seguridad asociado a él para que solo acepte tráfico de CloudFront cuando el servicio utilice una lista de prefijos administrados por AWS. Esto evita que el tráfico que no se origina en CloudFront llegue al Equilibrador de carga de aplicación en la capa de red (capa 3) o en la capa de transporte (capa 4).

Para obtener más información, consulte la entrada de blog [Limit access to your origins using the AWS-managed prefix list for Amazon CloudFront](https://aws.amazon.com//blogs/networking-and-content-delivery/limit-access-to-your-origins-using-the-aws-managed-prefix-list-for-amazon-cloudfront/).

# Restricción de la distribución geográfica de su contenido
<a name="georestrictions"></a>

Puede utilizar *restricciones geográficas*, a veces conocidas como *bloqueo geográfico*, para evitar que los usuarios de ubicaciones geográficas específicas accedan al contenido que distribuye a través de una distribución de Amazon CloudFront. Para utilizar las restricciones geográficas, tiene dos opciones:
+ Use la característica de restricciones geográficas de CloudFront. Utilice esta opción para restringir el acceso a todos los archivos asociados a una distribución y según el país.
+ Utilice un servicio de geolocalización de terceros. Utilice esta opción para restringir el acceso a un subconjunto de los archivos asociados a una distribución o para restringirlo a un nivel más detallado que por país.

**Topics**
+ [Uso de restricciones geográficas de CloudFront](#georestrictions-cloudfront)
+ [Uso de un servicio de geolocalización de terceros](#georestrictions-geolocation-service)

## Uso de restricciones geográficas de CloudFront
<a name="georestrictions-cloudfront"></a>

Cuando un usuario solicita el contenido, CloudFront normalmente lo ofrece independientemente de dónde se encuentra el usuario. Si necesita impedir que usuarios de países específicos accedan al contenido, puede usar la característica de restricciones geográficas de CloudFront para realizar una de las siguientes acciones:
+ Conceda permiso a sus usuarios para que accedan a su contenido solo si se encuentran en uno de los países aprobados en la lista de permitidos.
+ Evite que los usuarios accedan al contenido si se encuentran en uno de los países prohibidos de la lista de denegación.

Por ejemplo, si una solicitud proviene de un país donde no tiene autorización para distribuir su contenido, puede utilizar las restricciones geográficas de CloudFront para bloquear la solicitud.

**nota**  
CloudFront determina la ubicación de los usuarios mediante una base de datos de terceros. La precisión del mapeo entre direcciones IP y países varía en función de la región. Según pruebas recientes, la precisión global es del 99,8 %. Si CloudFront no puede determinar la ubicación de un usuario, CloudFront ofrece el contenido que el usuario ha solicitado.

Así es como funcionan las restricciones geográficas:

1. Supongamos que tiene derechos para distribuir su contenido únicamente en Liechtenstein. Se actualiza la distribución de CloudFront para agregar una lista de permitidos que contiene solo Liechtenstein. (También puede agregar una lista de denegación que contenga todos los países excepto Liechtenstein).

1. Un usuario en Mónaco solicita el contenido y DNS dirige la solicitud a una ubicación periférica de CloudFront en Milán, Italia.

1. La ubicación periférica en Milán revisa su distribución y determina que el usuario en Mónaco no tiene permiso para descargar su contenido.

1. CloudFront devuelve un código de estado HTTP `403 (Forbidden)` al usuario.

Si lo desea, puede configurar CloudFront para devolver un mensaje de error personalizado al usuario y puede especificar el tiempo durante el cual desea que CloudFront almacene en caché la respuesta de error del archivo solicitado. El valor de predeterminado es de 10 segundos. Para obtener más información, consulte [Creación de una página de error personalizada para códigos de estado HTTP específicos](creating-custom-error-pages.md).

Las restricciones geográficas se aplican a la totalidad de la distribución. Si necesita aplicar una restricción a parte del contenido y una restricción diferente (o ningún tipo de restricción) a otra parte del contenido, debe crear distribuciones de CloudFront independientes o [utilizar un servicio de geolocalización de terceros](#georestrictions-geolocation-service).

Si habilita los [registros estándar](AccessLogs.md) (registros de acceso) de CloudFront, puede identificar las solicitudes que CloudFront rechazó al buscar las entradas de registro cuyo valor de `sc-status` (el código de estado HTTP) sea `403`. Sin embargo, si solo utiliza los registros estándar, no puede distinguir entre una solicitud que CloudFront rechazó en función de la ubicación del usuario y las que CloudFront rechazó porque el usuario no tenía permiso de acceso al archivo debido a otro motivo. Si tiene un servicio de geolocalización de terceros como Digital Element o MaxMind, puede identificar la ubicación de las solicitudes en función de la dirección IP en la columna `c-ip` (IP del cliente) de los registros de acceso. Para obtener más información sobre los registros estándar de CloudFront, consulte [Registros de acceso (registros estándar)](AccessLogs.md).

En el siguiente procedimiento se explica cómo utilizar la consola de CloudFront para agregar restricciones geográficas a una distribución existente. Para obtener más información acerca de cómo crear una distribución, consulte [Creación de una distribución](distribution-web-creating-console.md).<a name="restrictions-geo-procedure"></a>

**Para agregar restricciones geográficas a la distribución web (consola) de CloudFront**

1. Inicie sesión en la Consola de administración de AWS y abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. En el panel de navegación, elija **Distribuciones** y, a continuación, elija la distribución que desea actualizar.

1. Elija la pestaña **Seguridad** y, a continuación, **Restricciones geográficas**.

1. Elija **Edit (Edición de)**.

1. Seleccione **Allow list** (Lista de permitidos) para crear una lista de países permitidos o **Block list** (Lista de bloqueados) para crear una lista de países bloqueados.

1. Agregue los países deseados a la lista y, a continuación, elija **Save changes** (Guardar cambios).

## Uso de un servicio de geolocalización de terceros
<a name="georestrictions-geolocation-service"></a>

La característica de restricciones geográficas de CloudFront le permite controlar la distribución de su contenido en el nivel de país para todos los archivos que esté distribuyendo con una determinada distribución web. Si tiene un caso de uso de restricciones geográficas en el que las restricciones no se ajustan a los límites del país o si quiere restringir el acceso solo a algunos de los archivos que está sirviendo por una distribución determinada, puede combinar CloudFront con un servicio de geolocalización de terceros. Esto le proporciona control sobre su contenido en función no solo del país, sino también de la ciudad, código postal o incluso la latitud y la longitud.

Cuando utiliza un servicio de geolocalización de terceros, le recomendamos utilizar direcciones URL firmadas de CloudFront, que le permiten especificar una fecha y hora de vencimiento a partir de la cual la URL deja de ser válida. Además, le recomendamos utilizar un bucket de Amazon S3 como origen porque eso le permite utilizar un [control de acceso de origen](private-content-restricting-access-to-s3.md) de CloudFront para evitar que los usuarios obtengan acceso al contenido directamente desde el origen. Para obtener más información acerca de las URL firmadas y controles de acceso de origen, consulte [Distribución de contenido privado con URL firmadas y cookies firmadas](PrivateContent.md).

Los siguientes pasos explican cómo controlar el acceso a sus archivos mediante un servicio de geolocalización de terceros.

**Para utilizar un servicio de geolocalización de terceros para restringir el acceso a los archivos de una distribución de CloudFront**

1. Obtenga una cuenta con un servicio de geolocalización.

1. Cargue su contenido a un bucket de Amazon S3.

1. Configure Amazon CloudFront y Amazon S3 para que sirvan contenido privado. Para obtener más información, consulte [Distribución de contenido privado con URL firmadas y cookies firmadas](PrivateContent.md).

1. Escriba su aplicación web para que haga lo siguiente:
   + Enviar la dirección IP de cada solicitud de usuario al servicio de geolocalización.
   + Evalúe el valor de devolución del servicio de geolocalización para determinar si el usuario se encuentra en una ubicación donde desea que CloudFront distribuya el contenido.
   + Si desea distribuir el contenido a la ubicación del usuario, genere una URL firmada para el contenido de CloudFront. Si no desea distribuir contenido a esa ubicación, devuelva el código de estado HTTP `403 (Forbidden)` al usuario. Otra opción es configurar CloudFront para que devuelva un mensaje de error personalizado. Para obtener más información, consulte [Creación de una página de error personalizada para códigos de estado HTTP específicos](creating-custom-error-pages.md).

   Para obtener más información, consulte la documentación del servicio de geolocalización que está utilizando.

Puede utilizar una variable de servidor web para obtener las direcciones IP de los usuarios que visitan su sitio web. Sin embargo, tenga en cuenta lo siguiente:
+ Si su servidor web no está conectado a Internet a través de un equilibrador de carga, puede utilizar una variable de servidor web para obtener la dirección IP remota. Sin embargo, esta dirección IP no siempre es la del usuario. También puede ser la dirección IP de un servidor proxy, dependiendo de cómo esté el usuario conectado a Internet.
+ Si su servidor web está conectado a Internet a través de un balanceador de carga, una variable de servidor web podría contener la dirección IP del balanceador de carga en lugar de la dirección IP del usuario. En esta configuración, le recomendamos utilizar la última dirección IP del encabezado HTTP `X-Forwarded-For`. Este encabezado normalmente contiene más de una dirección IP, la mayoría de los cuales son de proxis o balanceadores de carga. La última dirección IP de la lista tiene más posibilidades de asociarse a la ubicación geográfica del usuario.

Si su servidor web no está conectado a un equilibrador de carga, le recomendamos que utilice variables de servidor web en lugar del encabezado `X-Forwarded-For` para evitar la suplantación de direcciones IP.

# Uso del cifrado en el nivel de campo para ayudar a proteger la información confidencial
<a name="field-level-encryption"></a>

Con Amazon CloudFront, puede aplicar conexiones integrales seguras a los servidores de origen mediante HTTPS. El cifrado en el nivel de campo añade una capa de seguridad adicional que le permite proteger datos específicos durante su procesamiento en el sistema de forma que solo determinadas aplicaciones puedan verlos.

El cifrado en el nivel de campo le permite facilitar a sus usuarios que carguen de manera segura información sensible a los servidores web. La información confidencial proporcionada por los usuarios se cifra en el borde, cerca del usuario y permanece cifrada en toda la pila de la aplicación. Este cifrado garantiza que solo las aplicaciones que necesitan los datos y que tienen las credenciales para descifrarlos puedan hacerlo.

Para utilizar cifrado en el nivel de campo, cuando configure la distribución de CloudFront, especifique el conjunto de campos de las solicitudes POST que desea cifrar y la clave pública que se va a usar para cifrarlos. Puede cifrar hasta 10 campos de datos en cada solicitud. (No puede cifrar todos los datos de una solicitud mediante el cifrado en el nivel de campo, debe especificar campos individuales).

Cuando la solicitud HTTPS con el cifrado en el nivel de campo se reenvía al origen y se transfiere por toda la aplicación o subsistema de origen, la información confidencial sigue estando cifrada, lo que reduce el riesgo de una infracción de los datos o una pérdida accidental de la información confidencial. Los componentes que necesitan obtener acceso a la información confidencial por motivos empresariales, como un sistema de procesamiento de pagos que necesita tener acceso a un número de tarjeta de crédito, pueden utilizar la clave privada apropiada para descifrar los datos y obtener acceso a ellos.

**nota**  
Para utilizar el cifrado en el nivel de campo, el origen debe admitir la codificación fragmentada.

![\[Cifrado en nivel de campo en CloudFront\]](http://docs.aws.amazon.com/es_es/AmazonCloudFront/latest/DeveloperGuide/images/fleoverview.png)


El cifrado en el nivel de campo de CloudFront utiliza cifrado asimétrico, también denominado cifrado de clave pública. Se proporciona una clave pública a CloudFront y toda la información confidencial especificada se cifra automáticamente. La clave proporcionada a CloudFront no se puede utilizar para descifrar los valores cifrados; esto solo puede hacerlo la clave privada.

![\[Cifrar únicamente la información confidencial\]](http://docs.aws.amazon.com/es_es/AmazonCloudFront/latest/DeveloperGuide/images/encryptedfields.png)


**Topics**
+ [Información general del cifrado en el nivel de campo](#field-level-encryption-overview)
+ [Configuración del cifrado en el nivel de campo](#field-level-encryption-setting-up)
+ [Descifrado de campos de datos en el origen](#field-level-encryption-decrypt)

## Información general del cifrado en el nivel de campo
<a name="field-level-encryption-overview"></a>

Los siguientes pasos proporcionan información general sobre la configuración del cifrado en el nivel de campo. Para conocer los pasos específicos, consulte [Configuración del cifrado en el nivel de campo](#field-level-encryption-setting-up).

1. **Obtener un par clave pública-clave privada.** Debe obtener y agregar la clave pública antes de empezar a configurar el cifrado en el nivel de campo en CloudFront.

1. **Crear un perfil de cifrado en el nivel de campo.** Los perfiles de cifrado en el nivel de campo que se crean en CloudFront, definen los campos que se deben cifrar.

1. **Crear una configuración de cifrado en el nivel de campo.** Una configuración especifica los perfiles que se van a utilizar en función del tipo de contenido de la solicitud o de un argumento de consulta para cifrar campos de datos específicos. También puede elegir las opciones de comportamiento de reenvío de solicitudes que desee para diferentes escenarios. Por ejemplo: puede establecer el comportamiento para cuando el nombre del perfil especificado por el argumento de consulta en una URL de solicitud no exista en CloudFront.

1. **Enlazar a un comportamiento de la caché.** Enlace la configuración a un comportamiento de la caché de una distribución para especificar cuándo CloudFront debería cifrar los datos.

## Configuración del cifrado en el nivel de campo
<a name="field-level-encryption-setting-up"></a>

Siga estos pasos para empezar a utilizar el cifrado en el nivel de campo. Para obtener información sobre las cuotas (antes denominadas límites) en el cifrado en el nivel de campo, consulte [Cuotas](cloudfront-limits.md).
+ [Paso 1: Crear un par de claves RSA](#field-level-encryption-setting-up-step1)
+ [Paso 2: Agregar la clave pública a CloudFront](#field-level-encryption-setting-up-step2)
+ [Paso 3: Crear un perfil para el cifrado en el nivel de campo](#field-level-encryption-setting-up-step3)
+ [Paso 4: Crear una configuración](#field-level-encryption-setting-up-step4)
+ [Paso 5: Agregar una configuración a un comportamiento de la caché](#field-level-encryption-setting-up-step5)

### Paso 1: Crear un par de claves RSA
<a name="field-level-encryption-setting-up-step1"></a>

Para comenzar, debe crear un par de claves RSA que incluya una clave pública y una clave privada. La clave pública permite a CloudFront cifrar datos y la clave privada permite que los componentes del origen descifren los campos que se han cifrado. Puede utilizar OpenSSL u otra herramienta para crear un par de claves. El tamaño de la clave debe ser de 2 048 bits.

Por ejemplo, si utiliza OpenSSL, puede ejecutar el siguiente comando para generar un par de claves con una longitud de 2048 bits y guardarlo en el archivo `private_key.pem`:

```
openssl genrsa -out private_key.pem 2048
```

El archivo resultante contiene tanto la clave pública como la privada. Para extraer la clave pública de dicho archivo, ejecute el siguiente comando:

```
openssl rsa -pubout -in private_key.pem -out public_key.pem
```

El archivo de clave pública (`public_key.pem`) contiene el valor de clave cifrada que se pega en el paso siguiente.

### Paso 2: Agregar la clave pública a CloudFront
<a name="field-level-encryption-setting-up-step2"></a>

Después de obtener el par de claves RSA, agregue la clave pública a CloudFront.<a name="field-level-encryption-setting-up-step2-procedure"></a>

**Para agregar la clave pública a CloudFront (consola)**

1. Inicie sesión en Consola de administración de AWS y abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. En el panel de navegación, elija **Clave pública**.

1. Elija **Add public key (Agregar clave pública)**.

1. En **Key name (Nombre de la clave)**, escriba un nombre único para la clave. El nombre no puede tener espacios y solo puede incluir caracteres alfanuméricos, guiones bajos (\$1) y guiones (-). El número máximo de caracteres es 128.

1. En **Key value (valor de clave)**, pegue el valor de clave codificado de la clave pública, incluidas las líneas `-----BEGIN PUBLIC KEY-----` y `-----END PUBLIC KEY-----`.

1. En **Comment (Comentario)**, añada un comentario opcional. Por ejemplo, podría incluir la fecha de vencimiento de la clave pública.

1. Elija **Add (Añadir)**.

Puede agregar más claves para utilizar con CloudFront repitiendo los pasos del procedimiento.

### Paso 3: Crear un perfil para el cifrado en el nivel de campo
<a name="field-level-encryption-setting-up-step3"></a>

Después de añadir al menos una clave pública a CloudFront, cree un perfil que indique a este los campos que desea cifrar.<a name="field-level-encryption-setting-up-step3-procedure"></a>

**Para crear un perfil para el cifrado en el nivel de campo (consola)**

1. En el panel de navegación, elija **Field-level encryption (Cifrado en el nivel de campo)**.

1. Elija **Create profile (Crear perfil)**.

1. Rellene los siguientes campos:  
**Profile name (Nombre de perfil)**  
Escriba un nombre único para el perfil. El nombre no puede tener espacios y solo puede incluir caracteres alfanuméricos, guiones bajos (\$1) y guiones (-). El número máximo de caracteres es 128.  
**Public key name (Nombre de clave pública)**  
En la lista desplegable, elija el nombre de la clave pública que ha agregado a CloudFront en el paso 2. CloudFront utiliza la clave para cifrar los campos especificados en este perfil.  
**Provider name (Nombre de proveedor)**  
Escriba una frase para ayudar a identificar la clave, como el proveedor del que ha obtenido el par de claves. Necesita esta información, junto con la clave privada, cuando las aplicaciones descifran los campos de datos. El nombre del proveedor no puede tener espacios y solo puede incluir caracteres alfanuméricos, dos puntos (:), guiones bajos (\$1) y guiones (-). El número máximo de caracteres es 128.  
**Field name pattern to match (Patrón de coincidencia de nombres de campo)**  
Escriba los nombres de los campos de datos o los patrones que identifican los nombres de los campos de datos de la solicitud que desea que CloudFront cifre. Elija la opción \$1 para añadir todos los campos que desea cifrar con esta clave.  
Para el patrón de nombre de campo, puede escribir el nombre completo del campo de datos, como DateOfBirth, o solo la primera parte del nombre con un carácter comodín (\$1), como CreditCard\$1. El patrón de nombre de campo solo puede incluir caracteres alfanuméricos, corchetes ([ y ]), puntos (.), guiones bajos (\$1) y guiones (-), además del carácter comodín opcional (\$1).  
Asegúrese de que no utiliza caracteres solapados para diferentes patrones de nombre de campo. Por ejemplo, si tiene el patrón de nombre de campo ABC\$1, no puede añadir otro patrón de nombre de campo que sea AB\$1. Además, los nombres de los campos distinguen entre mayúsculas y minúsculas, y que el número máximo de caracteres que puede utilizar es de 128.  
**Comentario**  
(Opcional) Escriba un comentario sobre este perfil. El número máximo de caracteres que puede utilizar es 128.

1. Tras rellenar los campos, elija **Create profile (Crear perfil)**.

1. Si desea añadir más perfiles, elija **Add profile (Añadir perfil)**.

### Paso 4: Crear una configuración
<a name="field-level-encryption-setting-up-step4"></a>

Después de crear uno o varios perfiles de cifrado en el nivel de campo, cree una configuración que especifique el tipo de contenido de la solicitud que incluya los datos que se van a cifrar, el perfil que se va a utilizar para el cifrado y otras opciones que especifiquen cómo desea que CloudFront gestione el cifrado.

Por ejemplo, si CloudFront no puede cifrar los datos, puede especificar si CloudFront debería bloquear o reenviar una solicitud al origen en los siguientes casos:
+ **Cuando el tipo de contenido de una solicitud no está en una configuración**: si no ha agregado un tipo de contenido a una configuración, puede especificar si CloudFront debería reenviar la solicitud con ese tipo de contenido al origen sin cifrar los campos de datos o bloquear la solicitud y devolver un error.
**nota**  
Si agrega un tipo de contenido a una configuración pero no ha especificado el perfil con el que utilizarlo, CloudFront siempre reenvía las solicitudes con ese tipo de contenido al origen.
+ **Cuando se desconoce el nombre de perfil proporcionado en un argumento de consulta**: si especifica el argumento de consulta de `fle-profile` con un nombre de perfil que no existe para la distribución, puede especificar si CloudFront debería enviar la solicitud al origen sin cifrar los campos de datos o bloquear la solicitud y devolver un error.

En una configuración, también puede especificar si al proporcionar un perfil como un argumento de consulta en una URL se anula el perfil que ha mapeado al tipo de contenido de esa consulta. De forma predeterminada, CloudFront utiliza el perfil que ha mapeado a un tipo de contenido, si especifica uno. Esto le permite tener un perfil que se utiliza de forma predeterminada, pero también optar por aplicar un perfil diferente en determinadas solicitudes.

Así, por ejemplo, puede especificar (en la configuración) **SampleProfile** como el perfil de argumento de consulta que se va a utilizar. A continuación, puede utilizar la URL `https://d1234.cloudfront.net?fle-profile=SampleProfile` en lugar de `https://d1234.cloudfront.net`, para que CloudFront utilice **SampleProfile** para esta solicitud y no el perfil que ha configurado para el tipo de contenido de la solicitud.

Puede crear hasta 10 configuraciones para una única cuenta y, a continuación, asociar una de ellas al comportamiento de la caché de cualquier distribución para la cuenta.<a name="field-level-encryption-setting-up-step4-procedure"></a>

**Para crear una configuración para el cifrado en el nivel de campo (consola)**

1. En la página **Field-level encryption (Cifrado en el nivel de campo)**, elija **Create configuration (Crear configuración)**.

   Nota: para poder ver la opción para crear una configuración, debe haber creado al menos un perfil.

1. Rellene los siguientes campos para especificar el perfil que se va a usar. (Algunos campos no se pueden cambiar).  
**Content type (no se puede cambiar)**  
El tipo del contenido está establecido en `application/x-www-form-urlencoded` y no se puede cambiar.  
**Default profile ID (opcional)**  
En la lista desplegable, elija el perfil al que desea mapear al tipo de contenido en el campo **Content type (Tipo de contenido)**.  
**Content format (no se puede cambiar)**  
El formato del contenido está establecido en `URLencoded` y no se puede cambiar.

1. Si desea cambiar el comportamiento predeterminado de CloudFront para las siguientes opciones, seleccione la casilla de verificación correspondiente.  
**Forward request to origin when request’s content type is not configured (Reenviar solicitud al origen cuando el tipo de contenido de la solicitud no está configurado)**  
Seleccione la casilla si desea permitir que la solicitud vaya al origen *si no ha especificado el perfil que se va a utilizar para el tipo de contenido de la solicitud*.  
**Override the profile for a content type with a provided query argument (Invalidar el perfil de un tipo de contenido con un argumento de consulta proporcionado)**  
Seleccione la casilla si desea permitir que un perfil proporcionado en un argumento de consulta *anule el perfil que ha especificado para un tipo de contenido*.

1. Si selecciona la casilla para permitir que un argumento de consulta anule el perfil predeterminado, debe rellenar los siguientes campos adicionales para la configuración. Puede crear hasta cinco de estos mapeos de argumentos de consulta para su uso con las consultas.  
**Query argument (Argumento de consulta)**  
Escriba el valor que desea incluir en las URL para el argumento de consulta `fle-profile`. Este valor indica a CloudFront que debe utilizar el ID de perfil (que especificará en el campo siguiente) asociado con este argumento de consulta para el cifrado en el nivel de campo de esta consulta.  
El número máximo de caracteres que puede utilizar es 128. El valor no puede incluir espacios, y solo se pueden utilizar caracteres alfanuméricos además de los siguientes caracteres: guion (-), punto (.), guion bajo (\$1), asterisco (\$1), signo más (\$1), porcentaje (%).  
**Profile ID (ID de perfil)**  
En la lista desplegable, elija el perfil que desea asociar al valor que ha especificado para **Query argument (Argumento de consulta)**.  
**Forward request to origin when the profile specified in a query argument does not exist (Reenviar solicitud al origen cuando el perfil especificado en una consulta no exista)**  
Seleccione la casilla de verificación si desea permitir que la solicitud vaya al origen *si el perfil especificado en un argumento de consulta no está definido en CloudFront*.

### Paso 5: Agregar una configuración a un comportamiento de la caché
<a name="field-level-encryption-setting-up-step5"></a>

Para utilizar el cifrado en el nivel de campo, enlace una configuración a un comportamiento de la caché de una distribución añadiendo el ID de configuración como un valor de dicha distribución.

**importante**  
Para vincular una configuración de cifrado en el nivel de campo a un comportamiento de la caché, la distribución debe configurarse para que siempre use HTTPS y acepte las solicitudes HTTP `POST` y `PUT` de los espectadores. Es decir, se debe cumplir lo siguiente:  
La **Viewer Protocol Policy (política del protocolo del espectador)** del comportamiento de la caché debe establecerse en **Redirect HTTP to HTTPS (Redireccionamiento de HTTP a HTTPS)** o **HTTPS Only (solo HTTPS)**. (En CloudFormation o en la API de CloudFront, `ViewerProtocolPolicy` debe establecerse en `redirect-to-https` o `https-only`).
Los **métodos HTTP permitidos** del comportamiento de la caché deben establecerse en **GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE**. (En CloudFormation o en la API de CloudFront, `AllowedMethods` se debe configurar en `GET`, `HEAD`, `OPTIONS`, `PUT`, `POST`, `PATCH`, `DELETE`. Estos se pueden especificar en cualquier orden).
La **Origin Protocol Policy (política del protocolo de origen)** de la configuración de origen debe establecerse en **Match Viewer (coincidir con espectador)** o **HTTPS Only (solo HTTPS)**. (En CloudFormation o en la API de CloudFront, `OriginProtocolPolicy` debe establecerse en `match-viewer` o `https-only`).

Para obtener más información, consulte [Referencia de toda la configuración de distribución](distribution-web-values-specify.md).

## Descifrado de campos de datos en el origen
<a name="field-level-encryption-decrypt"></a>

CloudFront cifra los campos de datos mediante [AWS Encryption SDK](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html). Los datos permanecen cifrados en toda la pila de aplicaciones y únicamente pueden tener acceso a ellos las aplicaciones que dispongan de las credenciales para descifrarlos.

Tras el cifrado, el texto cifrado se codifica en base64. Cuando las aplicaciones descifran el texto en el origen, primero deben descodificar el texto cifrado y, a continuación, utilizar el SDK de cifrado de AWS para descifrar los datos.

El siguiente código de ejemplo ilustra cómo las aplicaciones pueden descifrar datos en el origen. Tenga en cuenta lo siguiente: 
+ Para simplificar el ejemplo, esta muestra carga claves públicas y privadas (en formato DER) desde archivos que se encuentran en el directorio de trabajo. En la práctica, debería almacenar la clave privada en una ubicación segura sin conexión, como un módulo de seguridad de hardware sin conexión, y distribuir la clave pública a su equipo de desarrollo.
+ CloudFront utiliza información específica al cifrar los datos y se debería utilizar el mismo conjunto de parámetros en el origen para descifrarlos. Entre los parámetros que CloudFront utiliza al inicializar la clave maestra se incluyen los siguientes:
  + PROVIDER\$1NAME: este valor se especificó al crear un perfil de cifrado en el nivel de campo. Utilice aquí el mismo valor.
  + KEY\$1NAME: el nombre para la clave pública se creó al cargarla en CloudFront y, a continuación, se especificó el nombre de la clave en el perfil. Utilice aquí el mismo valor.
  + ALGORITHM: CloudFront utiliza `RSA/ECB/OAEPWithSHA-256AndMGF1Padding` como algoritmo para cifrar, por lo que debe usar el mismo algoritmo para descifrar los datos.
+ Si ejecuta el siguiente programa de muestra con texto cifrado como entrada, los datos descifrados se muestran en la consola. Para obtener más información, consulte el [código de ejemplo de Java](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/java-example-code.html) del SDK de cifrado de AWS.

### Código de muestra
<a name="field-level-encryption-decrypt-sample"></a>

```
import java.nio.file.Files;
import java.nio.file.Paths;
import java.security.KeyFactory;
import java.security.PrivateKey;
import java.security.PublicKey;
import java.security.spec.PKCS8EncodedKeySpec;
import java.security.spec.X509EncodedKeySpec;

import org.apache.commons.codec.binary.Base64;

import com.amazonaws.encryptionsdk.AwsCrypto;
import com.amazonaws.encryptionsdk.CryptoResult;
import com.amazonaws.encryptionsdk.jce.JceMasterKey;

/**
 * Sample example of decrypting data that has been encrypted by CloudFront field-level encryption.
 */
public class DecryptExample {

    private static final String PRIVATE_KEY_FILENAME = "private_key.der";
    private static final String PUBLIC_KEY_FILENAME = "public_key.der";
    private static PublicKey publicKey;
    private static PrivateKey privateKey;

    // CloudFront uses the following values to encrypt data, and your origin must use same values to decrypt it.
    // In your own code, for PROVIDER_NAME, use the provider name that you specified when you created your field-level
    // encryption profile. This sample uses 'DEMO' for the value.
    private static final String PROVIDER_NAME = "DEMO";
    // In your own code, use the key name that you specified when you added your public key to CloudFront. This sample
    // uses 'DEMOKEY' for the key name.
    private static final String KEY_NAME = "DEMOKEY";
    // CloudFront uses this algorithm when encrypting data.
    private static final String ALGORITHM = "RSA/ECB/OAEPWithSHA-256AndMGF1Padding";

    public static void main(final String[] args) throws Exception {

        final String dataToDecrypt = args[0];

        // This sample uses files to get public and private keys.
        // In practice, you should distribute the public key and save the private key in secure storage.
        populateKeyPair();

        System.out.println(decrypt(debase64(dataToDecrypt)));
    }

    private static String decrypt(final byte[] bytesToDecrypt) throws Exception {
        // You can decrypt the stream only by using the private key.

        // 1. Instantiate the SDK
        final AwsCrypto crypto = new AwsCrypto();

        // 2. Instantiate a JCE master key
        final JceMasterKey masterKey = JceMasterKey.getInstance(
                publicKey,
                privateKey,
                PROVIDER_NAME,
                KEY_NAME,
                ALGORITHM);

        // 3. Decrypt the data
        final CryptoResult <byte[], ? > result = crypto.decryptData(masterKey, bytesToDecrypt);
        return new String(result.getResult());
    }

    // Function to decode base64 cipher text.
    private static byte[] debase64(final String value) {
        return Base64.decodeBase64(value.getBytes());
    }

    private static void populateKeyPair() throws Exception {
        final byte[] PublicKeyBytes = Files.readAllBytes(Paths.get(PUBLIC_KEY_FILENAME));
        final byte[] privateKeyBytes = Files.readAllBytes(Paths.get(PRIVATE_KEY_FILENAME));
        publicKey = KeyFactory.getInstance("RSA").generatePublic(new X509EncodedKeySpec(PublicKeyBytes));
        privateKey = KeyFactory.getInstance("RSA").generatePrivate(new PKCS8EncodedKeySpec(privateKeyBytes));
    }
}
```