Proteger un endpoint de contenido con HTTPS

Introducción

El endpoint funciona, pero los clientes deben leer el contenido mediante una conexión cifrada que verifique la identidad del servidor. Asocia un certificado ACM preparado con un nombre alternativo de CloudFront, exige HTTPS y prueba la página real, la confianza del certificado y su nombre.

Completa primero el laboratorio de distribución privada de S3. Esta VM independiente proporciona una nueva conexión privada al origen, un certificado importado para content.labex-n04.test y el ancla de confianza pública practice-ca.pem. El certificado todavía no está asociado con la distribución. Observa el estado en AWS View, arriba, y usa Terminal, abajo. No necesitas cuenta personal de AWS ni dominio comprado.

El certificado de práctica está firmado por una autoridad de certificación privada preparada. Confía en su archivo público de CA para un comando individual, sin modificar el almacén de confianza del sistema. Un sitio público de CloudFront necesita un certificado de confianza pública. Aquí practicas la asociación y comprobaciones TLS reales, sin registrar dominios ni emitir certificados públicos.

Objetivos de certificación

Vista general del laboratorio

Asociar el certificado y exigir HTTPS

En este paso, conecta el certificado y el nombre alternativo preparados con la distribución y exige solicitudes cifradas.

TLS cifra una conexión y permite verificar la identidad del servidor. Un certificado contiene nombres y una clave pública, firmados por una autoridad de certificación (CA). ACM, AWS Certificate Manager, administra certificados para servicios AWS. Tener un certificado en ACM no lo conecta automáticamente con una distribución.

Identifica los recursos preparados. $(...) guarda la salida en variables del shell; --query selecciona el recurso y --output text permite usar su ID como argumento. Mantén Terminal abierto:

cd /home/labex/project
HOST_NAME=content.labex-n04.test
DIST_ID=$(aws cloudfront list-distributions \
  --query "DistributionList.Items[?Comment=='labex-n04:private-content'].Id | [0]" \
  --output text)
CERT_ARN=$(aws acm list-certificates \
  --query "CertificateSummaryList[?DomainName=='content.labex-n04.test'].CertificateArn | [0]" \
  --output text)
aws acm describe-certificate \
  --certificate-arn "$CERT_ARN" \
  --query 'Certificate.{Name:DomainName,Names:SubjectAlternativeNames,Status:Status}'

Espera ISSUED y el nombre de práctica en Names. El ARN identifica la cuenta y la región. Los certificados de usuario de CloudFront en ACM deben estar en us-east-1; el ARN preparado usa esa región. El certificado debe cubrir el nombre alternativo asociado.

Lee la configuración actual y su ETag, el token de versión necesario para actualizar. > guarda la salida en un archivo:

aws cloudfront get-distribution-config \
  --id "$DIST_ID" \
  --query DistributionConfig > current-config.json
ETAG=$(aws cloudfront get-distribution-config \
  --id "$DIST_ID" \
  --query ETag \
  --output text)

Un nombre alternativo, o alias, permite reconocer el nombre del contenido. SNI, Server Name Indication, lo envía al establecer TLS para seleccionar el certificado. La política de protocolo del usuario controla HTTP y HTTPS, por separado del permiso de origen S3.

jq modifica JSON conservando los demás ajustes. --arg entrega los valores capturados como cadenas JSON. Los operadores | de la expresión entre comillas aplican tres cambios en orden: alias, certificado personalizado y acceso https-only. La política de seguridad seleccionada exige TLS 1.2 o posterior:

jq --arg host "$HOST_NAME" --arg cert "$CERT_ARN"   '.Aliases = {Quantity: 1, Items: [$host]} |
   .ViewerCertificate = {CloudFrontDefaultCertificate: false,
     ACMCertificateArn: $cert, SSLSupportMethod: "sni-only",
     MinimumProtocolVersion: "TLSv1.2_2021"} |
   .DefaultCacheBehavior.ViewerProtocolPolicy = "https-only"'   current-config.json > https-config.json
aws cloudfront update-distribution \
  --id "$DIST_ID" \
  --if-match "$ETAG" \
  --distribution-config file://https-config.json
aws cloudfront wait distribution-deployed \
  --id "$DIST_ID"

Revisa los ajustes guardados antes de probar la conexión:

aws cloudfront get-distribution-config \
  --id "$DIST_ID" \
  --query 'DistributionConfig.{Names:Aliases.Items,Certificate:ViewerCertificate.ACMCertificateArn,Protocol:DefaultCacheBehavior.ViewerProtocolPolicy}'

Espera el nombre exacto, tu ARN y https-only. AWS View muestra el alias y el certificado ACM asociado. La configuración nativa está lista; el siguiente paso demuestra una solicitud cifrada real. Ejecuta la comprobación de asociación.

Verificar el contenido cifrado y el certificado

En este paso, lee la página mediante HTTPS de confianza, observa el rechazo del acceso sin cifrar y distingue confianza del certificado de coincidencia del nombre.

curl --cacert practice-ca.pem confía en la CA pública preparada solo para este comando. --resolve conecta el nombre y puerto exactos con esta VM manteniendo el nombre para SNI y verificación. No registra un dominio público ni cambia el DNS del sistema. El endpoint HTTPS preparado usa el puerto 8443:

curl --fail --include --noproxy '*' --cacert practice-ca.pem   --resolve "${HOST_NAME}:8443:127.0.0.1"   "https://${HOST_NAME}:8443/index.html"

Espera HTTP 200 y Release one. El cliente estableció TLS real, verificó emisor y nombre, y recibió la página real de S3. Esto demuestra más que un ARN guardado.

Prueba el endpoint de usuario sin cifrar y el origen directo anónimo:

curl --noproxy '*' --output /dev/null   --resolve "${HOST_NAME}:8082:127.0.0.1"   --write-out 'Plaintext viewer: HTTP %{http_code}\n'   "http://${HOST_NAME}:8082/index.html"
curl --noproxy '*' --output /dev/null   --write-out 'Anonymous origin: HTTP %{http_code}\n'   http://127.0.0.1:5000/labex-n04-content/index.html

Ambos deben devolver HTTP 403. Exigir HTTPS al usuario no hace público el bucket S3; son protecciones independientes.

Omite ahora el archivo CA para probar la confianza. Este comando debe fallar deliberadamente:

curl --fail --noproxy '*'   --resolve "${HOST_NAME}:8443:127.0.0.1"   "https://${HOST_NAME}:8443/index.html"

Espera un error de verificación, normalmente el error 60 de curl: el almacén predeterminado no confía en esta CA privada. Continúa tras el fallo previsto. La solicitud correcta eligió el ancla adecuada; desactivar la verificación eliminaría la protección que estás practicando.

openssl s_client separa el nombre para SNI del nombre que se verifica. Envía el SNI correcto y confía en la CA, pero pide verificar un nombre deliberadamente incorrecto. -verify_return_error detiene la verificación al fallar y < /dev/null evita entrada interactiva:

openssl s_client -connect 127.0.0.1:8443   -servername "$HOST_NAME" -CAfile practice-ca.pem   -verify_hostname wrong.labex-n04.test   -verify_return_error < /dev/null

Espera hostname mismatch y una verificación fallida. Confiar en el emisor no basta: el certificado también debe cubrir la identidad solicitada. AWS View conserva la solicitud cifrada real y el rechazo sin cifrar. Ejecuta la comprobación HTTPS.

Eliminar solo tus recursos de distribución

En este paso, desactiva y elimina primero la distribución, después su OAC, el contenido S3 y el certificado preparado. Conserva el bucket de referencia.

CloudFront usa ETag como token de versión. Obtén la configuración y el ETag actuales sin inventarlo. Primero captura el OAC exacto conectado al origen:

OAC_ID=$(aws cloudfront get-distribution-config \
  --id "$DIST_ID" \
  --query 'DistributionConfig.Origins.Items[0].OriginAccessControlId' \
  --output text)

Guarda la configuración y captura su ETag:

aws cloudfront get-distribution-config \
  --id "$DIST_ID" \
  --query DistributionConfig \
  --output json > distribution-current.json
DIST_ETAG=$(aws cloudfront get-distribution-config \
  --id "$DIST_ID" \
  --query ETag \
  --output text)

En la configuración actual, Enabled de la distribución es el único atributo de ese nombre con valor true. La sustitución normal con sed crea una copia desactivada conservando el origen:

sed 's/"Enabled": true/"Enabled": false/' distribution-current.json > distribution-disabled.json
aws cloudfront update-distribution \
  --id "$DIST_ID" \
  --if-match "$DIST_ETAG" \
  --distribution-config file://distribution-disabled.json

Espera el despliegue de la configuración desactivada. La propagación AWS puede tardar; aquí no medimos la latencia mundial:

aws cloudfront wait distribution-deployed \
  --id "$DIST_ID"

Actualizar cambia el ETag. Lee el más reciente antes de eliminar la distribución desactivada:

DIST_ETAG=$(aws cloudfront get-distribution-config \
  --id "$DIST_ID" \
  --query ETag \
  --output text)
aws cloudfront delete-distribution \
  --id "$DIST_ID" \
  --if-match "$DIST_ETAG"

Elimina el OAC con su propio ETag. Los ID de distribución y OAC identifican recursos distintos:

OAC_ETAG=$(aws cloudfront get-origin-access-control \
  --id "$OAC_ID" \
  --query ETag \
  --output text)
aws cloudfront delete-origin-access-control \
  --id "$OAC_ID" \
  --if-match "$OAC_ETAG"

Elimina solo el objeto de contenido y el bucket del laboratorio:

aws s3api delete-object \
  --bucket labex-n04-content \
  --key index.html
aws s3api delete-bucket \
  --bucket labex-n04-content
aws s3api list-buckets \
  --query 'Buckets[].Name'

Tras eliminar la distribución, elimina únicamente el certificado preparado usando el ARN seleccionado antes. Esto elimina el recurso ACM; el archivo CA público puede permanecer como material local independiente:

aws acm delete-certificate \
  --certificate-arn "$CERT_ARN"
aws acm list-certificates \
  --query 'CertificateSummaryList[].CertificateArn'

No debe quedar el certificado del laboratorio. El bucket de referencia debe permanecer y el de contenido debe desaparecer. AWS View debe mostrar ninguna distribución de contenido y solo el objeto de referencia. Ejecuta la comprobación de limpieza. Una solicitud API fallida no prueba una eliminación.

Resumen

Asociaste un certificado ACM y un nombre alternativo con CloudFront, exigiste HTTPS y leíste contenido real mediante TLS verificado. Distinguiste emisor de confianza, nombre coincidente, cifrado del usuario y acceso privado al origen. Las solicitudes sin cifrar fueron rechazadas; las pruebas de emisor no confiable y nombre incorrecto fallaron. Eliminaste solo tus recursos y el certificado del laboratorio, conservando la referencia independiente.