Come posso risolvere gli errori HTTP 403 Forbidden relativi a un nome di dominio personalizzato di Gateway API che richiede l'autenticazione TLS reciproca?

7 minuti di lettura
0

Il nome di dominio personalizzato di Gateway Amazon API con autenticazione Transport Layer Security (TLS) reciproca attivata restituisce errori HTTP 403 Forbidden. Non so perché succede.

Breve descrizione

Nota: Gateway API restituisce errori 403 Forbidden per una serie di motivi. Questo articolo descrive soltanto gli errori 403 Forbidden relativi all'autenticazione TLS reciproca. Per informazioni sulla risoluzione di altri tipi di errori 403 Forbidden, consulta Come posso risolvere gli errori HTTP 403 di API Gateway?

Per richiamare un'API di Gateway API utilizzando un nome di dominio personalizzato che richiede l'autenticazione TLS reciproca, i client devono presentare un certificato attendibile nella richiesta API. Quando un client richiama l'API, Gateway API cerca l'emittente del certificato client nel truststore.
Le seguenti condizioni comportano l'interruzione della connessione TLS da parte di Gateway API e la restituzione di un codice di stato 403:

  • Gateway API non è in grado di trovare l'emittente del certificato client nel truststore.
  • Il certificato client utilizza un algoritmo di firma non sicuro.
  • Il certificato client è autofirmato.

Se la registrazione di Amazon CloudWatch è attivata per l'API, nei log di esecuzione viene visualizzato un messaggio di errore che ne indica la causa.

Importante: se la richiesta API non produce alcun log di CloudWatch dopo l'attivazione della registrazione, l'errore 403 Forbidden non è correlato all'autenticazione TLS reciproca.

Per le REST API

Se configuri la registrazione Amazon CloudWatch della REST API,, i log di esecuzione restituiscono anche uno dei seguenti messaggi di errore:

  • 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

Per le operazioni dell'API HTTP

Le API HTTP non supportano la registrazione delle esecuzioni. Per risolvere gli errori 403 Forbidden restituiti da un nome di dominio personalizzato che richiede TLS reciproco e richiama un'API HTTP, procedi come segue:

  1. Crea una nuova mappatura API per il tuo nome di dominio personalizzato che richiami una REST API solo per l'esecuzione di test.
    Nota: se non disponi di una REST API da testare, utilizza la REST API PetStore di esempio. Quindi, implementa l'API di esempio in una nuova fase e crea una nuova mappatura API che utilizzi il nome di dominio personalizzato.
  2. Segui le istruzioni riportate nella sezione Soluzione di questo articolo utilizzando la nuova mappatura API creata per la REST API.
  3. Reindirizza la mappatura API per il tuo nome di dominio personalizzato all'API HTTP.

Soluzione

Conferma della causa dell'errore

  1. Attiva la registrazione di CloudWatch per la REST API.
  2. Configura la registrazione dell'esecuzione e degli accessi.
    Nota: quando configuri la registrazione degli accessi per questo caso d'uso, è consigliabile utilizzare le seguenti variabili $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" }
    Queste variabili indicano a Gateway API di generare log di CloudWatch quando il nome di dominio personalizzato che richiede l'autenticazione TLS reciproca restituisce un errore 403. Inoltre, semplificano l'identificazione del chiamante che ha provato a richiamare l'operazione API.
  3. Visualizza i log di esecuzione delle REST API in CloudWatch per identificare la causa dell'errore. Se viene registrato un errore 403 Forbidden relativo all'autenticazione TLS reciproca, visualizzerai un messaggio di errore simile al seguente:
    Extended Request Id: {extendedRequestId} Access denied. Reason: {reason}
    ForbiddenException Forbidden: {requestId}

Risoluzione degli errori "Access denied. Reason: Could not find issuer for certificate"

Verifica che l'emittente del certificato client nella richiesta API sia incluso nel truststore del nome di dominio personalizzato

L'emittente del certificato client (client.pem) nella richiesta API deve essere incluso nel truststore del nome di dominio personalizzato. L'emittente deve inoltre essere incluso nel pacchetto di certificati (bundle.pem) in Amazon Simple Storage Service (Amazon S3).
Per verificare che l'emittente del certificato client sia incluso nel truststore richiesto, esegui il comando OpenSSL seguente:

$ openssl verify -CAfile bundle.pem client.pem

-oppure-

Se il pacchetto di certificati contiene autorità di certificazione intermedie, esegui il comando OpenSSL seguente:

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

Se l'emittente del certificato client nella richiesta API è incluso nel truststore richiesto, il comando restituisce la risposta OK.

Se l'emittente del certificato client non è incluso nel truststore richiesto, il comando restituisce il seguente errore: "error X at Y depth lookup: unable to get local issuer certificate"

Verifica che tutti i certificati client presenti nel truststore del nome di dominio personalizzato siano validi

Se uno dei certificati client nel truststore del nome di dominio personalizzato non è valido, alcuni client potrebbero non essere in grado di accedere alla tua API. Per confermare che tutti i certificati client nel truststore sono validi, procedi come segue:

  1. Apri la console Gateway API.

  2. Nel riquadro di navigazione a sinistra, scegli Nomi di dominio personalizzati. Quindi, scegli il nome di dominio personalizzato che richiede l'autenticazione TLS reciproca.

  3. Nella sezione Dettagli, verifica la presenza del messaggio di errore seguente: There is an invalid certificate in your truststore bundle.

  4. Se visualizzi il messaggio di errore, decodifica i certificati presenti nel truststore in modo da stabilire quale certificato ha generato l'avviso.
    Nota: il comando OpenSSL seguente visualizza l'oggetto e il contenuto di un certificato:

    $ openssl x509 -in certificate.crt -text -noout
  5. Aggiorna o rimuovi i certificati che hanno generato l'avviso. Quindi, carica un nuovo truststore su Amazon S3.

Per ulteriori informazioni, consulta Troubleshooting certificate warnings.

Nota: se la catena di certificati viene preservata, Gateway API accetta i certificati client firmati direttamente dall'autorità di certificazione root o da qualsiasi altra autorità di certificazione intermedia. Per convalidare i certificati client firmati solo dall'ultima autorità di certificazione intermedia, utilizza un sistema di autorizzazione AWS Lambda basato su parametri di richiesta. Puoi utilizzare il tuo algoritmo di convalida personalizzato a livello di funzione Lambda, accettando il certificato client come input dalla richiesta API.

Risoluzione degli errori "Access denied. Reason: Client cert using an insecure Signature Algorithm"

Verifica che il file di testo del truststore utilizzi un algoritmo di hashing supportato.Gateway API supporta i seguenti algoritmi di hashing nel truststore:

  • SHA-256 o superiore
  • RSA-2048 o superiore
  • ECDSA-256 o superiore

Per verificare che il file di testo del truststore utilizzi un algoritmo di hashing supportato, esegui il comando OpenSSL seguente:

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

La risposta al comando restituisce l'algoritmo di firma del truststore.

Per ulteriori informazioni, consulta Configuring your truststore.

Risoluzione degli errori "Access denied. Reason: self signed certificate"

Verifica che il certificato client autofirmato nella richiesta API non sia alterato o danneggiato.La richiesta di firma della certificazione client (my_client.csr), la chiave privata del certificato client (my_client.key) e la chiave pubblica del certificato client (my_client.pem) devono corrispondere.

Per confrontare i moduli, esegui i comandi OpenSSL seguenti:

$ 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: per semplificare il confronto e produrre un valore hash più breve, usa una pipe sul modulo di output. Vedi il seguente esempio openssl sha1:

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

Un esempio di output valido è simile al seguente:

2143831a73a8bb28467860df18550c696c03fbcb2143831a73a8bb28467860df18550c696c03fbcb
2143831a73a8bb28467860df18550c696c03fbcb

Per confermare l'integrità dei dati, verifica che non vengano apportate modifiche a livello di contenuto. Esegui il comando diff seguente:

$ diff client.crt bundle.crt

Per ulteriori informazioni, consulta Configuring your truststore.