SSL cert minimizza la strategia di rotazione delle chiavi di downtime

Si presuppone in modo errato: un certificato non deve essere revocato quando viene rilasciato nuovamente. In genere è un processo completamente diverso. Ciò significa che dovresti aggiungere un ultimo passaggio al tuo piano: revocare il vecchio certificato una volta terminato con l'installazione di quello nuovo.

I client non memorizzeranno nella cache il tuo certificato. Infatti, non possono conservare una copia memorizzata nella cache poiché è il tuo server che sta inviando il certificato come parte dell'handshake SSL. Potrebbero mantenere una copia del CRL nella cache per tutto il tempo in cui è valida, ma ciò dovrebbe avere un impatto molto limitato sulla sicurezza e nessuno sulla disponibilità.

Infine, non è necessario riavviare i server, è sufficiente riavviare il processo / i servizi utilizzando i certificati. Provocherebbe comunque il blocco delle connessioni esistenti, ma dovrebbe essere molto più veloce del riavvio dell'intero server.

Supponiamo, per un istante, che tu abbia davvero bisogno di "ridigitare i tuoi server Web" a causa di un bug insopportabile (se c'è una tale necessità, allora hai anche logicamente bisogno di farlo per ogni altra vulnerabilità simile che si presenta, quindi più volte all'anno, e devi farlo anche per le vulnerabilità che mostreranno , quindi, con questo ragionamento, anche la tua nuova chiave verrà immediatamente tostata). Supponiamo inoltre che la re-keying sia sufficiente (di nuovo, un errore: se un utente malintenzionato potrebbe ottenere la tua chiave privata, quindi potrebbe anche ottenere tutti i tuoi dati riservati, quindi il problema ha uno scopo molto più ampio).

In base a questi presupposti, il modello è quello di un compromesso delle tue chiavi private (è questo che temi). Devi fare due cose:

1. Dichiara il vecchio certificato come non valido, in modo che i client cessino di considerarlo affidabile. Questo è noto come revoca .

2. Ottieni un nuovo certificato con una nuova chiave di cui l'utente malintenzionato non sa.

Non c'è alcuna necessità concettuale di fare le cose in quell'ordine. In realtà, di solito vuoi che il nuovo certificato sia attivo e in esecuzione prima il vecchio viene revocato. Succede che alcuni CA insistono sul vincolare le due operazioni insieme, cioè revocando il vecchio certificato e rilasciando il nuovo contemporaneamente (una ragione per farlo è commerciale: hai pagato uno certificato, quindi dovresti ottenere un certificato non revocato in qualsiasi momento).

Fortunatamente, alcune caratteristiche ti aiuteranno:

• I client eseguono i certificati di cache non . Nel protocollo SSL / TLS , il server invia sistematicamente il suo certificato corrente e il client lo utilizzerà sempre, non un versione cache.

• La revoca è asincrona: quando un certificato viene revocato, il suo numero di serie sarà incluso nella lista di revoche di certificati pubblicata regolarmente dalla CA. Di solito, occorrono alcune ore prima che la revoca sia effettiva (dipende dalla politica della CA). Inoltre, i client fanno cache CRL, quindi, anche se un nuovo CRL viene immediatamente pubblicato dalla CA, i client che hanno collegato alcune ore fa continueranno a funzionare su quello precedente, fino alla scadenza. (OCSP può ridurre la finestra temporale, però.)

• Molti client non si preoccupano di controllare CRL in ogni caso, quindi, dal loro punto di vista, il vecchio certificato non verrà mai revocato.

È ancora nel tuo interesse completare la procedura rapidamente, ad esempio entro pochi minuti. Ad ogni modo, DEVI essere in grado di farlo correttamente, perché i certificati scadono: lo stai facendo presto (per un senso di deferenza rispetto all'attuale ondata di paranoia male informata).