Comment puis-je résoudre les erreurs HTTP 403 Interdit 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 Interdit pour diverses raisons. Cet article traite des erreurs 403 Interdit liées uniquement à l’authentification TLS mutuelle. Pour en savoir plus sur la résolution des autres types d’erreurs 403 Interdit, consultez la page Comment puis-je résoudre les erreurs HTTP 403 renvoyées par API Gateway ?

Pour appeler une API API Gateway avec un nom de domaine personnalisé qui nécessite l’authentification TLS mutuelle, les clients doivent présenter un certificat approuvé dans la demande d’API. Lorsqu’un client appelle 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 demande 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 :

• Accès refusé. Raison : Émetteur du certificat introuvable
• Accès refusé. Raison : Certificat client utilisant un algorithme de signature non sécurisé
• Accès refusé. Raison : certificat auto-signé

Pour les opérations d’API HTTP

Les API HTTP ne sont pas compatibles avec la journalisation des exécutions. Pour résoudre les erreurs 403 renvoyées lorsqu’un nom de domaine personnalisé qui nécessite une authentification TLS mutuelle appelle une API HTTP, vous devez procéder comme suit :

1. Créez un nouveau mappage d’API pour votre nom de domaine personnalisé qui appelle 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, il est recommandé d’utiliser les variables $context suivantes :

   { "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" }

   Ces variables indiquent à API Gateway de générer des journaux CloudWatch lorsque votre nom de domaine personnalisé qui demande une authentification TLS mutuelle renvoie une erreur 403. Elles permettent également d’identifier plus facilement l’utilisateur qui a tenté d’appeler votre opération d’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 Interdit liée à l’authentification TLS mutuelle est enregistrée, vous recevez un message d’erreur similaire au suivant :

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

Résolvez les erreurs « Accès refusé. Raison : émetteur du certificat introuvable »

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

L’émetteur du certificat client (client.pem) figurant dans la demande d’API doit être inclus dans le truststore de votre nom de domaine personnalisé. L’émetteur doit également être inclus dans l’ensemble de certificats (bundle.pem) 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

-ou-

Si l’ensemble 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 : « erreur X à une profondeur de recherche Y : impossible d’obtenir le certificat de l’émetteur local ».

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 API Gateway.

2. Dans le volet de navigation de gauche, 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, recherchez le message d’erreur suivant : L’ensemble de certificats dans votre truststore contient un certificat non valide.

4. Si le message d’erreur s’affiche, décodez les certificats dans votre Truststore pour identifier le certificat à l’origine de cet avertissement.
   Remarque : 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. Téléchargez ensuite un nouveau truststore sur Amazon S3.

Pour en savoir plus, consultez la page 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 demande. Vous pouvez utiliser votre algorithme de validation personnalisé au niveau de la fonction Lambda. Pour ce faire, acceptez le certificat client comme entrée de la demande d’API.

Résolvez les erreurs « Accès refusé. Raison : Le certificat client utilise un algorithme de signature non sécurisé ».

Vérifiez que le fichier texte 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 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.

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

Résolvez les erreurs « Accès refusé. Raison : certificat auto-signé ».

Vérifiez que le certificat client auto-signé figurant dans la demande d’API n’est ni modifié ni endommagé. La demande de signature de certification 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 rsa -noout -modulus -in my_client.csr
$ openssl x509 -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. Consultez l’exemple d’algorithme openssl sha1 suivant :

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

Un exemple de sortie valide ressemble à ce qui suit :

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

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