Como soluciono erros HTTP 403 Forbidden de um nome de domínio personalizado do API Gateway que exige TLS mútuo?

Breve descrição

Observação: o API Gateway retorna erros 403 Forbidden por vários motivos. Este artigo aborda erros 403 Forbidden relacionados somente ao TLS mútuo. Para obter informações sobre como solucionar outros tipos de erros 403 Forbidden, consulte Como soluciono erros “HTTP 403 Forbidden” do API Gateway?

Para invocar uma API do API Gateway com um nome de domínio personalizado que exija TLS mútuo, os clientes devem apresentar um certificado confiável na solicitação da API. Quando um cliente invoca a API, o API Gateway procura o emissor do certificado do cliente na sua truststore.
As condições a seguir fazem com que o API Gateway não se conecte ao TLS e retorne um código de status 403:

• O API Gateway não consegue encontrar o emissor do certificado do cliente em sua truststore.
• O certificado do cliente usa um algoritmo de assinatura não seguro.
• O certificado do cliente é autoassinado.

Quando o log do Amazon CloudWatch é ativado para sua API, uma mensagem de erro que indica a causa do erro aparece nos seus logs de execução.

Importante: se a solicitação da API não produzir nenhum Log do CloudWatch após a ativação do registro em log, o erro 403 Forbidden não estará relacionado ao TLS mútuo.

Para APIs REST

Se você configurar o registro em log do Amazon CloudWatch para sua API REST, uma das seguintes mensagens de erro também aparecerá nos seus logs de execução:

• 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 operações de API HTTP

As APIs HTTP não oferecem suporte a registro em log de execução. Para solucionar erros 403 Forbidden retornados por um nome de domínio personalizado que exige TLS mútuo e invoca uma API HTTP, faça o seguinte:

1. Crie um novo mapeamento de API para seu nome de domínio personalizado que invoque uma API REST apenas para fins de teste.
   Observação: se você não tiver uma API REST para testar, use o exemplo da API REST PetStore. Em seguida, implante a API de exemplo em um novo estágio e crie um novo mapeamento de API que use seu nome de domínio personalizado.
2. Siga as instruções na seção Resolução deste artigo com o novo mapeamento de API que você criou para sua API REST.
3. Redirecione o mapeamento da API do seu nome de domínio personalizado de volta à sua API HTTP.

Resolução

Confirme a causa do erro

1. Ative o registro em log do CloudWatch para sua API REST.
2. Configure a execução e o registro em log de acesso.
   Observação: quando você configura o registro em log de acesso para esse caso de uso, é uma prática recomendada para as seguintes variáveis $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" }

   Essas variáveis fazem com que o API Gateway gere Logs do CloudWatch quando seu nome de domínio personalizado que exige TLS mútuo retorna um erro 403. Eles também facilitam a identificação do chamador que tentou invocar sua operação de API.
3. Visualize os logs de execução da sua API REST no CloudWatch para identificar a causa do erro. Se um erro 403 Forbidden relacionado ao TLS mútuo for registrado, você receberá uma mensagem de erro semelhante à seguinte:

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

Resolva erros “Access denied. Reason: Could not find issuer for certificate”

Verifique se o emissor do certificado do cliente na solicitação da API está incluído no repositório confiável do nome de domínio personalizado

O emissor do certificado do cliente (client.pem) na solicitação da API deve ser incluído no repositório confiável do seu nome de domínio personalizado. O emissor também deve ser incluído como parte do pacote de certificados (bundle.pem) no Amazon Simple Storage Service (Amazon S3).
Para verificar se o emissor do certificado do cliente está incluído no armazenamento confiável necessário, execute o seguinte comando OpenSSL:

$ openssl verify -CAfile bundle.pem client.pem

-ou-

Se o pacote de certificados contiver autoridades de certificação intermediárias, execute o seguinte comando OpenSSL:

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

Se o emissor do certificado do cliente na solicitação da API estiver incluído no armazenamento confiável necessário, o comando retornará uma resposta OK.

Se o emissor do certificado do cliente não estiver incluído no armazenamento confiável necessário, o comando retornará o seguinte erro: “error X at Y depth lookup: unable to get local issuer certificate”

Verifique se todos os certificados de cliente no repositório confiável do seu nome de domínio personalizado são válidos

Se um dos certificados de cliente no repositório confiável do seu nome de domínio personalizado não for válido, alguns clientes talvez não consigam acessar sua API. Para confirmar se os certificados do cliente em seu repositório confiável são válidos, faça o seguinte:

1. Abra o console do API Gateway.

2. No painel de navegação esquerdo, escolha Nomes de domínio personalizados. Em seguida, escolha seu nome de domínio personalizado que exija TLS mútuo.

3. Na seção Detalhes, verifique a seguinte mensagem de erro: Há um certificado inválido em seu pacote da truststore.

4. Se você vir a mensagem de erro, decodifique os certificados em seu repositório confiável para identificar qual certificado produziu o aviso.
   Observação: o comando OpenSSL a seguir exibe o assunto e o conteúdo de um certificado:

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

5. Atualize ou remova os certificados que produziram o aviso. Em seguida, faça o upload de um novo truststore para o Amazon S3.

Para obter mais informações, consulte Solução de problemas de avisos de certificado.

Observação: se sua cadeia de certificados for preservada, o API Gateway aceitará certificados de cliente assinados diretamente pela autoridade de certificação raiz ou por qualquer outra autoridade de certificação intermediária. Para validar certificados de clientes assinados somente pela última autoridade de certificação intermediária, use um AWS Lambda Authorizer baseado em parâmetros de solicitação. Você pode usar seu algoritmo de validação personalizado no nível da função do Lambda. Para fazer isso, aceite o certificado do cliente como entrada da solicitação da API.

Resolva erros “Access denied. Reason: Client cert using an insecure Signature Algorithm”

Verifique se o arquivo de texto da truststore usa um algoritmo de hash compatível. O API Gateway é compatível com os seguintes algoritmos de hash no armazenamento confiável:

• SHA-256 ou mais forte
• RSA-2048 ou mais forte
• ECDSA-256 ou mais forte

Para confirmar que seu arquivo de texto da truststore usa um algoritmo de hash compatível, execute o seguinte comando OpenSSL:

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

A resposta do comando retorna o algoritmo de assinatura da sua truststore.

Para obter mais informações, consulte Configuração do armazenamento de confiança.

Resolva erros “Access denied. Reason: self signed certificate”

Verifique se o certificado de cliente autoassinado na solicitação da API não está alterado ou corrompido. A solicitação de assinatura da certificação do cliente (my_client.csr), a chave privada do certificado do cliente (my_client.key) e a chave pública do certificado do cliente (my_client.pem) devem corresponder.

Para comparar os módulos, execute estes comandos do 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

Observação: para produzir um valor de hash mais curto para facilitar a comparação, use um tubo no módulo de saída. Veja o seguinte exemplo de openssl sha1:

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

Um exemplo de saída válido é semelhante ao seguinte:

2143831a73a8bb28467860df18550c696c03fbcb2143831a73a8bb28467860df18550c696c03fbcb
2143831a73a8bb28467860df18550c696c03fbcb

Para confirmar a integridade dos dados, verifique se não há nenhuma modificação de dados no nível do conteúdo. Execute o seguinte comando diff:

$ diff client.crt bundle.crt

Para obter mais informações, consulte Configuração do armazenamento de confiança.