

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Risolvi altri problemi
<a name="misc-problems"></a>

In questa sezione vengono fornite indicazioni per i problemi non correlati al rilascio o alla convalida dei certificati ACM.

**Topics**
+ [Problemi di autorizzazione per Certification Authority (CAA)](troubleshooting-caa.md)
+ [Problemi di importazione dei certificazione](troubleshoot-import.md)
+ [Problemi di associazione dei certificati](troubleshooting-pinning.md)
+ [Problemi con API Gateway](troubleshoot-apigateway.md)
+ [Cosa fare quando un certificato smette di funzionare in modo imprevisto](unexpected-failure.md)
+ [Problemi con il ruolo collegato al servizio ACM](slr-problems.md)

# Problemi di autorizzazione per Certification Authority (CAA)
<a name="troubleshooting-caa"></a>

È possibile utilizzare record DNS di tipo CAA per specificare che l'autorità di certificazione (CA) di Amazon può emettere certificati ACM per il dominio e per il sottodominio. Se si riceve un messaggio di errore durante l'emissione di certificati che avvisa che **uno o più nomi di dominio non sono stati convalidati a causa di un errore relativo all'Autenticazione dell'autorità di certificazione (CAA)**, verificare i record CAA del DNS. Se si riceve questo errore dopo che la richiesta del certificato ACM è stata convalidata correttamente, sarà necessario aggiornare i registri CAA e richiedere nuovamente un certificato. Il campo **valore** deve contenere uno dei seguenti nomi di dominio in nel record CAA:
+ amazon.com
+ amazontrust.com
+ awstrust.com
+ amazonaws.com

Per ulteriori informazioni relative alla creazione di record CAA, consultare [(Opzionale) Configurazione di un registro CAA](setup.md#setup-caa).

**Nota**  
Puoi scegliere di non configurare un record CAA per il dominio se non vuoi consentire il controllo CAA.

# Problemi di importazione dei certificazione
<a name="troubleshoot-import"></a>

Puoi importare certificati di terze parti in ACM e associarli ai [servizi integrati](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html). In caso di problemi, consulta gli argomenti correlati ai [prerequisiti](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate-prerequisites.html) e [al formato dei certificati](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate-format.html). In particolare, tieni presente quanto segue: 
+ È possibile importare solo certificati X.509 versione 3. SSL/TLS 
+ Il certificato può essere autofirmato oppure può essere firmato da un'autorità di certificazione (CA). 
+ Se il certificato è firmato da una CA, devi includere una catena di certificati intermedia che fornisce un percorso alla radice dell'autorità. 
+ Se il certificato è autofirmato, devi includere la chiave privata in testo normale.
+ Ogni certificato nella catena deve certificare direttamente quello precedente. 
+ Non includere il certificato dell'entità finale nella catena di certificati intermedia.
+ I tuoi certificati, la catena di certificati e la chiave privata devono essere codificati con PEM. In generale, la codifica PEM è costituita da blocchi di testo ASCII codificati Base64 che iniziano e terminano con header e footer di testo normale. Non è necessario aggiungere righe o spazi o apportare altre modifiche a un file PEM durante la copia o il caricamento. È possibile verificare le catene di certificati utilizzando l'[utility di verifica OpenSSL](https://www.openssl.org/docs/manmaster/man1/openssl-verify.html).
+ La chiave privata (se presente) non deve essere crittografata. (Suggerimento: se ha una passphrase, è crittografata.)
+ I servizi [integrati](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html) con ACM devono utilizzare algoritmi e dimensioni delle chiavi supportati da ACM-supported. Consulta la Guida per l' AWS Certificate Manager utente e la documentazione di ciascun servizio per assicurarti che il certificato funzioni. 
+ Il supporto del certificato da parte dei servizi integrati può variare a seconda se il certificato è importato in IAM o in ACM. 
+ Il certificato deve essere valido quando viene importato. 
+ Le informazioni dettagliate per tutti i tuoi certificati sono visualizzate nella console. Per impostazione predefinita, tuttavia, se richiami l'[ListCertificates](https://docs.aws.amazon.com/acm/latest/APIReference/API_ListCertificates.html)API o il AWS CLI comando [list-certificates](https://docs.aws.amazon.com/cli/latest/reference/acm/list-certificates.html) senza specificare il `keyTypes` filtro, vengono visualizzati solo `RSA_1024` o `RSA_2048` i certificati. 

# Problemi di associazione dei certificati
<a name="troubleshooting-pinning"></a>

Per rinnovare un certificato, ACM genera una nuova coppia di chiavi di accesso pubblica-privata. Se l'applicazione utilizza[Associazione dei certificati](acm-bestpractices.md#best-practices-pinning), a volte noto come pinning SSL, per bloccare un certificato ACM, l'applicazione potrebbe non essere in grado di connettersi al dominio dopo il rinnovo del certificato. AWS Per questo motivo, ti consigliamo di non associare un certificato ACM. Se la tua applicazione deve associare un certificato, puoi eseguire quanto indicato di seguito:
+ [Importa il tuo certificato su ACM](import-certificate.md), quindi associa l'applicazione al certificato importato. ACM non fornisce il rinnovo gestito per i certificati importati.
+ Se stai utilizzando un certificato pubblico, aggiungi la tua applicazione a tutti i [ certificati root Amazon](https://www.amazontrust.com/repository/) disponibili. Se stai utilizzando un certificato privato, aggiungi la tua applicazione a un certificato root CA.

# Problemi con API Gateway
<a name="troubleshoot-apigateway"></a>

Quando distribuisci un endpoint API *ottimizzato per l'edge, API Gateway* imposta CloudFront una distribuzione per te. La CloudFront distribuzione è di proprietà di API Gateway, non del tuo account. La distribuzione è associata al certificato ACM utilizzato per la distribuzione dell'API. Per rimuovere l'associazione e permettere ad ACM di eliminare il certificato, devi rimuovere il dominio personalizzato API Gateway associato al certificato. 

Quando implementi un endpoint API *regionale*, API Gateway crea un Application Load Balancer (ALB) a tuo nome. Il load balancer è di proprietà di API Gateway e non è visibile a te. L'ALB è associato al certificato ACM utilizzato per la distribuzione dell'API. Per rimuovere l'associazione e permettere ad ACM di eliminare il certificato, devi rimuovere il dominio personalizzato API Gateway associato al certificato. 

# Cosa fare quando un certificato smette di funzionare in modo imprevisto
<a name="unexpected-failure"></a>

Se un certificato ACM è stato associato correttamente a un servizio integrato ma il certificato smette di funzionare e il servizio integrato inizia a restituire errori, la causa potrebbe essere una modifica delle autorizzazioni necessarie al servizio per utilizzare un certificato ACM. 

Ad esempio, Elastic Load Balancing (ELB) richiede l'autorizzazione per decrittografare e, a sua volta, decripta la chiave privata del certificato. AWS KMS key Questa autorizzazione viene concessa da una policy basata sulle risorse che ACM applica quando si associa un certificato a ELB. Se ELB perde la concessione per tale autorizzazione, non riuscirà al successivo tentativo a decrittare la chiave del certificato.

Per esaminare il problema, controlla lo stato delle tue sovvenzioni utilizzando la console all'indirizzo. AWS KMS [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms) Esegui una delle seguenti azioni:
+ Se ritieni che le autorizzazioni concesse a un servizio integrato siano state revocate, visita la console del servizio integrato, dissocia il certificato dal servizio, quindi associalo nuovamente. In questo modo sarà riapplicata la policy basata sulle risorse e sarà concessa una nuova autorizzazione.
+ Se ritieni che le autorizzazioni concesse ad ACM siano state revocate, contatta at home\$1/. Supporto https://console.aws.amazon.com/support/

# Problemi con il ruolo collegato al servizio ACM
<a name="slr-problems"></a>

[Quando emetti un certificato firmato da una CA privata che è stato condiviso con te da un altro account, ACM tenta al primo utilizzo di impostare un ruolo collegato al servizio (SLR) per interagire come principale con una politica di accesso basata sulle risorse. CA privata AWS](https://docs.aws.amazon.com/privateca/latest/userguide/pca-resource-sharing.html#pca-rbp) Se rilasci un certificato privato da una CA condivisa e l'SLR non è disponibile, ACM non sarà in grado di rinnovare automaticamente tale certificato.

ACM potrebbe avvisarti che non è in grado di determinare se esiste un SLR sul tuo account. Se l'autorizzazione `iam:GetRole` richiesta è già stata concessa ad ACM SLR per il tuo account, l'avviso non si ripeterà dopo la creazione del SLR. In caso di ripetizione, l'utente o l'amministratore dell'account potrebbe essere necessario concedere l'autorizzazione `iam:GetRole` ad ACM o associare il proprio account con il `AWSCertificateManagerFullAccess` della policy gestito da ACM.

Per ulteriori informazioni, consulta [Autorizzazioni del ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) nella *Guida per l'utente di IAM*.