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à.
ACMcaratteristiche del certificato
I certificati pubblici forniti da ACM hanno le caratteristiche descritte in questa pagina .
Nota
Queste caratteristiche si applicano solo ai certificati forniti daACM. Potrebbero non essere applicabili ai certificati in cui si importano ACM.
-
I certificati pubblici tramite cui richiedi ACM sono ottenuti da Amazon Trust Services
, un'autorità di certificazione pubblica (CA) gestita da Amazon. Amazon Root da CAs 1 a 4 utilizza la firma incrociata di una vecchia radice denominata Starfield G2 Root Certificate Authority - G2. Starfield root è considerato affidabile sui dispositivi Android a partire dalle versioni successive di Gingerbread e da iOS a partire dalla versione 4.1. Le root di Amazon sono considerate affidabili da iOS a partire dalla versione 11. Qualsiasi browser, applicazione o sistema operativo che includa le radici di Amazon o Starfield si fiderà dei certificati pubblici ottenuti daACM. I certificati leaf o end-entity ACM emessi ai clienti derivano la loro autorità da una CA principale di Amazon Trust Services tramite uno qualsiasi dei numerosi intermediari. CAs ACMassegna casualmente una CA intermedia in base al tipo di certificato (o) richiesto. RSA ECDSA Poiché la CA intermedia viene selezionata casualmente dopo la generazione della richiesta, ACM non fornisce informazioni sulla CA intermedia.
- Attendibilità browser e applicazione
-
ACMi certificati sono considerati affidabili da tutti i principali browser, tra cui Google Chrome, Microsoft Internet Explorer e Microsoft Edge, Mozilla Firefox e Apple Safari. I browser che considerano attendibili ACM i certificati visualizzano un'icona a forma di lucchetto nella barra di stato o nella barra degli indirizzi quando sono connessi tramiteSSL/TLSa siti che utilizzano ACM certificati. ACMi certificati sono considerati affidabili anche da Java.
- Rotazione CA intermedia e root
-
Per mantenere un'infrastruttura di certificati resiliente e agile, Amazon può in qualsiasi momento scegliere di interrompere la fornitura di una CA intermedia senza preavviso. Modifiche di questo tipo non hanno alcun impatto sui clienti. Per ulteriori informazioni, consulta il post di blog “Amazon introduce autorità di certificazione intermedie dinamiche
”. Nell'improbabile caso in cui Amazon interrompa la fornitura di una CA root, la modifica avverrà con la rapidità necessaria alle circostanze. A causa del grande impatto di tale cambiamento, Amazon utilizzerà tutti i meccanismi disponibili per avvisare AWS i clienti, tra cui l' AWS Health Dashboard e-mail ai proprietari degli account e il contatto con i responsabili tecnici degli account.
- Accesso al firewall per la revoca
-
Se un certificato end-entity non è più affidabile, verrà revocato. OCSPe CRLs sono i meccanismi standard utilizzati per verificare se un certificato è stato revocato o meno. OCSPe CRLs sono i meccanismi standard utilizzati per pubblicare le informazioni sulla revoca. Alcuni firewall dei clienti potrebbero richiedere regole aggiuntive per consentire il funzionamento di questi meccanismi.
I seguenti modelli di caratteri URL jolly possono essere utilizzati per identificare il traffico di revoca. Un asterisco (*) rappresenta uno o più caratteri alfanumerici, un punto interrogativo (?) rappresenta un singolo carattere alfanumerico e un cancelletto (#) rappresenta un numero.
-
OCSP
http://ocsp.?????.amazontrust.com
http://ocsp.*.amazontrust.com
-
CRL
http://crl.?????.amazontrust.com/?????.crl
http://crl.*.amazontrust.com/*.crl
-
- Convalida del dominio (DV)
-
I certificati ACM sono convalidati dal dominio. Cioè, il campo oggetto di un ACM certificato identifica un nome di dominio e nient'altro. Quando richiedi un ACM certificato, devi confermare di possedere o controllare tutti i domini specificati nella richiesta. Puoi convalidare la proprietà utilizzando l'e-mail o. DNS Per ulteriori informazioni, consulta Convalida e-mail e DNSconvalida.
- Periodo di validità
-
Il periodo di validità dei ACM certificati è di 13 mesi (395 giorni).
- Distribuzione e rinnovo gestito
-
ACMgestisce il processo di rinnovo dei ACM certificati e il rifornimento dei certificati dopo il loro rinnovo. Il rinnovo automatico consente di evitare tempi di inattività causati da certificati non configurati in modo corretto, revocati o scaduti. Per ulteriori informazioni, consulta Rinnovo gestito per ACM i certificati.
- Nomi di dominio multipli
-
Ogni ACM certificato deve includere almeno un nome di dominio completo (FQDN) ed è possibile aggiungere altri nomi se lo si desidera. Ad esempio, quando crei un ACM certificato per
www.example.com
, puoi anche aggiungere il nomewww.example.net
se i clienti possono raggiungere il tuo sito utilizzando uno dei due nomi. Ciò vale anche per domini essenziali (noti anche come apex di zona o domini nudi). Cioè, puoi richiedere un ACM certificato per www.example.com e aggiungere il nome example.com. Per ulteriori informazioni, consulta Richiesta di un certificato pubblico. - Nomi jolly
-
ACMconsente di utilizzare un asterisco (*) nel nome di dominio per creare un ACM certificato contenente un nome jolly in grado di proteggere diversi siti nello stesso dominio. Ad esempio,
*.example.com
proteggewww.example.com
eimages.example.com
.Nota
Quando si fa richiesta di un certificato jolly, l'asterisco (
*
) deve essere nella posizione più a sinistra nel nome di dominio e può proteggere solo un livello di sottodominio. Ad esempio,*.example.com
può proteggerelogin.example.com
etest.example.com
, ma non può proteggeretest.login.example.com
. Si noti inoltre come*.example.com
protegga solo i sottodomini diexample.com
e non il dominio essenziale o apex (example.com
). Ad ogni modo, è possibile richiedere un certificato che protegga un dominio essenziale o apex e i relativi sottodomini specificando nomi di dominio multipli nella richiesta. Ad esempio, è possibile richiedere un certificato che proteggaexample.com
e*.example.com
. - Algoritmi chiave
-
Un certificato deve specificare un algoritmo e la dimensione della chiave di accesso. Attualmente, i seguenti algoritmi a chiave pubblica RSA e Elliptic Curve Digital Signature Algorithm (ECDSA) sono supportati da. ACM ACMpuò richiedere l'emissione di nuovi certificati utilizzando algoritmi contrassegnati da un asterisco (*). Gli algoritmi rimanenti sono supportati solo per i certificati importati.
Nota
Quando si richiede un PKI certificato privato firmato da una CA di AWS Private CA, la famiglia (RSAoECDSA) di algoritmi di firma specificata deve corrispondere alla famiglia di algoritmi della chiave segreta della CA.
-
RSA1024 bit ()
RSA_1024
-
RSA2048 bit (*)
RSA_2048
-
RSA3072 bit ()
RSA_3072
-
RSA4096 bit ()
RSA_4096
-
ECDSA256 bit (*
EC_prime256v1
) -
ECDSA384 bit (*
EC_secp384r1
) -
ECDSA521 bit ()
EC_secp521r1
ECDSAle chiavi sono più piccole e offrono una sicurezza paragonabile a quella RSA delle chiavi ma con una maggiore efficienza di elaborazione. Tuttavia, non ECDSA è supportato da tutti i client di rete. La tabella seguente, adattata da NIST
, mostra il livello di sicurezza rappresentativo di RSA e ECDSA con chiavi di varie dimensioni. Tutti i valori sono in bit. Confronto della sicurezza per algoritmi e chiaviForza di sicurezza
RSAdimensione della chiave
ECDSAdimensione della chiave
128
3072 256 192
7680 384 256
15360 521 La forza di sicurezza, intesa come potenza di 2, è correlata al numero di tentativi necessari per violare la crittografia. Ad esempio, sia una chiave a 3072 bit che una RSA chiave a 256 bit ECDSA possono essere recuperate con non più di 2.128 ipotesi.
Importante
Si noti come i servizi integrati permettano solo agli algoritmi e alle dimensioni della chiave di accesso supportati di essere associati alle loro risorse. Inoltre, il loro supporto varia a seconda che il certificato venga importato IAM o meno. ACM Per ulteriori informazioni, consultare la documentazione di ogni servizio.
-
Per Elastic Load Balancing, consulta HTTPSListeners for Your Application Load Balancer.
-
Per CloudFront, consulta SSLTLSSupporti/Protocolli e cifrari.
-
- Punycode
-
I seguenti requisiti Punycode
relativi a Nomi di dominio internazionalizzati devono essere soddisfatti: -
I nomi di dominio che iniziano con il modello "<character><character>--" devono corrispondere a "xn--".
-
Anche i nomi di dominio che iniziano con "xn--" devono essere nomi di dominio internazionalizzati validi.
Esempi di punycodeNome dominio
Soddisfa #1
Soddisfa #2
Consentito
Nota
esempio.com
N/A
n/a
✓
Non inizia con "<character><character>--"
a--esempio.com
N/A
n/a
✓
Non inizia con "<character><character>--"
abc—esempio.com
N/A
n/a
✓
Non inizia con "<character><character>--"
xn—xyz.com
Sì
Sì
✓
Nome di dominio internazionalizzato valido (si risolve su 简.com)
xn--esempio.com
Sì
No
✗
Nome di dominio internazionalizzato non valido
ab--esempio.com
No
No
✗
Deve iniziare con "xn--"
-
- Eccezioni
-
Tieni presente quanto segue:
-
ACMnon fornisce certificati di convalida estesa (EV) o certificati di convalida dell'organizzazione (OV).
-
ACMnon fornisce certificati per qualcosa di diverso dai protocolli SSL TLS /.
-
Non è possibile utilizzare ACM certificati per la crittografia delle e-mail.
-
ACMattualmente non consente di disattivare il rinnovo gestito dei ACM certificati per i certificati. Inoltre, il rinnovo gestito non è disponibile per i certificati in cui importiACM.
-
Non è possibile richiedere certificati per nomi di dominio appartenenti a Amazon, ad esempio quelli che finiscono con such amazonaws.com, cloudfront.net o elasticbeanstalk.com.
-
Non è possibile scaricare la chiave privata per un ACM certificato.
-
Non puoi installare direttamente ACM i certificati sul tuo sito Web o applicazione Amazon Elastic Compute Cloud (AmazonEC2). È possibile comunque utilizzare il proprio certificato con qualsivoglia servizio integrato. Per ulteriori informazioni, consulta Servizi integrati con AWS Certificate Manager.
-