¿Cómo soluciono los errores HTTP 403 Forbidden (Prohibido) de un nombre de dominio personalizado de API Gateway que requiere una TLS mutua?

9 minutos de lectura
0

Mi nombre de dominio personalizado de Amazon API Gateway que tiene activada la autenticación de seguridad de la capa de transporte (TLS) mutua devuelve errores HTTP 403 Forbidden (Prohibido). No sé por qué sucede esto.

Descripción breve

Nota: API Gateway puede devolver errores 403 Forbidden (Prohibido) por varias razones. Este artículo aborda errores 403 Forbidden (Prohibido) relacionados con TLS mutua únicamente. Para obtener información sobre cómo solucionar otros tipos de errores 403 Forbidden (Prohibido), consulte ¿Cómo soluciono los errores HTTP 403 Forbidden (Prohibido) de API Gateway?

Para invocar una API de API Gateway mediante un nombre de dominio personalizado que requiere la TLS mutua, los clientes deben presentar un certificado de confianza en la solicitud de API. Cuando un cliente intenta invocar la API, API Gateway busca el emisor del certificado de cliente en su almacén de confianza.

Las siguientes condiciones hacen que API Gateway no pueda establecer la conexión TLS y devuelva un código de estado 403:

  • API Gateway can't find the issuer of the client certificate in your truststore (API Gateway no puede encontrar el emisor del certificado de cliente en su almacén de confianza).
  • El certificado de cliente utiliza un algoritmo de firma poco seguro.
  • El certificado de cliente está autofirmado.

Si el registro de Amazon CloudWatch está activado para su API, aparece un mensaje de error que indica la causa del error en los registros de ejecución.

Importante: Si la solicitud de la API no produce ningún registro de CloudWatch Logs después de activar el registro, el error 403 Forbidden no está relacionado con la TLS mutua.

Para las API REST

Si configura el registro de Amazon CloudWatch para su API de REST, también aparece uno de los siguientes mensajes de error en los registros de ejecución:

  • Acceso denegado. Motivo: no se pudo encontrar el emisor del certificado
  • Acceso denegado. Motivo: el certificado de cliente utiliza un algoritmo de firma poco seguro
  • Acceso denegado. Motivo: certificado autofirmado

Para operaciones de API HTTP

Las API HTTP no admiten el registro de ejecución. Para solucionar errores 403 Forbidden devueltos por un nombre de dominio personalizado que requiere TLS mutua e invoca una API HTTP, debe hacer lo siguiente:

1.    Cree una nueva asignación de API para su nombre de dominio personalizado que invoque una API de REST solo para pruebas.
Nota: Si no tiene una API de REST disponible para llevar a cabo las pruebas, use la API de REST de PetStore de ejemplo. Luego, implemente la API de ejemplo en una nueva etapa y cree una nueva asignación de API que use su nombre de dominio personalizado.

2.    Siga las instrucciones de la sección Resolución de este artículo con la nueva asignación de API que creó en su API REST.

3.    Una vez identificado y resuelto el error, vuelva a dirigir la asignación de API de su nombre de dominio personalizado a su API HTTP.

Resolución

Confirmar la causa del error

1.   Active el registro de CloudWatch para su API de REST. Luego, configure el registro de ejecución y acceso.

Al configurar el registro de acceso para este caso de uso, es una práctica recomendada utilizar las siguientes variables $context. Estas variables hacen dos cosas:

  • Le indican a API Gateway que genere registros de CloudWatch cuando el nombre de dominio personalizado que requiere TLS mutua devuelve un error 403 Forbidden (Prohibido).
  • Facilitan la identificación de la persona que llama que intentó invocar su operación de API cuando revisa sus registros de CloudWatch.

Variables $context recomendadas para el registro de acceso de CloudWatch que permitirán a API Gateway generar registros de ejecución y acceso

{ "accountId":"$context.accountId", "apiId":"$context.apiId", "domainName":"$context.domainName", "domainPrefix":"$context.domainPrefix", "error.message":"$context.error.message", "error.responseType":"$context.error.responseType", "extendedRequestId":"$context.extendedRequestId", "httpMethod":"$context.httpMethod", "identity.sourceIp":"$context.identity.sourceIp", "identity.clientCert.clientCertPem":"$context.identity.clientCert.clientCertPem", "identity.clientCert.subjectDN":"$context.identity.clientCert.subjectDN", "identity.clientCert.issuerDN":"$context.identity.clientCert.issuerDN", "identity.clientCert.serialNumber":"$context.identity.clientCert.serialNumber", "identity.clientCert.validity.notBefore":"$context.identity.clientCert.validity.notBefore", "identity.clientCert.validity.notAfter":"$context.identity.clientCert.validity.notAfter", "identity.userAgent":"$context.identity.userAgent", "path":"$context.path", "protocol":"$context.protocol", "requestId":"$context.requestId", "requestTime":"$context.requestTime", "requestTimeEpoch":"$context.requestTimeEpoch", "resourceId":"$context.resourceId", "resourcePath":"$context.resourcePath", "stage":"$context.stage", "responseLatency":"$context.responseLatency", "responseLength":"$context.responseLength", "status":"$context.status" }

2.    Identifique qué está causando los errores 403 Forbidden (Prohibido) al consultar los registros de ejecución de la API de REST en CloudWatch. Si se registra un error 403 Forbidden (Prohibido) relacionado con la TLS mutua, recibe un mensaje de error similar al siguiente:

Ejemplo de mensaje de error de registros de CloudWatch cuando un nombre de dominio personalizado que requiere TLS mutua devuelve un error 403 Forbidden (Prohibido)

Extended Request Id: {extendedRequestId} 
Access denied. Reason: {reason} 
ForbiddenException Forbidden: {requestId}

Para resolver los errores “Access denied. Reason: Could not find issuer for certificate” (Acceso denegado. Motivo: no se pudo encontrar el emisor del certificado)

Compruebe que el emisor del certificado de cliente en la solicitud de la API esté incluido en el almacén de confianza del nombre de dominio personalizado

El emisor del certificado de cliente (client.pem) en la solicitud de la API debe incluirse en el almacén de confianza del nombre de dominio personalizado. El emisor también debe incluirse como parte del paquete de certificados (bundle.pem) en Amazon Simple Storage Service (Amazon S3).

Para comprobar si el emisor del certificado de cliente está incluido en el almacén de confianza requerido, ejecute el siguiente comando de OpenSSL:

$ openssl verify -CAfile bundle.pem client.pem

-o bien-

Si el paquete de certificados contiene autoridades certificadoras intermedias, ejecute el siguiente comando de OpenSSL:

$ openssl verify -CAfile rootCA.pem -untrusted intCA.pem client.pem

El comando devuelve una respuesta de OK (Correcto) si el emisor del certificado de cliente en la solicitud de API se incluye en el almacén de confianza requerido.

El comando devuelve el siguiente error si el emisor del certificado de cliente no está incluido en el almacén de confianza requerido: “error X at Y depth lookup: unable to get local issuer certificate” (error X al buscar en Y: no se puede obtener el certificado del emisor local).

Compruebe que todos los certificados de cliente del almacén de confianza de su nombre de dominio personalizado sean válidos

Si uno de los certificados de cliente del almacén de confianza de su nombre de dominio personalizado no es válido, es posible que algunos clientes no puedan acceder a su API.

Para verificar si todos los certificados de cliente de su almacén de confianza son válidos, haga lo siguiente:

1.    Abra la consola de API Gateway.

2.    En el panel de navegación izquierdo, elija Custom domain names (Nombres de dominio personalizado). Luego, elija su nombre de dominio personalizado que requiera TLS mutua.

3.    En la sección Details (Detalles), compruebe si aparece el siguiente mensaje de error: There is an invalid certificate in your truststore bundle (Hay un certificado no válido en el paquete del almacén de confianza).

4.    Si ve el mensaje de error, debe decodificar los certificados en su almacén de confianza para identificar qué certificado produjo la advertencia.
Nota: El siguiente comando de OpenSSL muestra el contenido de un certificado, incluido su asunto:

$ openssl x509 -in certificate.crt -text -noout

5.    Actualice o elimine los certificados que produjeron la advertencia. Luego, cargue un nuevo almacén de confianza en Amazon S3.

Para obtener más información, consulte Solución de problemas de advertencias de certificados.

Nota: Si se conserva su cadena de certificados, API Gateway acepta certificados de cliente firmados directamente por la autoridad de certificación raíz o por cualquier otra autoridad de certificación intermedia. Para validar los certificados de cliente firmados únicamente por la última autoridad de certificación intermedia, utilice un autorizador de AWS Lambda basado en parámetros de solicitud. Puede utilizar su algoritmo de validación personalizado en la función de Lambda al aceptar el certificado de cliente como entrada de la solicitud de API.

Para resolver los errores “Access denied. Reason: Client cert using an insecure Signature Algorithm” (Acceso denegado. Motivo: el certificado de cliente utiliza un algoritmo de firma poco seguro)

Compruebe que el archivo de texto del almacén de confianza utilice un algoritmo hash compatible

API Gateway admite los siguientes algoritmos hash en el almacén de confianza:

  • SHA-256 o más fuerte
  • RSA-2048 o más fuerte
  • ECDSA-256 o más fuerte

Para comprobar si el archivo de texto del almacén de confianza utiliza un algoritmo hash admitido, ejecute el siguiente comando de OpenSSL:

$ openssl x509 -in client.crt -text -noout | grep 'Signature Algorithm'

La respuesta del comando devuelve el algoritmo de firma de su almacén de confianza.

Para obtener más información, consulte Configuración del almacén de confianza.

Para resolver los errores “Access denied. Reason: self signed certificate” (Acceso denegado. Motivo: certificado autofirmado)

Compruebe que el certificado de cliente autofirmado en la solicitud de la API no se haya alterado ni dañado

Los siguientes elementos deben coincidir exactamente:

  • El módulo de la clave privada (private.key) que se utiliza para firmar el certificado autofirmado en el almacén de confianza en S3 (bundle.crt o bundle.pem).
  • El módulo del certificado del cliente que se pasa en la solicitud de API (client.crt).

Para comparar los dos módulos, ejecute los siguientes comandos de OpenSSL:

$ openssl rsa -noout -modulus -in private.key
$ openssl x509 -noout -modulus -in bundle.crt
$ openssl x509 -noout -modulus -in client.crt

Nota: Si quiere producir un valor hash más corto para una comparación más sencilla, puede canalizar el módulo de salida en una función hash criptográfica. Consulte el siguiente ejemplo de openssl sha1:

$ openssl [operation] -noout -modulus -in [data] | openssl sha1

Ejemplos de resultado de comandos válidos

2143831a73a8bb28467860df18550c696c03fbcb
2143831a73a8bb28467860df18550c696c03fbcb
2143831a73a8bb28467860df18550c696c03fbcb

Para confirmar la integridad de los datos, compruebe que no haya ninguna modificación de datos en el contenido mediante la ejecución del comando diff:

$ diff client.crt bundle.crt

Para obtener más información, consulte Configuración del almacén de confianza.


OFICIAL DE AWS
OFICIAL DE AWSActualizada hace un año