Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Résoudre d'autres problèmes
Cette section contient des conseils relatifs à des problèmes non liés à la délivrance ou à la validation des certificats ACM.
**Topics**
+ [Problèmes d'autorisation de l'autorité de certification (CAA)](troubleshooting-caa.md)
+ [Problèmes liés à l'importation de certificat](troubleshoot-import.md)
+ [Problèmes d'épinglage de certificat](troubleshooting-pinning.md)
+ [Problèmes liés à API Gateway](troubleshoot-apigateway.md)
+ [Que faire lorsqu'un certificat de travail échoue de manière inattendue ?](unexpected-failure.md)
+ [Problèmes liés au rôle lié à un service (SLR) ACM](slr-problems.md)
# Problèmes d'autorisation de l'autorité de certification (CAA)
Vous pouvez utiliser des enregistrements DNS CAA afin de spécifier que l'autorité de certification Amazon peut émettre des certificats ACM pour votre domaine ou sous-domaine. Si vous recevez une erreur lors de l'émission du certificat indiquant **La validation a échoué pour un ou plusieurs domaines en raison d'une erreur d’autorisation de l'autorité de certification (CAA)**, vérifiez vos enregistrements DNS de CAA. Si vous recevez cette erreur alors que votre demande de certificat a été validée, vous devez mettre à jour vos enregistrements CAA et demander un nouveau certificat. Le champ de **value** (valeur) de votre enregistrement CAA doit comporter l'un des noms de domaine suivants :
+ amazon.com
+ amazontrust.com
+ awstrust.com
+ amazonaws.com
Pour plus d'informations sur la création d'un enregistrement CAA, consultez [(Facultatif) Configuration d'un enregistrement CAA](setup.md#setup-caa).
**Note**
Vous pouvez choisir de ne pas configurer un registre CAA pour votre domaine si vous ne souhaitez pas activer la vérification de CAA.
# Problèmes liés à l'importation de certificat
Vous pouvez importer des certificats tiers dans ACM et les associer à des [services intégrés](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html). Si vous rencontrez des problèmes, passez en revue les rubriques consacrées aux [prérequis](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate-prerequisites.html) et aux [formats de certificats](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate-format.html). Notez en particulier les éléments suivants :
+ Vous ne pouvez importer que des SSL/TLS certificats X.509 version 3.
+ Votre certificat peut être auto-signé ou signé par une autorité de certification (CA).
+ Si votre certificat est signé par une autorité de certification, vous devez inclure une chaîne de certificats intermédiaire qui fournit un chemin d'accès à la racine de l'autorité.
+ Si votre certificat est auto-signé, vous devez inclure la clé privée en texte brut.
+ Chaque certificat de la chaîne doit directement certifier celui qui le précède.
+ N'incluez pas votre certificat d'entité finale dans la chaîne de certificats intermédiaire.
+ Votre certificat, la chaîne de certificats et la clé privée (le cas échéant) doivent être codés PEM. En général, le codage PEM se compose de blocs de texte ASCII codé en Base64 qui commencent et se terminent par des lignes d'en-tête et de pied de page en texte brut. Vous ne devez pas ajouter de lignes ou d'espaces ni apporter d'autres modifications à un fichier PEM lors de sa copie ou de son téléchargement. Vous pouvez vérifier les chaînes de certificats à l'aide de l'[utilitaire de vérification OpenSSL](https://www.openssl.org/docs/manmaster/man1/openssl-verify.html).
+ Votre clé privée (le cas échéant) ne doit pas être chiffrée. (Astuce : si elle comporte une phrase secrète, celle-ci est chiffrée).
+ Les services [intégrés](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html) à ACM doivent utiliser des algorithmes et des tailles de clé pris en charge par ACM. Consultez le guide de l' AWS Certificate Manager utilisateur et la documentation de chaque service pour vous assurer que votre certificat fonctionnera.
+ La prise en charge des certificats par les services intégrés peut varier selon que le certificat est importé dans IAM ou dans ACM.
+ Le certificat doit être valide au moment de l'importation.
+ Les informations détaillées de l'ensemble de vos certificats sont affichées dans la console. Par défaut, toutefois, si vous appelez l'[ListCertificates](https://docs.aws.amazon.com/acm/latest/APIReference/API_ListCertificates.html)API ou la AWS CLI commande [list-certificates](https://docs.aws.amazon.com/cli/latest/reference/acm/list-certificates.html) sans spécifier le `keyTypes` filtre, seuls `RSA_1024` les `RSA_2048` certificats sont affichés.
# Problèmes d'épinglage de certificat
Pour renouveler un certificat, ACM génère une nouvelle paire de clés publiques-privées. Si votre application utilise[Épinglage de certificat](acm-bestpractices.md#best-practices-pinning), parfois sous le nom d'épinglage SSL, pour épingler un certificat ACM, il est possible qu' AWS elle ne puisse pas se connecter à votre domaine après le renouvellement du certificat. C'est pourquoi nous vous recommandons de ne pas épingler de certificat ACM. Si votre application doit épingler un certificat, vous pouvez procéder comme suit :
+ [Importez votre propre certificat dans ACM](import-certificate.md), puis épinglez votre application au certificat importé. ACM ne fournit pas de renouvellement géré pour les certificats importés.
+ Si vous utilisez un certificat public, épinglez votre application à tous les [Amazon root certificates](https://www.amazontrust.com/repository/) (certificats racines Amazon) disponibles. Si vous utilisez un certificat privé, épinglez votre application au certificat racine de votre CA.
# Problèmes liés à API Gateway
Lorsque vous déployez un point de terminaison d'API *optimisé pour* les périphériques, API Gateway configure une CloudFront distribution pour vous. La CloudFront distribution appartient à API Gateway, et non à votre compte. La distribution est liée au certificat ACM que vous avez utilisé lors du déploiement de votre API. Pour supprimer la liaison et autoriser ACM à supprimer votre certificat, vous devez supprimer le domaine personnalisé API Gateway qui est associé au certificat.
Lorsque vous déployez un point de terminaison d'API *régional*, API Gateway crée un équilibreur de charge d'application ALB (Application Load Balancer) en votre nom. L'équilibreur de charge appartient à API Gateway et n'est pas visible par vous. L'équilibreur de charge d'application est lié au certificat ACM que vous avez utilisé lors du déploiement de votre API. Pour supprimer la liaison et autoriser ACM à supprimer votre certificat, vous devez supprimer le domaine personnalisé API Gateway qui est associé au certificat.
# Que faire lorsqu'un certificat de travail échoue de manière inattendue ?
Si vous avez correctement associé un certificat ACM à un service intégré, mais que le certificat cesse de fonctionner et que le service intégré commence à renvoyer des erreurs, la cause peut être une modification des autorisations dont le service a besoin pour utiliser un certificat ACM.
Par exemple, Elastic Load Balancing (ELB) nécessite une autorisation pour déchiffrer un fichier AWS KMS key qui, à son tour, déchiffre la clé privée du certificat. Cette autorisation est accordée par une politique basée sur les ressources qu'ACM applique lorsque vous associez un certificat à ELB. Si ELB perd l'octroi de cette autorisation, il échouera la prochaine fois qu'il tentera de déchiffrer la clé du certificat.
Pour étudier le problème, vérifiez l'état de vos subventions à l'aide de la AWS KMS console à l'adresse[https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms). Puis effectuez l'une des opérations suivantes :
+ Si vous pensez que les autorisations octroyées à un service intégré ont été révoquées, accédez à la console du service intégré, dissociez le certificat du service, puis associez-le à nouveau. Cela permettra de réappliquer la stratégie basée sur les ressources et de mettre en place un nouvel octroi.
+ Si vous pensez que les autorisations accordées à ACM ont été révoquées, contactez Support at https://console.aws.amazon.com/support/ home\$1/.
# Problèmes liés au rôle lié à un service (SLR) ACM
[Lorsque vous émettez un certificat signé par une autorité de certification privée qui a été partagé avec vous par un autre compte, ACM tente, lors de la première utilisation, de configurer un rôle lié au service (SLR) afin d'interagir en tant que principal avec une Autorité de certification privée AWS politique d'accès basée sur les ressources.](https://docs.aws.amazon.com/privateca/latest/userguide/pca-resource-sharing.html#pca-rbp) Si vous émettez un certificat privé à partir d'une autorité de certification partagée et que le rôle SLR n'est pas en place, ACM ne sera pas en mesure de renouveler automatiquement ce certificat.
ACM peut vous avertir qu'il ne peut pas déterminer si un rôle SLR existe sur votre compte. Si l'autorisation `iam:GetRole` requise a déjà été accordée au rôle SLR ACM pour votre compte, l'alerte ne se reproduira pas après la création du rôle SLR. Si elle se reproduit, vous ou votre administrateur de compte devrez peut-être accorder l'autorisation `iam:GetRole` à ACM, ou associer votre compte à la stratégie `AWSCertificateManagerFullAccess` gérée par ACM.
Pour de plus amples informations, veuillez consulter [Autorisations de rôles liés à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) dans le * Guide de l'utilisateur IAM*