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

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 i problemi che causano errori HTTP 403 di Gateway API?

Per invocare 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 invoca 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 Logs dopo l'attivazione della registrazione, l'errore 403 Forbidden non è correlato all'autenticazione TLS reciproca.

Per le REST API

Se configuri la registrazione di Amazon CloudWatch della REST API, i log di esecuzione restituiscono 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 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 l'autenticazione TLS reciproca e invoca un'API HTTP, procedi come segue:

1. Crea una nuova mappatura API per il tuo nome di dominio personalizzato che richiami invochi 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, usa 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" }

   Questo modello di log degli accessi registra le informazioni sul certificato client quando l'autenticazione TLS reciproca causa errori 403. Inoltre, semplifica l'identificazione del chiamante che ha provato a invocare l'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

La catena di certificati completa del certificato client (client.pem) nella richiesta API deve essere inclusa nel truststore del nome di dominio personalizzato. Il truststore (bundle.pem) è un file archiviato 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

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

Per risolvere questo errore, carica un nuovo truststore su Amazon S3 che includa la catena di certificati completa del certificato client.

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, completa i passaggi seguenti:

1. Apri la console Gateway Amazon API.

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

3. Nella sezione Dettagli del dominio, verifica la presenza di un avviso come: Il tuo pacchetto truststore contiene 1 certificato non valido.

4. Se visualizzi l’avviso, decodifica i certificati presenti nel truststore per stabilire quale certificato ha generato l'avviso. 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 Risoluzione dei problemi relativi agli avvisi dei certificati.

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 creare un algoritmo di convalida personalizzato nel sistema di autorizzazione Lambda basato sulla richiesta. Il certificato client è disponibile nell'input della richiesta API in requestContext.identity.ClienCert.

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. Se l'algoritmo non è supportato, aggiorna il certificato client per utilizzare un algoritmo supportato. Quindi, carica un nuovo truststore su Amazon S3.

Per ulteriori informazioni, consulta Configurazione del 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 del certificato 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 seguenti comandi OpenSSL:

openssl req -noout -modulus -in my_client.csr
openssl rsa -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 l'esempio openssl sha1 seguente:

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

Un esempio di output valido è simile al seguente:

2143831a73a8bb28467860df18550c696c03fbcb
2143831a73a8bb28467860df18550c696c03fbcb
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

Se i moduli non corrispondono o il comando diff restituisce differenze, rigenera il certificato client e aggiorna il tuo truststore. Quindi, carica un nuovo truststore su Amazon S3.

Per ulteriori informazioni, consulta Configurazione del truststore.

Informazioni correlate

Come attivare l'autenticazione TLS reciproca per le REST API in Gateway API