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

Ultimo aggiornamento: 08-12-2021

Il nome di dominio personalizzato Amazon API Gateway con autenticazione Transport Layer Security (TLS) reciproca attivata restituisce errori HTTP 403 Non consentito. Perché si verifica questo problema e come posso risolverlo?

Breve descrizione

Nota: API Gateway può restituire errori 403 Non consentito per diversi motivi. Questo articolo descrive errori 403 Non consentito solo relativi all'autenticazione TLS reciproca. Per informazioni sulla risoluzione di altri tipi di errori 403 Non consentito, consulta In che modo posso risolvere gli errori HTTP 403 Non consentito da API Gateway?

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

Se si verifica una delle seguenti condizioni, API Gateway non riesce a connettersi a TLS e restituisce un codice di stato 403:

  • API Gateway 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 API REST, 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. Motivo: certificato autofirmato

Per le 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 richiama un'API REST solo per il test.
Nota: se non hai un'API REST disponibile per il test, usa l'API REST di esempio PetStore. Quindi, distribuisci 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.    Se non l'hai già fatto, attiva la registrazione di CloudWatch per la tua API REST. Assicurati di configurare l'esecuzione e la registrazione degli accessi.

Nota: quando si configura la registrazione degli accessi per questo caso d'uso, è consigliabile utilizzare le seguenti variabili $context. Queste variabili fanno due cose:

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

Variabili $context consigliate per la registrazione degli accessi di CloudWatch che consentiranno a API Gateway 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 cosa sta causando gli errori 403 Non consentito visualizzando i log di esecuzione dell'API REST in CloudWatch. Se viene registrato un errore 403 Non consentito relativo all'autenticazione TLS reciproca, viene visualizzato un messaggio di errore simile all'esempio seguente.

Esempio: messaggio di errore di CloudWatch Logs per quando un nome di dominio personalizzato che richiede l'autenticazione TLS reciproca restituisce un errore 403 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 bundle di certificati contiene autorità di certificazione intermedie, emetti il seguente comando OpenSSL:

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

Il comando restituisce una risposta OK se l'emittente del certificato client nella richiesta API è incluso nel truststore richiesto.

Il comando restituisce il seguente errore se l'emittente del certificato client non è incluso nel truststore richiesto: "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: C'è un certificato non valido nel tuo bundle truststore.

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 sui certificati.

Nota: API Gateway accetta certificati client firmati direttamente dall'autorità di certificazione root o da qualsiasi altro intermedio se la loro catena di certificati viene mantenuta. Per convalidare i certificati client firmati solo dall'ultima autorità di certificazione intermedia, utilizza un'autorizzazione per AWS Lambda basata 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 o meno un algoritmo di hashing supportato, emetti 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, emetti 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 PIPE sul modulo di output in una funzione hash crittografica. Ad 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 sia stata apportata alcuna modifica ai dati a livello di contenuto eseguendo il comando diff:

$ diff client.crt bundle.crt

Per ulteriori informazioni, consulta Configurazione delle policy di accesso.


Questo articolo è stato utile?


Hai bisogno di supporto tecnico o per la fatturazione?