Preparazione alla creazione di certificati privati

Pianificazione della struttura di una gerarchia CA

Come best practice, pianificare una gerarchia di autorità certificate che corrisponde alla struttura della tua organizzazione. In genere, è possibile implementare una delle seguenti strutture CA comuni.

Due livelli: Root CA e CA subordinata

Utilizzare questa opzione se il carico di lavoro richiede la struttura CA più semplice. In questo scenario si crea una singola CA root attendibile. Poi, si crea una CA subordinata, ad esempio una CA intermedia, per emettere certificati di foglia alle vostre app e servizi.

Tre livelli: CA principale e due autorità di certificazione subordinate

Utilizzare questa opzione se il carico di lavoro richiede uno strato aggiuntivo tra le operazioni CA di root e di livello inferiore. In questo scenario, la CA subordinata intermedia viene utilizzata solo per firmare le Autorità di certificazione subordinate che rilasciano i certificati leaf alle applicazioni.

Impostazione della profondità della gerarchia CA

Quando si crea un'autorità di certificazione in Secrets Manager, è possibile impostare il parametro Lunghezza massima del percorso per determinare quanti certificati CA possono esistere nella sua catena di autorità. Questo valore enfatizza quanti certificati CA possono esistere nel percorso di certificazione della tua CA.

In generale, è possibile configurare una CA radice che non limiti il numero di Autorità di certificazione subordinate che può creare nel suo percorso di certificazione. Tuttavia, la definizione di una lunghezza massima del percorso per le Autorità di certificazione subordinate è un'importante misura di sicurezza per evitare che le Autorità di certificazione siano configurate in modo errato. A seconda del posizionamento di una CA subordinata nella tua gerarchia, assicurati di specificare una lunghezza di percorso massima in modo che la sua potenza di firma sia limitata solo alla profondità prevista.

La lunghezza massima del percorso che si definisce non include i certificati a foglia. Nell'esempio precedente, la CA subordinata nel livello 4 può emettere certificati foglia ma non è in grado di avere più certificati CA nel suo percorso.

Scelta di un periodo di validità per i tuoi certificati

Il periodo di validità di un certificato X.509 è un campo obbligatorio che determina quanto tempo il certificato è attendibile e rimane valido. Quando si pianifica la gerarchia CA, si lavora all'indietro rispetto alla durata di vita preferita per i certificati di foglia che si desidera rilasciare alle proprie applicazioni. Poi, determinare il periodo di validità dei certificati CA.

Un certificato deve avere un periodo di validità più breve o uguale al periodo di validità per la CA che lo ha rilasciato. Ad esempio, se si crea una CA radice con un time-to-live (TTL) di 10 anni, tutte le Autorità di certificazione intermedie ad essa subordinate devono avere un TTL uguale o inferiore a 10 anni. Allo stesso modo, se una CA intermedia ha TTL di 3 anni, qualsiasi certificato di foglia deve avere un TTL pari o inferiore a 3 anni.

1. Scegli un periodo di validità per i tuoi certificati a foglia adatto al tuo caso d'uso.

   I certificati privati che è possibile creare con Secrets Manager sono considerati certificati di foglia che possono essere rilasciati a un'entità di fine, come ad esempio un'app client o server. Con Secrets Managerè possibile creare certificati con un periodo di validità massimo di tre anni o 36 mesi. Dopo aver stabilito un periodo TTL o validità per i certificati di foglia, si imposta il valore utilizzando un modello di certificato in modo che venga applicato il TTL preferito ogni volta che viene generato un nuovo certificato di foglia.

   Più corto è il TTL dei tuoi certificati a foglia, più ti protetti contro l'esposizione involontaria o il compromesso del tuo certificato e della sua chiave privata. Un periodo di validità più breve per i vostri certificati significa che si riduce la probabilità di compromesso, ma richiede anche di ruotare più frequentemente il certificato per assicurarsi che rimanga valido. Per evitare un interruzione involontaria, è possibile pianificare rotazione automatica dei propri certificati privati.

2. Scegli un periodo di validità per la CA subordinata.

   Come best practice, impostare un periodo di validità per un certificato CA subordinato che sia significativamente superiore ai periodi di validità dei certificati che rilasciano. Definire un periodo di validità di una CA principale che sia da due a cinque volte il periodo di qualsiasi certificato di tipo CA o certificato di foglia che emette. Ad esempio, se si dispone di una gerarchia CA a due livelli e si desidera emettere certificati a foglia con un TTL di un anno, configurare la CA emittente subordinata con un TTL di tre anni. È sempre possibile aggiornare i certificati CA subordinati senza sostituire il certificato di root CA.

3. Scegli un periodo di validità per la tua CA root.

   Quando si aggiorna un certificato di root CA, la modifica impatta la tua intera infrastruttura a chiave pubblica. Per minimizzare l'impatto, si consiglia di impostare un periodo di validità lungo per il proprio certificato CA root. In Secrets Manager, il TTL predefinito per i certificati di root è di 10 anni.

Scegliere un servizio di gestione delle chiavi

Prima di creare un'autorità di certificazione in Secrets Manager, è necessario scegliere un Key Management Service (KMS) per la generazione delle chiavi pubbliche e private della CA. È possibile scegliere il motore di certificato privato KMS interno, in questo caso le chiavi pubbliche e private della CA sono create nel software e gestite internamente dal servizio. Si può anche scegliere di gestire le chiavi in un modulo di sicurezza hardware (HSM) esterno. Secrets Manager supporta IBM Cloud Hyper Protect Crypto Services (HPCS) per la gestione delle chiavi CA. È possibile configurare una CA per utilizzare le chiavi esistenti in un keystore privato HPCS, oppure consentire a Secrets Manager di creare nuove chiavi per la CA.

Il motore del certificato privato Secrets Manager utilizza l'API PKCS#11 per comunicare con HPCS. L'autenticazione e l'autorizzazione avvengono tramite una chiave API IAM gestita tramite un Secrets Manager segreto delle credenziali IAM. Le operazioni di firma crittografica vengono eseguite nell'HPCS e il materiale della chiave privata della CA non lascia mai il dispositivo crittografico.

Nota: Secrets Manager non controlla i costi o i limiti tariffari associati alla creazione di certificati CA con chiavi in HPCS.

Scelta di un algoritmo per generare chiavi

Prima di creare un'autorità di certificazione in Secrets Manager, è necessario scegliere un algoritmo chiave per la generazione dei tasti pubblici e privati per la vostra CA. La coppia di chiavi pubbliche e private viene utilizzata per autenticare una connessione SSL/TLS. Se non sei sicuro da dove iniziare, puoi utilizzare la seguente guida suggerita per la selezione di un algoritmo chiave.

1. Scegli una famiglia di algoritmi.

   L'algoritmo chiave che si seleziona determina l'algoritmo di codifica e la dimensione chiave da utilizzare per generare chiavi e firmare certificati. Come best practice, utilizzare la stessa famiglia di algoritmi per tutti i certificati che appartengono a una catena di certificati. Secrets Manager supporta le seguenti famiglie di algoritmi.

   Famiglie di algoritmi e dimensioni delle chiavi supportate

   Famiglia di algoritmo	Descrizione	Dimensioni chiave supportate
   RSA	Ampiamente utilizzato e compatibile con la maggior parte dei browser e server, RSA è lo standard di settore per la crittografia a chiave pubblica.	2048 bit 4096 bit
   Curva ellittica (CE)	Genera chiavi più forti e certificati minori. Ad esempio, una chiave EC 256 - bit è equivalente nella forza di crittografia ad una chiave RSA a 3072 - bit.	224 bit 256 bit 384 bit 521 bit

2. Scegli una dimensione chiave.

   La dimensione o la lunghezza chiave che si seleziona determina la forza di codifica. Più grande è la dimensione chiave per una famiglia di algoritmi, più difficile è la rottura. Tieni presente che le lunghezze chiave più lunghe si traduce in più dati da memorizzare e trasmettere, che possono influenzare le prestazioni del tuo certificato. Come best practice, scegliere una dimensione chiave appropriata per il periodo TTL o di validità del tuo certificato.

   Per i certificati di soggiorno più lunghi, si consiglia di utilizzare lunghezze chiave più lunghe per fornire una protezione più crittografica.

Leggi elenco di revoca certificati

Con questo endpoint è possibile recuperare la CRL corrente in forma grezza e codificata DER. Se /pem viene aggiunto all'endpoint, il CRL viene restituito in formato PEM.

GET v1/ibmcloud/private_cert/config/certificate_authorities/:ca-name/crl(/pem)

Response 200 OK
<binary DER-encoded CRL>

Per convalidare che i certificati CA foglia o intermedi non sono revocati dal contesto di un certificato foglia, è possibile configurare la propria CA con la proprietà "crl_distribution_points_encoded": true. Questa configurazione codifica l'indirizzo URL utilizzato per scaricare la CRL della CA emittente nella proprietà X509v3 CRL Distribution Points di ogni certificato della CA intermedia o della foglia. Quindi, il programma di convalida CA può controllare se i certificati CA foglia o intermedi sono revocati.

Leggi certificato CA

Con questo endpoint, è possibile recuperare il certificato CA in formato codificato DER non elaborato. Se /pem viene aggiunto all'endpoint, il certificato CA viene restituito in formato PEM.

GET v1/ibmcloud/private_cert/config/certificate_authorities/:ca-name/ca(/pem)

Response 200 OK
<binary DER-encoded certificate >

Leggi catena di certificati CA

È possibile richiamare con questo endpoint la catena di certificati CA, che include la CA in formato PEM. Questo endpoint è nudo. Non restituisce una struttura di dati Vault standard e la CLI Vault non può leggerla.

GET v1/ibmcloud/private_cert/config/certificate_authorities/:ca-name/ca_chain

Response 200 OK
<PEM-encoded certificate chain>

Per verificare che la catena di CA provenga dal contesto di un certificato foglia, è possibile configurare le autorità di certificazione in Secrets Manager con la proprietà "issuing_certificates_urls_encoded": true. In ogni certificato di CA foglia o intermedia, questa configurazione codifica l'indirizzo URL utilizzato per scaricare il certificato della CA emittente nella proprietà Authority Information Access/CA Issuers. Quindi, il tuo programma di convalida CA può convalidare ogni certificato CA.