Rinnovo certificato root dei Servizi certificati Microsoft

Question

Rinnovo certificato root dei Servizi certificati Microsoft

#1 da (14 voti)

16

Al momento abbiamo Microsoft Enterprise Certificate Server installato su un computer membro del dominio che rilascia certificati di 1 anno agli utenti per l'autenticazione alla VPN.

Desideriamo iniziare a rilasciare certificati server Web dalla nostra CA per proteggere Dell Open Manage (un'applicazione per la gestione dei sistemi) e anche Microsoft RDP. Perché abbiamo un bel po 'di server (100+) e non ho trovato un modo per automatizzare l'installazione dei certificati (nota l'installazione - non la distribuzione - so come distribuire automaticamente) stiamo considerando l'emissione di certificati per tutta la vita del server. La maggior parte dei nostri server viene utilizzata per 10 anni o meno, quindi vorremmo certificati di 10-15 anni.

Come ho capito, CA non può emettere certificati più lunghi di quanto essi stessi siano validi. Pertanto, se volessimo emettere certificati SSL decennali, il nostro certificato CA radice avrebbe bisogno di essere valido almeno per 11 anni ma in pratica probabilmente per 15-20 anni.

Inoltre, comprendo che più lunga è la durata del certificato, più la chiave privata è suscettibile di compromettere e quindi il desiderio di utilizzare una lunghezza della chiave più lunga per certificati più lunghi.

Sto pensando di rinnovare il certificato di root per una durata maggiore, ma ho le seguenti domande:

1) Generare un certificato di root 15-20 anni nelle migliori pratiche? Ancora una volta capisco idealmente che emetteremo certificati per una durata più breve - ma il lavoro manuale necessario per l'installazione di detti certificati ogni anno non è banale, quindi il desiderio di usare una lunghezza maggiore - purché farlo sia ragionevolmente sicuro

2) Dovremmo usare la lunghezza della chiave 4096 per la CA radice o possiamo usare una chiave più breve? Alcune letture che ho fatto suggeriscono che alcuni dispositivi di rete non supporteranno certificati più lunghi di 2048 bit.

3) Quando si rinnova il certificato radice, è possibile riutilizzare la coppia di chiavi esistente o generare una nuova coppia di chiavi. Capisco che la generazione di una nuova coppia di chiavi sia migliore da un punto di vista della sicurezza, ma lo faremo se i certificati emessi esistenti continueranno a funzionare senza la necessità di apportare modifiche?

Grazie
Brad

cryptography public-key-infrastructure certificates certificate-authority

posta Brad 03.04.2011 - 15:12

fonte

1 risposta

Leggi altre domande sui tag cryptography public-key-infrastructure certificates certificate-authority

Il mio computer è a rischio di essere hackerato quando si utilizza il Wi-Fi pubblico? Come posso testare la mia applicazione web per gli attacchi temporali?

score 14 · Answer 1

I certificati root (in senso stretto, " trust anchors ") dovrebbero essere longevi; come si nota, cambiare un certificato di root è costoso perché non deve essere fatto alla leggera: quel certificato concentra l'intera sicurezza dei certificati e per cosa sono utilizzati. Per l'interoperabilità, probabilmente si vogliono mantenere le date di validità inferiori all'anno 2038, perché ci sono alcuni (molti) sistemi là fuori che codificano internamente le date come un conteggio di secondi dal 1 ° gennaio 1970, su un numero intero a 32 bit con segno. In una data specifica dell'anno 2038, il conteggio si avvolgerà, in valori negativi e ne consegue l'ilarità. Questo è l'equivalente binario del bug Y2K. Speriamo , quando raggiungiamo quella data fatidica, la maggior parte delle architetture passeranno a un modello a 64 bit in cui questo problema non si verificherà per molto tempo; o almeno per un conteggio su un intero unsigned a 32 bit, che acquista 68 anni extra. (Y2K è risultato essere piuttosto secondario, quindi non c'è motivo di farsi prendere dal panico.)

Per le chiavi RSA, 2048 bit dovrebbero essere sufficienti per la sicurezza a lungo termine. Questa è, naturalmente, una scommessa sulla tecnologia e la scienza del futuro, quindi non c'è alcuna garanzia. Visita questo sito per un trattamento completo delle lunghezze delle chiavi consigliate. In alternativa, verifica se è possibile utilizzare ECDSA per il certificato radice: quasi tutte le implementazioni ECDSA supportano la curva standard "P-521", che offre "sicurezza a 521 bit", apparentemente equivalente a una chiave RSA di 15360 bit (o così via) ( cioè nessuna preoccupazione per molto tempo).

Se il nuovo certificato di base utilizza la stessa chiave e lo stesso nome, corrisponderà ai certificati emessi in precedenza e le cose andranno bene. Se cambi la chiave e / o il nome, dovrai emettere nuovi certificati. Probabilmente, se si utilizzano certificati CA intermedi, solo quelli dovranno essere riemessi. Il modo "normale" di gestire un rollover della chiave di root è definire la nuova root, inserirla in tutti i dispositivi di verifica senza rimuovendo la vecchia root; dopo alcuni anni, quando tutti i certificati relativi alla vecchia radice sono scaduti, puoi rimuoverli dai sistemi di verifica.

Naturalmente, la ragione principale per cui si vorrebbe cambiare la radice è che si crede che la chiave sia stata utilizzata troppo a lungo; riutilizzare la stessa chiave sconfigge lo scopo. Si noti che la radice è, per sua natura, unica: c'è una chiave privata di cui preoccuparsi, situata in un unico punto, normalmente un HSM (Hardware Security Module) resistente alla manomissione. Il punto di tale HSM è che la chiave non può essere rubata senza che tu te ne accorga. Quindi, se usi una chiave abbastanza grande per iniziare, non dovrai cambiare la chiave - o, se lo fai, allora devi farlo urgentemente . A quel punto, le date di validità della radice sono moot: se la chiave radice viene rubata, si desidera che la nuova chiave venga distribuita ora (almeno alla fine della settimana), non entro i prossimi tre anni. Quindi, la "pratica corrente" è quella di creare una radice di lunga durata con una grande chiave e di impostare la radice di validità di alcuni anni oltre la data di pensionamento prevista (in modo che questo sia il problema di qualcun altro).