As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Solucionar outros problemas Esta seção inclui orientações para problemas não relacionados à emissão ou à validação de certificados do ACM. **Topics** + [Problemas da autorização da autoridade de certificação (CAA)](troubleshooting-caa.md) + [Problemas de importação do certificado](troubleshoot-import.md) + [Problemas de fixação do certificado](troubleshooting-pinning.md) + [Problemas do API Gateway](troubleshoot-apigateway.md) + [O que fazer quando um certificado de trabalho falha inesperadamente](unexpected-failure.md) + [Problemas com a função vinculada ao serviço (SLR) do ACM](slr-problems.md) # Problemas da autorização da autoridade de certificação (CAA) Você pode usar registros do DNS da CAA para especificar que a autoridade de certificação (CA) da Amazon pode emitir certificados do ACM para seu domínio ou subdomínio. Se você receber um erro durante a emissão do certificado que diz **ne or more domain names have failed validation due to a Certification Authority Authorization (CAA) error** (Falha de validação em um ou mais nomes de domínio devido a um erro de autenticação da autoridade de certificação (CAA), verifique os registros DNS da CAA. Se receber esse erro depois que a solicitação de certificado do ACM foi validada com êxito, você deverá atualizar seus registros de CAA e solicitar um certificado novamente. O campo **value** (valor) em seu registro de CAA precisa conter um dos seguintes nomes de domínio: + amazon.com + amazontrust.com + awstrust.com + amazonaws.com Para obter mais informações sobre a criação de um registro de CAA, consulte [(Opcional) Configurar um registro de CAA](setup.md#setup-caa). **nota** Você pode optar por não configurar um registro de CAA para seu domínio se não quiser habilitar a verificação de CAA. # Problemas de importação do certificado Você pode importar certificados de terceiros para o ACM e associá-los aos [serviços integrados](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html). Se você encontrar problemas, revise os [pré-requisitos](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate-prerequisites.html) e os tópicos de [formato do certificado](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate-format.html). Observe principalmente o seguinte: + Você pode importar somente certificados X.509 versão 3 SSL/TLS . + O certificado pode ser autoassinado ou pode ser assinado por uma autoridade de certificação (CA). + Se o certificado for assinado por uma CA, você deverá incluir uma cadeia de certificados intermediária que forneça um caminho para a raiz da autoridade. + Se o certificado for autoassinado, você deverá incluir a chave privada como texto sem formatação. + Cada certificado na cadeia deve certificar diretamente o certificado anterior. + Não inclua o certificado de entidade final na cadeia de certificados intermediária. + Seu certificado, a cadeia de certificados e a chave privada (se houver) devem ser codificados em PEM. Em geral, a codificação PEM consiste em blocos de texto ASCII codificado na Base64 que começam e terminam com linhas de cabeçalho e rodapé de texto simples. Você não deve adicionar linhas ou espaços nem fazer quaisquer outras alterações em um arquivo PEM durante a cópia ou o upload do mesmo. Você pode verificar cadeias de certificados usando o [utilitário de verificação OpenSSL](https://www.openssl.org/docs/manmaster/man1/openssl-verify.html). + A chave privada (se houver) não deve estar criptografada. (Dica: se tiver uma senha, ela é criptografada.) + Os serviços [integrados](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html) com o ACM devem usar tamanhos de chave e algoritmos suportados pelo ACM. Consulte o Guia AWS Certificate Manager do usuário e a documentação de cada serviço para garantir que seu certificado funcione. + O suporte aos certificados dos serviços integrados pode ser diferente dependendo de o certificado ser importado para o IAM ou para o ACM. + O certificado deve estar válido quando ele é importado. + As informações detalhadas sobre todos os seus certificados são exibidas no console. Por padrão, no entanto, se você chamar a [ListCertificates](https://docs.aws.amazon.com/acm/latest/APIReference/API_ListCertificates.html)API ou o AWS CLI comando [list-certificates](https://docs.aws.amazon.com/cli/latest/reference/acm/list-certificates.html) sem especificar o `keyTypes` filtro, somente os `RSA_2048` certificados `RSA_1024` ou certificados serão exibidos. # Problemas de fixação do certificado Para renovar um certificado, o ACM gera um novo par de chaves pública/privada. Se seu aplicativo usa[Fixação do certificado](acm-bestpractices.md#best-practices-pinning), às vezes conhecido como fixação SSL, para fixar um certificado ACM, talvez o aplicativo não consiga se conectar ao seu domínio depois de AWS renovar o certificado. Por esse motivo, recomendamos que você não fixe um certificado do ACM. Se o seu aplicativo precisa fazer fixação de um certificado, você pode fazer o seguinte: + [Importe o seu próprio certificado para o ACM](import-certificate.md) e, em seguida, fixe seu aplicativo no certificado importado. O ACM não fornece renovação gerenciada para certificados importados. + Se você estiver usando um certificado público, fixe o aplicativo a todos os [certificados raiz da Amazon](https://www.amazontrust.com/repository/) disponíveis. Se você estiver usando um certificado privado, fixe o aplicativo ao certificado raiz da CA. # Problemas do API Gateway Quando você implanta um endpoint de API *otimizado para borda*, o API Gateway configura uma CloudFront distribuição para você. A CloudFront distribuição é de propriedade do API Gateway, não da sua conta. A distribuição é vinculada ao certificado do ACM que você usou ao implantar a API. Para remover o vínculo e permitir que o ACM exclua o certificado, você deve remover o domínio personalizado do API Gateway que está associado ao certificado. Ao implantar um endpoint de uma API *regional*, o API Gateway cria um Application Load Balancer (ALB) em seu nome. O balanceador de carga é de propriedade do API Gateway e não é visível a você. O ALB é vinculado ao certificado do ACM que você usou ao implantar a API. Para remover o vínculo e permitir que o ACM exclua o certificado, você deve remover o domínio personalizado do API Gateway que está associado ao certificado. # O que fazer quando um certificado de trabalho falha inesperadamente Se você tiver associado com êxito um certificado do ACM a um serviço integrado, mas o certificado parar de funcionar e o serviço integrado começar a retornar erros, a causa pode ser uma alteração nas permissões de que o serviço precisa para usar um certificado do ACM. Por exemplo, o Elastic Load Balancing (ELB) exige permissão para descriptografar e AWS KMS key isso, por sua vez, decifra a chave privada do certificado. Essa permissão é concedida por uma política baseada em recursos que o ACM aplica quando você associa um certificado ao ELB. Se o ELB perder a concessão para essa permissão, ele falhará a próxima vez que tentar descriptografar a chave do certificado. Para investigar o problema, verifique o status de suas concessões usando o AWS KMS console em[https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms). Depois faça uma das seguintes ações: + Se você acredita que as permissões concedidas a um serviço integrado foram revogadas, visite o console do serviço integrado, desassocie o certificado do serviço e associe-o novamente. Isto reaplicará a política baseada nos recursos e criará uma nova concessão. + Se você acredita que as permissões concedidas ao ACM foram revogadas, entre Suporte em contato em https://console.aws.amazon.com/support/ home\$1/. # Problemas com a função vinculada ao serviço (SLR) do ACM [Quando você emite um certificado assinado por uma CA privada que foi compartilhada com você por outra conta, o ACM tenta primeiro configurar uma função vinculada ao serviço (SLR) para interagir como principal com uma CA privada da AWS política de acesso baseada em recursos.](https://docs.aws.amazon.com/privateca/latest/userguide/pca-resource-sharing.html#pca-rbp) Se você emitir um certificado privado de uma autoridade de certificação compartilhada e o SLR não estiver em vigor, o ACM não poderá renovar automaticamente esse certificado para você. O ACM pode alertar você de que não é possível determinar se existe uma SLR na sua conta. Se a necessária permissão do `iam:GetRole` já foi concedida à SLR do ACM para sua conta, o alerta não será repetido depois que a SLR for criada. Se ele ocorrer novamente, você ou o administrador da conta podem precisar conceder a permissão `iam:GetRole` ao ACM ou associar sua conta à política `AWSCertificateManagerFullAccess` gerenciada pelo ACM. Para saber mais, consulte [Permissões de Função Vinculadas ao Serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) no *Guia do Usuário do IAM*.