

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à.

# Che cos'è CA privata AWS?
<a name="PcaWelcome"></a>

CA privata AWS consente la creazione di gerarchie di autorità di certificazione (CA) private, tra cui root e subordinate CAs, senza i costi di investimento e manutenzione legati alla gestione di una CA locale. Il personale privato CAs può emettere certificati X.509 di entità finale utili in scenari quali:
+ Creazione di canali di comunicazione TLS crittografati 
+ Autenticazione di utenti, computer, endpoint API e dispositivi IoT
+ Codice di firma crittografica
+ Implementazione del protocollo OCSP (Online Certificate Status Protocol) per ottenere lo stato di revoca del certificato

CA privata AWS è possibile accedere alle operazioni da Console di gestione AWS, utilizzando l' CA privata AWS API o utilizzando. AWS CLI

**Topics**
+ [Disponibilità regionale per AWS Autorità di certificazione privata](#PcaRegions)
+ [Servizi integrati con AWS Autorità di certificazione privata](#PcaIntegratedServices)
+ [Algoritmi crittografici supportati in AWS Autorità di certificazione privata](#supported-algorithms)
+ [Conformità a RFC 5280 in AWS Autorità di certificazione privata](#RFC-compliance)
+ [Prezzi per AWS Autorità di certificazione privata](#PcaPricing)
+ [Termini e concetti per AWS Private CA](PcaTerms.md)

## Disponibilità regionale per AWS Autorità di certificazione privata
<a name="PcaRegions"></a>

 

Come la maggior parte AWS delle risorse, le autorità di certificazione private (CAs) sono risorse regionali. Per utilizzare private CAs in più di una regione, devi creare le tue CAs in quelle regioni. Non è possibile copiare dati privati CAs tra regioni. Visita [Regioni ed endpoint AWS](https://docs.aws.amazon.com/general/latest/gr/rande.html#pca_region) in *Riferimenti generali di AWS* o la [Tabella delle regioni AWS](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/) per vedere la disponibilità regionale per CA privata AWS. 

**Nota**  
ACM è attualmente disponibile in alcune regioni, ma non lo CA privata AWS sono.

## Servizi integrati con AWS Autorità di certificazione privata
<a name="PcaIntegratedServices"></a>

Se utilizzi l' AWS Certificate Manager opzione per richiedere un certificato privato, puoi associare tale certificato a qualsiasi servizio integrato con ACM. Questo vale sia per i certificati concatenati a una CA privata AWS radice che per i certificati concatenati a una radice esterna. Per ulteriori informazioni, consulta [Integrated Services nella Guida](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html) per l' AWS Certificate Manager utente. 

Puoi anche CAs integrare private in Amazon Elastic Kubernetes Service per fornire l'emissione di certificati all'interno di un cluster Kubernetes. Per ulteriori informazioni, consulta [Proteggi Kubernetes con AWS Autorità di certificazione privata](PcaKubernetes.md).

**Nota**  
Amazon Elastic Kubernetes Service non è un servizio integrato ACM.

Se utilizzi l' CA privata AWS API o AWS CLI per emettere un certificato o esportare un certificato privato da ACM, puoi installare il certificato ovunque desideri. 

## Algoritmi crittografici supportati in AWS Autorità di certificazione privata
<a name="supported-algorithms"></a>

CA privata AWS supporta i seguenti algoritmi crittografici per la generazione di chiavi private e la firma dei certificati. 


**Algoritmo supportato**  

| Algoritmi a chiave privata | Algoritmi di firma | 
| --- | --- | 
|  ML\$1DSA\$144 ML\$1DSA\$165 ML\$1DSA\$187 RSA\$12048  RSA\$13072  RSA\$14096 EC\$1Prime256v1 EC\$1SECP384R1 EC\$1SECP521R1 SM2 (Solo regioni della Cina)  | ML\$1DSA\$144ML\$1DSA\$165ML\$1DSA\$187 SHA256CON RSASHA384CON RSASHA512CON RSASHA256CON ECDSA SHA384CON ECDSASHA512CON ECDSASM3WITHSM2 | 

Questo elenco si applica solo ai certificati emessi direttamente CA privata AWS dalla console, dall'API o dalla riga di comando. Quando AWS Certificate Manager emette certificati utilizzando un CA da CA privata AWS, supporta alcuni ma non tutti questi algoritmi. Per ulteriori informazioni, consulta [Richiedere un certificato privato](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-private.html) nella Guida per l' AWS Certificate Manager utente.

**Nota**  
Per RSA o ECDSA, la famiglia di algoritmi di firma specificata deve corrispondere alla famiglia di algoritmi di chiave della chiave privata della CA.  
Per ML-DSA, la funzione hash è definita come parte dell'algoritmo stesso. Non è possibile selezionare una funzione hash diversa con ML-DSA. Per mantenere la compatibilità con le versioni precedenti APIs, viene utilizzato lo stesso valore per l'algoritmo chiave e l'algoritmo di firma.

## Conformità a RFC 5280 in AWS Autorità di certificazione privata
<a name="RFC-compliance"></a>

CA privata AWS [non impone determinati vincoli definiti nella RFC 5280.](https://datatracker.ietf.org/doc/html/rfc5280) Anche la situazione inversa è vera: vengono applicati alcuni vincoli aggiuntivi appropriati per una CA privata.

**Applicato**
+ [Non dopo la data](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.5). Conformemente alla [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280), CA privata AWS impedisce il rilascio di certificati recanti una data `Not After` successiva alla data `Not After` del certificato della CA emittente.
+ [Vincoli di base.](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.9) CA privata AWS impone i vincoli di base e la lunghezza del percorso nei certificati CA importati. 

  I vincoli di base indicano se la risorsa identificata dal certificato è una CA e può emettere certificati. I certificati emessi da una CA importati in CA privata AWS devono includere l'estensione dei vincoli di base e l'estensione deve essere contrassegnata con `critical`. Oltre alla `critical` bandiera, `CA=true` deve essere impostata. CA privata AWS impone i vincoli di base fallendo con un'eccezione di convalida per i seguenti motivi:
  + L'estensione non è inclusa nel certificato emesso da una CA.
  + L'estensione non è contrassegnata `critical`.

  La lunghezza del percorso ([pathLenConstraint](PcaTerms.md#terms-pathlength)) determina quanti subordinati CAs possono esistere a valle del certificato CA importato. CA privata AWS impone la lunghezza del percorso fallendo con un'eccezione di convalida per i seguenti motivi:
  + L'importazione di un certificato emesso da una CA violerebbe il vincolo di lunghezza del percorso nel certificato emesso da una CA o in qualsiasi certificato emesso da una CA nella catena.
  + L'emissione di un certificato violerebbe un vincolo di lunghezza del percorso.
+ [I vincoli di nome](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.10) indicano uno spazio dei nomi all'interno del quale devono essere collocati tutti i nomi dei soggetti nei certificati successivi in un percorso di certificazione. Le restrizioni si applicano al nome distinto del soggetto e ai nomi alternativi del soggetto.

**Non applicato**
+ [Politiche relative ai certificati](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.4). Le politiche relative ai certificati regolano le condizioni in base alle quali una CA rilascia i certificati.
+ [Inibisci qualsiasi politica](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.14). Utilizzato nei certificati rilasciati a. CAs
+ [Nome alternativo dell'emittente](https://datatracker.ietf.org/doc/html/rfc5280#section-section-4.2.1.7). Consente di associare identità aggiuntive all'emittente del certificato CA.
+ [Vincoli politici](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.11). Questi vincoli limitano la capacità di una CA di emettere certificati emessi da una CA subordinata.
+ [Mappature delle politiche](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.5). Utilizzato nei certificati CA. Elenca una o più coppie di OIDs; ogni coppia include un issuerDomainPolicy e unsubjectDomainPolicy.
+ [Attributi della directory dei soggetti](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.8). Utilizzato per trasmettere gli attributi identificativi del soggetto.
+ [Accesso alle informazioni sull'argomento](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.2.2). Come accedere alle informazioni e ai servizi relativi all'oggetto del certificato in cui compare l'estensione.
+ [Identificatore chiave soggetto (SKI)](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.2) e [identificatore chiave dell'autorità (AKI)](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.1). La RFC richiede un certificato emesso da una CA per contenere l'estensione SKI. I certificati emessi dalla CA devono contenere un'estensione AKI corrispondente allo SKI del certificato CA. AWS non applica questi requisiti. Se il certificato emesso da una CA non contiene uno SKI, l'AKI del certificato emesso da una CA dell'entità finale o subordinata emesso sarà invece l'hash SHA-1 della chiave pubblica emittente.
+ [SubjectPublicKeyInfo](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1)e [nome alternativo del soggetto (SAN).](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.6) Quando si emette un certificato, CA privata AWS copia le estensioni SubjectPublicKeyInfo e le estensioni SAN dal CSR fornito senza eseguire la convalida.

## Prezzi per AWS Autorità di certificazione privata
<a name="PcaPricing"></a>

Al tuo account viene addebitato un prezzo mensile per ogni CA privata a partire dal momento in cui la crei. Verranno addebitati anche i costi per ogni certificato rilasciato. Questo addebito include i certificati esportati da ACM e i certificati creati dall' CA privata AWS API o dalla CA privata AWS CLI. Non è previsto alcun addebito per una CA privata dopo che è stata eliminata. Tuttavia, se ripristini una CA privata, ti verrà addebitata per l'intervallo di tempo compreso tra l'eliminazione e il ripristino. I certificati privati per i quali non hai accesso alla chiave privata sono gratuiti. Questi includono certificati utilizzati con [Servizi integrati](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html) come Elastic Load Balancing e API CloudFront Gateway. 

Per le informazioni più recenti CA privata AWS sui prezzi, consulta la sezione [AWS Autorità di certificazione privata Prezzi](https://aws.amazon.com/private-ca/pricing/). Puoi anche utilizzare il [calcolatore dei AWS prezzi](https://calculator.aws/#/createCalculator/certificateManager) per stimare i costi. 

# Termini e concetti per AWS Private CA
<a name="PcaTerms"></a>

I seguenti termini e concetti possono aiutarti a lavorare con AWS Autorità di certificazione privata.

**Topics**
+ [Trust](#terms-trust)
+ [Certificati del server TLS](#terms-tlscert)
+ [Firma del certificato](#terms-signing)
+ [Autorità di certificazione](#terms-ca)
+ [CA root](#terms-rootca)
+ [Certificato CA](#terms-ca-cert)
+ [Un certificato emesso da una CA root](#terms-root)
+ [Certificato dell'entità finale](#terms-endentity)
+ [Certificati autofirmati](#terms-selfsignedcert)
+ [Certificato privato](#terms-pca-cert)
+ [Percorso del certificato](#terms-certpath)
+ [Vincolo di lunghezza del percorso](#terms-pathlength)

## Trust
<a name="terms-trust"></a>

Per poter considerare attendibile l'identità di un sito Web, un browser Web deve essere in grado di verificare il certificato di tale sito. I browser, tuttavia, considerano attendibili solo un ristretto numero di certificati noti come certificati root CA. Una terza parte attendibile, nota come autorità di certificazione (CA), convalida l'identità del sito Web ed emette un certificato digitale firmato all'operatore del sito Web. Il browser può quindi verificare la firma digitale per convalidare l'identità del sito Web. Se la convalida riesce, verrà visualizzata un'icona a forma di lucchetto nella barra degli indirizzi.

## Certificati del server TLS
<a name="terms-tlscert"></a>

Le transazioni HTTPS richiedono certificati del server per autenticare un server. Un certificato del server è una struttura di dati X.509 v3 che associa la chiave pubblica nel certificato all'oggetto del certificato. Un certificato TLS è firmato da un'autorità di certificazione (CA). Contiene il nome del server, il periodo di validità, la chiave pubblica, l'algoritmo di firma e altro ancora. 

## Firma del certificato
<a name="terms-signing"></a>

Una firma digitale è un hash crittografato su un certificato. Una firma viene utilizzata per confermare l'integrità dei dati del certificato. La CA privata crea una firma utilizzando una funzione hash crittografica, ad esempio SHA256 sul contenuto del certificato di dimensioni variabili. Questa funzione hash produce una stringa di dati di dimensioni fisse in modo efficace imperdonabile. Questa stringa è chiamata hash. La CA effettua la crittografia del valore hash con la propria chiave privata e concatena gli hash crittografati con il certificato.

## Autorità di certificazione
<a name="terms-ca"></a>

Un'autorità di certificazione (CA) emette e, se necessario, revoca i certificati digitali. Il tipo più comune di certificato si basa sullo standard ISO X.509. Un certificato X.509 conferma l'identità dell'oggetto del certificato e associa tale identità a una chiave pubblica. L'oggetto può essere un utente, un'applicazione, un computer o un altro dispositivo. La CA firma il certificato sottoponendo ad hashing i contenuti e crittografando l'hash con la chiave privata correlata alla chiave pubblica nel certificato. Un'applicazione client, ad esempio un browser Web che deve confermare l'identità di un oggetto, utilizza la chiave pubblica per decrittografare la firma del certificato. Esegue quindi l'hashing dei contenuti del certificato e confronta il valore sottoposto ad hashing con la firma decrittografata per stabilire se corrispondono. Per informazioni sulla firma dei certificati, consulta [Firma del certificato](#terms-signing). 

È possibile utilizzare CA privata AWS per creare una CA privata e utilizzare la CA privata per emettere certificati. La CA privata emette solo SSL/TLS certificati privati da utilizzare all'interno dell'organizzazione. Per ulteriori informazioni, consulta [Certificato privato](#terms-pca-cert). Anche la CA privata richiede un certificato prima che sia possibile utilizzarla. Per ulteriori informazioni, consulta [Certificato CA](#terms-ca-cert). 

## CA root
<a name="terms-rootca"></a>

Una CA root è un elemento costitutivo di crittografia e la root di affidabilità sulla cui base possono essere emessi i certificati. È composta da una chiave privata per sottoscrivere (emettere) certificati e di un certificato root che identifica la CA root e vincola la chiave privata al nome della CA. Il certificato root viene distribuito negli archivi affidabili di ciascuna entità in un ambiente. Gli amministratori creano archivi attendibili per includere solo quelli di cui si CAs fidano. Gli amministratori aggiornano o creano gli archivi attendibili nei sistemi operativi, nelle istanze e nelle immagini delle macchine host delle entità nel proprio ambiente. Quando le risorse tentano di connettersi tra loro, verificano i rispettivi certificati presentati. Un client controlla la validità dei certificati e se esiste una catena dal certificato a un certificato root installato nell'archivio attendibilità. Se tali condizioni sono soddisfatte, viene stabilita una «stretta di mano» tra le risorse. Questo handshake dimostra in modo crittografico l'identità di ciascuna entità rispetto all'altra e crea un canale di comunicazione crittografato (TLS/SSL) tra di loro.

## Certificato CA
<a name="terms-ca-cert"></a>

Un certificato di un'autorità di certificazione (CA) conferma l'identità della CA e la associa alla chiave pubblica contenuta nel certificato. 

È possibile CA privata AWS utilizzarlo per creare una CA root privata o una CA subordinata privata, ciascuna supportata da un certificato CA. I certificati emessi da una CA subordinata sono firmati da un altro certificato emesso da una CA superiore in una catena di attendibilità. Ma nel caso di una CA root, il certificato è firmato automaticamente. È inoltre possibile stabilire un'autorità root esterna (ospitata in locale, ad esempio). È quindi possibile utilizzare l'autorità principale per firmare un certificato emesso da una CA root subordinata ospitata da CA privata AWS.

L'esempio seguente mostra i campi tipici contenuti in un certificato CA privata AWS CA X.509. Si noti che per un certificato CA il valore `CA:` del campo `Basic Constraints` è impostato su `TRUE`. 

```
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 4121 (0x1019)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=Washington, L=Seattle, O=Example Company Root CA, OU=Corp, CN=www.example.com/emailAddress=corp@www.example.com
        Validity
            Not Before: Feb 26 20:27:56 2018 GMT
            Not After : Feb 24 20:27:56 2028 GMT
        Subject: C=US, ST=WA, L=Seattle, O=Examples Company Subordinate CA, OU=Corporate Office, CN=www.example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:c0: ... a3:4a:51
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                F8:84:EE:37:21:F2:5E:0B:6C:40:C2:9D:C6:FE:7E:49:53:67:34:D9
            X509v3 Authority Key Identifier:
                keyid:0D:CE:76:F2:E3:3B:93:2D:36:05:41:41:16:36:C8:82:BC:CB:F8:A0

            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: critical
                Digital Signature, CRL Sign
    Signature Algorithm: sha256WithRSAEncryption
         6:bb:94: ... 80:d8
```

## Un certificato emesso da una CA root
<a name="terms-root"></a>

Un'autorità di certificazione (CA) esiste in genere all'interno di una struttura gerarchica che ne contiene più altre CAs con relazioni padre-figlio chiaramente definite tra di loro. Il figlio o il subordinato CAs sono certificati dal genitore CAs, creando una catena di certificati. La CA al livello più alto della gerarchia è detta CA root e il suo certificato viene denominato certificato root. Questo certificato generalmente è autofirmato. 

## Certificato dell'entità finale
<a name="terms-endentity"></a>

Un certificato di entità finale identifica una risorsa, ad esempio un server, un'istanza, un contenitore o un dispositivo. A differenza dei certificati CA, i certificati di entità finale non possono essere utilizzati per emettere certificati. Altri termini comuni per il certificato di entità finale sono «client» o «leaf». 

## Certificati autofirmati
<a name="terms-selfsignedcert"></a>

Un certificato firmato dall'emittente invece di una CA superiore. A differenza dei certificati emessi dalla root protetta mantenuta da una CA, i certificati autofirmati sono essi stessi la root; di conseguenza presentano limitazioni importanti, perché ad esempio possono essere utilizzati per fornire crittografia in transito ma non per verificare le identità; inoltre, non possono essere revocati. Sono inaccettabili dal punto di vista della sicurezza. Ma le organizzazioni li usano comunque perché sono facili da generare, non richiedono competenze o infrastrutture e molte applicazioni li accettano. Non sono disponibili controlli per l'emissione di certificati autofirmati. Le aziende che li usano vanno incontro a rischi maggiori di interruzioni causate dalla scadenza dei dispositivi, perché non è possibile tenere sotto controllo le date di scadenza.

## Certificato privato
<a name="terms-pca-cert"></a>

CA privata AWS i certificati sono SSL/TLS certificati privati che è possibile utilizzare all'interno dell'organizzazione, ma non sono affidabili sulla rete Internet pubblica. Utilizzarli per identificare le risorse, ad esempio client, server, applicazioni, servizi, dispositivi e utenti. Quando si stabilisce un canale di comunicazione crittografato sicuro, ogni risorsa utilizza un certificato come il seguente e le tecniche crittografiche necessarie per provare la propria identità a un'altra risorsa. Gli endpoint API interni, i server Web, gli utenti VPN, i dispositivi IoT e molte altre applicazioni utilizzano i certificati privati per stabilire canali di comunicazione crittografati necessari per un funzionamento sicuro. Per impostazione predefinita, i certificati privati non sono pubblicamente attendibili. Un amministratore interno deve configurare esplicitamente le applicazioni affinché considerino attendibili i certificati privati e deve distribuire i certificati. 

```
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            e8:cb:d2:be:db:12:23:29:f9:77:06:bc:fe:c9:90:f8
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=WA, L=Seattle, O=Example Company CA, OU=Corporate, CN=www.example.com
        Validity
            Not Before: Feb 26 18:39:57 2018 GMT
            Not After : Feb 26 19:39:57 2019 GMT
        Subject: C=US, ST=Washington, L=Seattle, O=Example Company, OU=Sales, CN=www.example.com/emailAddress=sales@example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00...c7
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Authority Key Identifier:
                keyid:AA:6E:C1:8A:EC:2F:8F:21:BC:BE:80:3D:C5:65:93:79:99:E7:71:65

            X509v3 Subject Key Identifier:
                C6:6B:3C:6F:0A:49:9E:CC:4B:80:B2:8A:AB:81:22:AB:89:A8:DA:19
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://NA/crl/12345678-1234-1234-1234-123456789012.crl

    Signature Algorithm: sha256WithRSAEncryption
         58:32:...:53
```

## Percorso del certificato
<a name="terms-certpath"></a>

Un client che si basa su un certificato convalida l'esistenza di un percorso dal certificato dell'entità finale, possibilmente attraverso una catena di certificati intermedi, a una radice attendibile. Il client verifica che ogni certificato lungo il percorso sia valido (non revocato). Verifica inoltre che il certificato dell'entità finale non sia scaduto, che abbia integrità (non sia stato manomesso o modificato) e che i vincoli del certificato siano applicati.

## Vincolo di lunghezza del percorso
<a name="terms-pathlength"></a>

I vincoli di base *pathLenConstraint*per un certificato CA stabiliscono il numero di certificati CA subordinati che possono esistere nella catena sottostante. Ad esempio, un certificato CA con un vincolo di lunghezza del percorso pari a zero non può avere alcun subordinato. CAs Una CA con un vincolo di lunghezza del percorso pari a uno può contenere fino a un livello di subordinato al di sotto di essa. CAs [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.9) lo definisce come «il numero massimo di certificati non-self-issued intermedi che possono seguire questo certificato in un percorso di certificazione valido». Il valore della lunghezza del percorso esclude il certificato dell'entità finale, sebbene un linguaggio informale sulla «lunghezza» o la «profondità» di una catena di convalida possa includerlo... generando confusione.