Comment puis-je résoudre les erreurs HTTP 403 Forbidden générées par un nom de domaine personnalisé API Gateway qui demande une authentification TLS mutuelle ?

Brève description

Remarque : API Gateway renvoie des erreurs 403 Forbidden pour diverses raisons. Cet article traite des erreurs 403 Forbidden liées uniquement à l’authentification TLS mutuelle. Pour en savoir plus sur la résolution des autres types d’erreurs 403 Forbidden, consultez la section Comment puis-je résoudre les erreurs HTTP 403 renvoyées par API Gateway ?

Pour invoquer une API d’API Gateway avec un nom de domaine personnalisé qui requiert l’authentification TLS mutuelle, les clients doivent présenter un certificat approuvé dans la requête d’API. Lorsqu’un client invoque l’API, API Gateway recherche l’émetteur du certificat client dans votre truststore.

Les conditions suivantes forcent API Gateway à faire échouer la connexion TLS et à renvoyer un code d’état 403 :

• API Gateway ne trouve pas l’émetteur du certificat client dans votre truststore.
• Le certificat client utilise un algorithme de signature non sécurisé.
• Le certificat client est autosigné.

Si vous avez activé la journalisation Amazon CloudWatch pour votre API, un message indiquant la cause de l’erreur s’affiche dans vos journaux d’exécution.

Important : Si la requête m, d’API ne génère aucun journal CloudWatch une fois la journalisation activée, l’erreur 403 Interdit n’est pas liée à l’authentification TLS mutuelle.

Pour les API REST

Si vous configurez la`journalisation Amazon CloudWatch pour votre API REST, l’un des messages d’erreur suivants s’affiche également dans vos journaux d’exécution :

• 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

Pour les API HTTP

Les API HTTP ne sont pas compatibles avec la journalisation des exécutions. Pour résoudre les erreurs 403 Forbidden renvoyées par un nom de domaine personnalisé qui requiert le TLS mutuel et invoque une API HTTP, vous devez procéder comme suit :

1. Créez un nouveau mappage d’API pour votre nom de domaine personnalisé qui invoque une API REST à des fins de test uniquement.
   Remarque : Si vous n’avez pas d’API REST à tester, utilisez l’exemple d’API REST PetStore. Déployez ensuite l’exemple d’API dans une nouvelle étape, puis créez un nouveau mappage d’API qui utilise votre nom de domaine personnalisé.
2. Suivez les instructions de la section Résolution de cet article pour utiliser le nouveau mappage d’API que vous avez créé avec votre API REST.
3. Redirigez le mappage d’API de votre nom de domaine personnalisé vers votre API HTTP.

Résolution

Vérifier l’origine de l’erreur

1. Activez la journalisation CloudWatch pour votre API REST.

2. Configurez la journalisation des exécutions et des accès. Remarque : Lorsque vous configurez la journalisation des accès pour ce cas d'utilisation, utilisez les variables $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" }

   Ce modèle de journal d'accès journalise les informations du certificat client lorsque le protocole TLS mutuel provoque des erreurs 403. Il permet également d’identifier plus facilement l’appelant qui a tenté d’invoquer votre API.

3. Consultez les journaux d’exécution de votre API REST dans CloudWatch pour identifier la cause de l’erreur. Si une erreur 403 Forbidden liée à l’authentification TLS mutuelle est journalisée, vous recevez un message d’erreur similaire au suivant :

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

Résoudre les erreurs « Access denied. Reason: Could not find issuer for certificate »

Vérifiez que l’émetteur du certificat client figurant dans la demande d’API est inclus dans le truststore du nom de domaine personnalisé

La chaîne de certificats complète du certificat client (client.pem) figurant dans la requête d’API doit être incluse dans le truststore de votre nom de domaine personnalisé. Le truststore (bundle.pem) est un fichier stocké dans Amazon Simple Storage Service (Amazon S3). Pour vérifier si l’émetteur du certificat client est inclus dans le truststore requis, exécutez la commande OpenSSL suivante :

openssl verify -CAfile bundle.pem client.pem

Si le bundle de certificats contient des autorités de certification intermédiaires, exécutez la commande OpenSSL suivante :

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

Si l’émetteur du certificat client figurant dans la demande d’API est inclus dans le truststore requis, la commande renvoie OK en réponse.

Si l'émetteur du certificat client n'est pas inclus dans le truststore requis, la commande renvoie l'erreur suivante :

error X at Y depth lookup: unable to get local issuer certificate

Pour résoudre cette erreur, chargez un nouveau truststore sur Amazon S3 qui inclut la chaîne de certificats complète pour le certificat client.

Vérifier que tous les certificats client du truststore du nom de domaine personnalisé sont valides

Si l’un des certificats client du truststore de votre nom de domaine personnalisé n’est pas valide, il est possible que certains clients ne puissent pas accéder à votre API. Pour vérifier la validité des certificats client figurant dans votre truststore, procédez comme suit :

1. Ouvrez la console Amazon API Gateway.

2. Dans le volet de navigation, sélectionnez Noms de domaine personnalisés. Choisissez ensuite le nom de domaine personnalisé qui nécessite une authentification TLS mutuelle.

3. Dans la section Détails du domaine, recherchez un avertissement tel que : Votre bundle truststore contient des certificats non valides.

4. Si cet avertissement s’affiche, décodez les certificats dans votre truststore pour identifier le certificat à l’origine de cet avertissement. La commande OpenSSL suivante affiche l’objet et le contenu d’un certificat :

   openssl x509 -in certificate.crt -text -noout

5. Mettez à jour ou supprimez les certificats qui ont généré l’avertissement. Puis, chargez un nouveau truststore sur Amazon S3.

Pour en savoir plus, consultez la section Résolution des problèmes d’avertissements liés aux certificats.

Remarque : Si la chaîne de certificats est préservée, API Gateway accepte les certificats client signés directement par l’autorité de certification racine ou toute autre autorité de certification intermédiaire.Pour valider les certificats client signés uniquement par la dernière autorité de certification intermédiaire, utilisez le mécanisme d'autorisation AWS Lambda basé sur les paramètres de requête. Vous pouvez créer un algorithme de validation personnalisé dans le mécanisme d'autorisation Lambda basé sur les requêtes. Le certificat client se trouve dans l'entrée de la requête d'API sous requestContext.identity.clienCert.

Résoudre les erreurs « Access denied. Reason: Client cert using an insecure Signature Algorithm ».

Vérifiez que le fichier texte du truststore utilise un algorithme de hachage compatible. API Gateway prend en charge les algorithmes de hachage suivants dans le truststore :

• SHA-256 ou supérieur
• RSA-2048 ou supérieur
• ECDSA-256 ou supérieur

Pour vérifier que le fichier texte du truststore utilise un algorithme de hachage compatible, exécutez la commande OpenSSL suivante :

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

La commande renvoie l’algorithme de signature de votre truststore en réponse. Si l'algorithme n'est pas pris en charge, mettez à jour votre certificat client pour utiliser un algorithme pris en charge. Puis, chargez un nouveau truststore sur Amazon S3.

Pour en savoir plus, consultez la section Configuration de votre truststore.

Résoudre les erreurs « Access denied. Reason: self signed certificate ».

Vérifiez que le certificat client auto-signé figurant dans la requête d’API n’est ni modifié ni endommagé. La demande de signature du certificat client (my_client.csr), la clé privée du certificat client (my_client.key) et la clé publique du certificat client (my_client.pem) doivent correspondre.

Pour comparer les modules, exécutez les commandes OpenSSL suivantes :

openssl req -noout -modulus -in my_client.csr
openssl rsa -noout -modulus -in my_client.key
openssl x509 -noout -modulus -in my_client.pem

Remarque : Pour produire une valeur de hachage plus courte et faciliter la comparaison, utilisez une barre verticale sur le module de sortie. Reportez-vous à l’exemple openssl sha1 suivant :

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

Un exemple de sortie valide ressemble à ce qui suit :

2143831a73a8bb28467860df18550c696c03fbcb
2143831a73a8bb28467860df18550c696c03fbcb
2143831a73a8bb28467860df18550c696c03fbcb

Pour vérifier l’intégrité des données, vérifiez qu’il n’y a aucune modification des données au niveau du contenu. Exécutez la commande diff suivante :

diff client.crt bundle.crt

Si les modules ne correspondent pas ou si la commande diff renvoie des différences, régénérez le certificat client et mettez à jour votre truststore. Puis, chargez un nouveau truststore sur Amazon S3.

Pour en savoir plus, consultez la section Configuration de votre truststore.

Informations connexes

Comment activer l'authentification TLS mutuelle pour vos API REST dans API Gateway