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

Breve descrizione

Nota: Gateway API può restituire errori 403 Forbidden (Non consentito) per diversi motivi. Questo articolo descrive soltanto gli errori 403 Forbidden (Non consentito) relativi all'autenticazione TLS reciproca. Per informazioni sulla risoluzione di altri tipi di errori 403 Forbidden (Non consentito), consulta How do I troubleshoot HTTP 403 Forbidden errors from API Gateway? (Come posso risolvere gli errori HTTP 403 Forbidden (Non consentito) di Gateway API?)

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 prova a richiamare l'API, Gateway API cerca l'emittente del certificato client nel tuo truststore.

Le seguenti condizioni fanno sì che Gateway API interrompa la connessione TLS e restituisca un codice di stato 403:

• Gateway API non riesce a trovare l'emittente del certificato client nel tuo truststore.
• Il certificato client utilizza un algoritmo di firma non sicuro.
• Il certificato del cliente è autofirmato.

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

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

Per le API REST

Se configuri la registrazione di Amazon CloudWatch per la tua REST API, nei log di esecuzione viene visualizzato anche uno dei seguenti messaggi di errore:

• Accesso negato. Motivo: impossibile trovare l'emittente del certificato
• Accesso negato. Motivo: il certificato client utilizza un algoritmo di firma non sicuro
• Accesso negato. Reason: self signed certificate (Accesso negato. Motivo: certificato autofirmato)

Per le operazioni dell'API HTTP

Le API HTTP non supportano la registrazione dell'esecuzione. Per risolvere gli errori 403 Non consentito restituiti da un nome di dominio personalizzato che richiede l'autenticazione TLS reciproca e richiama un'API HTTP, è necessario effettuare le seguenti operazioni:

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 per il test, 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 tuo nome di dominio personalizzato.

2.    Segui le istruzioni nella sezione Risoluzione di questo articolo utilizzando la nuova mappatura API creata per l'API REST.

3.    Una volta identificato e risolto l'errore, reindirizza la mappatura API per il tuo nome di dominio personalizzato all'API HTTP.

Risoluzione

Conferma della causa dell'errore

1.   Attiva la registrazione di CloudWatch per la tua REST API. Quindi, configura la registrazione dell'esecuzione e degli accessi.

Quando si configura la registrazione degli accessi per questo caso d'uso, una best practice consiste nell'utilizzare le seguenti variabili $context. Queste variabili hanno due funzioni:

• Indicano a Gateway API di generare file di log CloudWatch quando il nome di dominio personalizzato che richiede l'autenticazione TLS reciproca restituisce un errore 403 Forbidden (Non consentito).
• Rendono più facile l'identificazione del chiamante che ha provato a richiamare la tua operazione API quando rivedi i file di log CloudWatch.

Variabili $context consigliate per la registrazione degli accessi di CloudWatch che consentiranno a Gateway API di generare log di esecuzione e accesso

{ "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.    Identifica la causa degli errori 403 Forbidden (Non consentito) consultando i log di esecuzione della REST API in CloudWatch. Se viene registrato un errore 403 Forbidden (Non consentito) relativo all'autenticazione TLS reciproca, visualizzerai un messaggio di errore simile al seguente:

Ad esempio: messaggio di errore dei file di log CloudWatch per quando un nome di dominio personalizzato che richiede l'autenticazione TLS reciproca restituisce un errore 403 Forbidden (Non consentito)

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

Per risolvere gli errori "Accesso negato. Motivo: impossibile trovare l'emittente per il certificato"

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 tuo nome di dominio personalizzato. L'emittente deve essere incluso anche come parte del pacchetto di certificati (bundle.pem) in Amazon Simple Storage Service (Amazon S3).

Per verificare se l'emittente del certificato client è incluso nel truststore richiesto, emetti il seguente comando OpenSSL:

$ openssl verify -CAfile bundle.pem client.pem

-oppure-

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

$ 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" ("errore X alla ricerca di profondità Y: impossibile ottenere il certificato dell'emittente locale")

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

Se uno dei certificati client nel truststore del tuo nome di dominio personalizzato non è valido, alcuni client potrebbero non essere in grado di accedere alla tua API.

Per verificare che tutti i certificati client nel tuo truststore siano validi, procedi come segue:

1.    Apri la console API Gateway.

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

3.    Nella sezione Dettagli, verifica la presenza del seguente messaggio di errore: There is an invalid certificate in your truststore bundle (Nel bundle truststore è presente un certificato non valido).

4.    Se visualizzi il messaggio di errore, devi decodificare i certificati nel tuo truststore in modo da identificare quale certificato ha generato l'avviso.
Nota: il seguente comando OpenSSL visualizza il contenuto di un certificato, incluso il relativo oggetto:

$ 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 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.

Per risolvere gli errori "Accesso negato. Motivo: il certificato client utilizza un algoritmo di firma non sicuro"

Verifica che il tuo file di testo truststore utilizzi un algoritmo di hashing supportato

API Gateway supporta i seguenti algoritmi di hashing nel truststore:

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

Per verificare se il tuo file di testo truststore utilizza un algoritmo di hashing supportato, esegui il seguente comando OpenSSL:

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

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

Per ulteriori informazioni, consulta Configurazione delle policy di accesso.

Per risolvere gli errori "Accesso negato. Motivo: certificato autofirmato"

Verifica che il certificato client autofirmato nella richiesta API non sia alterato o danneggiato

I seguenti elementi devono corrispondere esattamente:

• Il modulo della chiave privata (private.key) utilizzato per firmare il certificato autofirmato all'interno del truststore in S3 (bundle.crt o bundle.pem).
• Il modulo dal certificato del client passato nella richiesta API (client.crt).

Per confrontare i due moduli, esegui i seguenti comandi OpenSSL:

$ openssl rsa -noout -modulus -in private.key
$ openssl x509 -noout -modulus -in bundle.crt
$ openssl x509 -noout -modulus -in client.crt

Nota: per produrre un valore hash più breve per un confronto più semplice, è possibile eseguire una PIPE del modulo di output in una funzione hash crittografica. Vedi il seguente esempio openssl sha1:

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

Esempi di output del comando validi

2143831a73a8bb28467860df18550c696c03fbcb
2143831a73a8bb28467860df18550c696c03fbcb
2143831a73a8bb28467860df18550c696c03fbcb

Per confermare l'integrità dei dati, verifica che non vengano apportate modifiche al loro contenuto durante l'esecuzione del comando diff:

$ diff client.crt bundle.crt

Per ulteriori informazioni, consulta Configurazione del truststore.

---