Comment dois-je résoudre les erreurs HTTP 403 Forbidden (HTTP 403 accès interdit) provenant d'un nom de domaine personnalisé d'API Gateway qui nécessite une authentification TLS mutuelle ?

Brève description

Remarque : API Gateway peut renvoyer des erreurs 403 Forbidden (403 accès interdit) pour diverses raisons. Cet article traite des erreurs 403 Forbidden (403 accès interdit) uniquement liées à l'authentification TLS mutuelle. Pour en savoir plus sur le dépannage d'autres types d'erreurs 403 Forbidden (403 accès interdit), consultez la section Comment résoudre les erreurs HTTP 403 Forbidden (HTTP 403 accès interdit) provenant d'API Gateway ?

Pourappeler une API, API Gateway à l'aide d'un nom de domaine personnalisé qui nécessite une authentification TLS mutuelle, les clients doivent présenter un certificat approuvé dans la demande d'API. Lorsqu'un client tente d'appeler l'API, API Gateway recherche l'auteur du certificat client dans votre magasin de confiance.

Les conditions suivantes entraînent l'échec de la connexion TLS par API Gateway et le renvoi d'un code d'état 403 :

• API Gateway ne trouve pas l'auteur du certificat client dans votre magasin de confiance.
• Le certificat client utilise un algorithme de signature non sécurisé.
• Le certificat client est autosigné.

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

Important : si la demande d'API ne produit pas de CloudWatch Logs après l'activation de la journalisation, l'erreur 403 Forbidden (403 accès 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 : auteur du certificat introuvable
• Accès refusé. Raison : certificat client utilisant un algorithme de signature non sécurisé
• Accès refusé. Raison : certificat autosigné

Pour les opérations de l'API HTTP

Les API HTTP ne prennent pas en charge la journalisation d'exécution. Pour résoudre les erreurs 403 Forbidden (403 accès interdit) renvoyées par un nom de domaine personnalisé qui nécessite une authentification TLS mutuelle et appelle une API HTTP, vous devez procéder comme suit :

1.    Créez un mappage d'API pour votre nom de domaine personnalisé qui appelle une API REST uniquement à des fins de test.
Remarque : si aucune API REST n'est disponible pour les tests, utilisez l'exemple d'API REST PetStore. Ensuite, déployez l'exemple d'API à une nouvelle étape et créez un mappage d'API qui utilise votre nom de domaine personnalisé.

2.    Suivez les instructions de la section Résolution de cet article en utilisant le mappage d'API que vous avez créé avec votre API REST.

3.    Une fois l'erreur identifiée et résolue, redirigez le mappage d'API pour votre nom de domaine personnalisé vers l'API HTTP.

Résolution

Confirmer la cause de l'erreur

1.   Activez la journalisation CloudWatch pour votre API REST. Ensuite, configurez la journalisation de l'exécution et des accès.

Lors de la configuration de la journalisation d'accès pour ce cas d'utilisation, il est recommandé d'utiliser les variables $context suivantes. Ces variables remplissent deux rôles :

• Elles indiquent à API Gateway de générer CloudWatch Logs lorsque votre nom de domaine personnalisé qui nécessite une authentification TLS mutuelle renvoie une erreur 403 Forbidden (403 accès interdit).
• Elles facilitent l'identification de l'appelant qui a essayé d'appeler votre opération API lorsque vous consultez CloudWatch Logs.

Variables $context recommandées pour la journalisation d'accès CloudWatch qui permettra à API Gateway de générer des journaux d'exécution et d'accès

{ "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.    Identifiez la cause des erreurs 403 Forbidden (403 accès interdit) en consultant vos journaux d'exécution de l'API REST dans CloudWatch. Si une erreur 403 Forbidden (403 accès interdit) liée à l'authentification TLS mutuelle est consignée, vous recevez un message d'erreur semblable à ce dernier :

Exemple de message d'erreur CloudWatch Logs lorsqu'un nom de domaine personnalisé qui nécessite une authentification TLS mutuelle renvoie une erreur 403 Forbidden (403 accès interdit)

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

Pour résoudre les erreurs « Accès refusé. Raison : impossible de trouver l'auteur du certificat »

Vérifiez que l'auteur du certificat client dans la demande d'API est inclus dans le magasin de confiance du nom de domaine personnalisé

L'auteur du certificat client (client.pem) dans la demande d'API doit être inclus dans le magasin de confiance de votre nom de domaine personnalisé. L'auteur doit également être inclus dans la solution groupée de certificats (bundle.pem) dans Amazon Simple Storage Service (Amazon S3).

Pour vérifier si l'auteur du certificat client est inclus dans le magasin de confiance requis, exécutez la commande OpenSSL suivante :

$ openssl verify -CAfile bundle.pem client.pem

-ou-

Si la solution groupée de certificats contient des autorités de certification intermédiaire, exécutez la commande OpenSSL suivante :

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

Si l'auteur du certificat client dans la demande d'API est inclus dans le magasin de confiance requis, la commande renvoie une réponse OK.

Si l'auteur du certificat client n'est pas inclus dans le magasin de confiance requis, la commande renvoie l'erreur suivante : « erreur X à la recherche de profondeur Y : impossible d'obtenir le certificat d'auteur local »

Vérifiez que tous les certificats clients du magasin de confiance de votre nom de domaine personnalisé sont valides

Si l'un des certificats clients du magasin de confiance de votre nom de domaine personnalisé n'est pas valide, certains clients peuvent ne pas être en mesure d'accéder à l'API.

Pour vérifier si tous les certificats clients de votre magasin de confiance sont valides, procédez comme suit :

1.    Ouvrez la console API Gateway.

2.    Dans le panneau de navigation de gauche, choisissezCustom domain names (Noms de domaine personnalisés). Choisissez ensuite votre nom de domaine personnalisé qui nécessite une authentification TLS mutuelle.

3.    Dans la sectionDetails (Détails), recherchez le message d'erreur suivant :There is an invalid certificate in your truststore bundle (Votre solution groupée du magasin de confiance contient un certificat non valide).

4.    Si le message d'erreur s'affiche, vous devez décoder les certificats de votre magasin de confiance pour identifier le certificat à l'origine de l'avertissement.
Remarque : la commande OpenSSL suivante affiche le contenu d'un certificat, y compris son sujet :

$ openssl x509 -in certificate.crt -text -noout

5.    Mettez à jour ou supprimez les certificats à l'origine de l'avertissement. Ensuite, chargez un nouveau magasin de confiance dans Amazon S3.

Pour plus d'informations, consultez la section Résolution des avertissements relatifs aux certificats.

Remarque : si leur chaîne de certificats est préservée, API Gateway accepte les certificats clients directement signés par l'autorité de certification racine ou toute autre autorité de certification intermédiaire. Pour valider les certificats clients signés uniquement par la dernière autorité de certification intermédiaire, utilisez un mécanisme d'autorisation AWS Lambda basé sur des paramètres de demande. Vous pouvez utiliser votre algorithme de validation personnalisé au niveau de la fonction Lambda en acceptant le certificat client comme entrée de la demande d'API.

Pour résoudre les erreurs « Accès refusé. Raison : certificat client utilisant un algorithme de signature non sécurisé »

Vérifiez que votre fichier texte du magasin de confiance utilise un algorithme de hachage pris en charge

API Gateway prend en charge les algorithmes de hachage suivants dans le magasin de confiance :

• SHA-256 minimum
• RSA-2048 minimum
• ECDSA-256 minimum

Pour vérifier si votre fichier texte de magasin de confiance utilise un algorithme de hachage pris en charge, exécutez la commande OpenSSL suivante :

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

La réponse à la commande renvoie l'algorithme de signature de votre magasin de confiance.

Pour plus d'informations, consultez la section Configuration de votre magasin de confiance.

Pour résoudre les erreurs « Accès refusé. Raison : « certificat autosigné »

Vérifiez que le certificat client autosigné dans la demande d'API n'est ni modifié ni endommagé

Les éléments suivants doivent correspondre exactement :

• Le module de la clé privée (private.key) est utilisé pour signer le certificat autosigné dans le magasin de confiance de S3 (bundle.crt ou bundle.pem).
• Le module du certificat du client est transmis dans la demande d'API (client.crt).

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

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

Remarque : pour produire une valeur de hachage plus courte afin de faciliter la comparaison, vous pouvez intégrer via PIPE-ing le module de sortie dans une fonction de hachage cryptographique. Consultez l'exemple openssl sha1 suivant :

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

Exemples de sorties de commandes valides

2143831a73a8bb28467860df18550c696c03fbcb
2143831a73a8bb28467860df18550c696c03fbcb
2143831a73a8bb28467860df18550c696c03fbcb

Pour confirmer l'intégrité des données, vérifiez qu'il n'y a pas eu de modification des données au niveau du contenu en exécutant la commande diff suivante :

$ diff client.crt bundle.crt

Pour plus d'informations, consultez la section Configuration de votre magasin de confiance.

---