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

Descripción breve

Nota: API Gateway devuelve errores 403 Forbidden por diversos motivos. Este artículo aborda los errores 403 Forbidden relacionados únicamente con el TLS mutuo. Para obtener información sobre cómo solucionar otros tipos de errores 403 Forbidden, consulte ¿Cómo puedo solucionar los errores HTTP 403 desde API Gateway?

Para invocar una API de API Gateway con un nombre de dominio personalizado que requiera un TLS mutuo, los clientes deben presentar un certificado de confianza en la solicitud de API. Cuando un cliente invoca la API, API Gateway busca al emisor del certificado del cliente en su almacén de confianza.
Las siguientes condiciones hacen que API Gateway falle en 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.
• The client certificate uses an insecure signature algorithm.
• The client certificate is self signed.

Si se activa el registro de Amazon CloudWatch 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 API no produce ningún registro de CloudWatch después de activar el registro, el error 403 Forbidden no está relacionado con el TLS mutuo.

En el caso de las API de REST

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

• Access denied. Reason: Could not find issuer for certificate
• Access denied. Reason: Client cert using an insecure Signature Algorithm
• Access denied. Reason: self signed certificate

Para operaciones de API HTTP

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

1. Cree una nueva asignación de API para su nombre de dominio personalizado que invoque una API de REST solo para realizar pruebas.
   Nota: Si no tiene una API de REST con la que realizar pruebas, use la ]( de REST de PetStore de ejemplo[. A continuación, implemente la API de ejemplo en una nueva etapa y cree una nueva asignación de API que utilice 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ó a su API de REST.
3. Redirija la asignación de API para su nombre de dominio personalizado a su API HTTP.

Resolución

Confirmación de la causa del error

1. Active el registro de CloudWatch para su API de REST.
2. Configure el registro de ejecución y acceso.
   Nota: Al configurar el registro de acceso para este caso de uso, se recomienda utilizar las siguientes variables de $context:

   { "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" }

   Estas variables indican a API Gateway que genere CloudWatch Logs cuando su nombre de dominio personalizado que requiere TLS mutuo arroje un error 403. También facilitan la identificación de la persona que llama y que intentó invocar la operación de API.
3. Consulte los registros de ejecución de la API REST en CloudWatch para identificar la causa del error. Si se registra un error 403 Forbidden relacionado con el TLS mutuo, recibirá un mensaje de error similar al siguiente:

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

Resolver errores «Access denied. Reason: Could not find issuer for certificate»

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

El emisor del certificado de cliente (client.pem) de la solicitud de API debe estar incluido 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-

Si el paquete de certificados contiene autoridades de certificación intermedias, ejecute el siguiente comando de OpenSSL:

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

Si el emisor del certificado de cliente de la solicitud de API está incluido en el almacén de confianza requerido, el comando devuelve la respuesta OK.

Si el emisor del certificado de cliente no está incluido en el almacén de confianza requerido, el comando devuelve el siguiente error: «error X at Y depth lookup: unable to get local issuer certificate»

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

Si uno de los certificados de cliente del almacén de confianza del nombre de dominio personalizado no es válido, es posible que algunos clientes no puedan acceder a la API. Para confirmar que los certificados de cliente del 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 Nombres de dominio personalizados. Luego, elija el nombre de dominio personalizado que requiera TLS mutuo.

3. En la sección Detalles, compruebe si aparece el siguiente mensaje de error: There is an invalid certificate in your truststore bundle.

4. Si ve el mensaje de error, descodifique los certificados del almacén de confianza para identificar qué certificado generó la advertencia.
   **Nota:**El siguiente comando de OpenSSL muestra el asunto y el contenido de un certificado:

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

5. Actualice o elimine los certificados que generaron la advertencia. A continuación, suba un nuevo almacén de confianza a 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 los certificados de cliente firmados directamente por la autoridad de certificación raíz o cualquier otra autoridad de certificación intermedia. Para validar los certificados de cliente firmados únicamente por la última autoridad certificadora intermedia, utilice un Autorizador de AWS Lambda basado en parámetros de solicitud. Puede usar su algoritmo de validación personalizado en el nivel de función de Lambda. Para ello, acepte el certificado de cliente como entrada de la solicitud de API.

Resolver errores «Access denied. Reason: Client cert using an insecure Signature Algorithm»

Compruebe que su archivo de texto de truststore utilice un algoritmo de hash compatible. API Gateway admite los siguientes algoritmos de 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 confirmar que su archivo de texto de almacén de confianza utiliza un algoritmo de hash compatible, 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 del almacén de confianza.

Para obtener más información, consulte Configuración de su tienda de confianza.

Resolver errores «Access denied. Reason: self signed certificate»

Compruebe que el certificado de cliente autofirmado de la solicitud de API no esté alterado ni dañado. La solicitud de firma de certificación de cliente (my_client.csr), la clave privada del certificado de cliente (my_client.key) y la clave pública del certificado de cliente (my_client.pem) deben coincidir.

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

$ openssl rsa -noout -modulus -in my_client.csr
$ openssl x509 -noout -modulus -in my_client.key
$ openssl x509 -noout -modulus -in my_client.pem

Nota: Para producir un valor hash más corto y facilitar la comparación, utilice una canalización en el módulo de salida. Consulte el siguiente ejemplo de openssl sha1:

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

Un ejemplo de salida válido es similar al siguiente:

2143831a73a8bb28467860df18550c696c03fbcb2143831a73a8bb28467860df18550c696c03fbcb
2143831a73a8bb28467860df18550c696c03fbcb

Para confirmar la integridad de los datos, compruebe que no haya ninguna modificación de los datos a nivel de contenido. Ejecute el siguiente comando diff:

$ diff client.crt bundle.crt

Para obtener más información, consulte Configuración de su tienda de confianza.