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

Última actualización: 08-12-2021

Mi nombre de dominio personalizado de Amazon API Gateway que tiene activada la autenticación de Transport Layer Security (TLS) mutua devuelve errores HTTP 403 Forbidden. ¿Por qué sucede esto y cómo se soluciona?

Descripción corta

Nota: API Gateway puede devolver errores 403 Forbidden por varias razones. Este artículo aborda errores 403 Forbidden relacionados con TLS mutua únicamente. Para obtener información sobre cómo solucionar otros tipos de errores 403 Forbidden, consule ¿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.

Si se produce alguna de las siguientes condiciones, API Gateway no puede establecer la conexión TLS y devuelve 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 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 las 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 tu nombre de dominio personalizado que invoque una API REST solo para pruebas.
Nota: Si no tienes una API REST disponible para llevar a cabo pruebas, use la API REST de PetStore de ejemplo. Luego, implemente la API de ejemplo en una nueva etapa y cree una nueva asignación de API para ella 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.    Si aún no lo ha hecho, active el registro de CloudWatch para su API REST. Asegúrese de configurar el registro de ejecución y acceso.

Nota: 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 Logs cuando el nombre de dominio personalizado que requiere TLS mutua devuelve un error 403 Forbidden.
  • Facilitan la identificación de la persona que llama que intentó invocar su API cuando revisa sus registros de CloudWatch Logs.

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 consultando los registros de ejecución de la API REST en CloudWatch. Si se registra un error 403 Forbidden relacionado con la TLS mutua, aparece un mensaje de error similar al siguiente ejemplo.

Ejemplo de mensaje de error de CloudWatch Logs cuando un nombre de dominio personalizado que requiere TLS mutua devuelve un error 403 Forbidden

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 OK si el emisor del certificado de cliente en la solicitud de la 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. A continuación, 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: API Gateway acepta certificados de cliente firmados directamente por la autoridad de certificación raíz o por cualquier otro intermedio si se conserva su cadena de certificados. 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 aceptando el certificado de cliente como entrada de la solicitud de la 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 o no, 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 pasado 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 fácil, puede canalizar el módulo de salida en una función hash criptográfica. Por ejemplo: 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, verifique que no haya habido ninguna modificación de datos en el contenido ejecutando el comando diff:

$ diff client.crt bundle.crt

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


¿Le resultó útil este artículo?


¿Necesita asistencia técnica o con la facturación?