Sostituisci i certificati simultaneamente su server remoti?

1

Un server di terze parti ci invia messaggi firmati che verifichiamo. Quando il suo certificato sta per scadere, la terza parte genera una nuova coppia di chiavi e ci invia il nuovo certificato.

A un certo punto, il server inizierà a firmare con la sua nuova chiave, richiedendo che usiamo il nuovo certificato corrispondente da verificare.

Come possiamo rendere questo processo di sostituzione su due lati preciso e facile? Sarebbe una seccatura se qualche messaggio venisse rifiutato a causa di problemi di temporizzazione (ad esempio, gli switch di tipo A, quindi un messaggio viene inviato, quindi gli switch di parte B).

Una soluzione ovvia potrebbe essere quella di provare tutte le chiavi non scadute, ma sembra l'inquinamento del codice. In particolare perché affrontiamo questa sfida solo in alcuni scenari, il che significa che alcuni casi di verifica della firma devono preoccuparsi di più certificati, mentre altri no.

Un'altra idea è specificare un timestamp. Tuttavia, gli orologi dei server potrebbero non essere sincronizzati e le cache di memoria (ad esempio con una scadenza di 15 minuti) interferirebbero ancora di più.

    
posta Timo 27.06.2016 - 11:38
fonte

2 risposte

1

How can we make this two-side replacement process accurate and easy?

Il modo convenzionale per farlo è supportare più certificati nel lato di verifica. Il lato del verificatore dovrebbe installare i nuovi certificati, che dovrebbero funzionare fianco a fianco. Il firmatario può quindi passare al nuovo certificato al momento della scelta prima della scadenza del vecchio certificato.

Si noti che nella maggior parte dei casi d'uso di crittografia asimmetrica, il verificatore in genere avrebbe comunque bisogno del supporto di più certificati, poiché il verificatore potrebbe dover verificare i vecchi messaggi utilizzando certificati scaduti. In questi casi, l'utente deve essere informato che la verifica ha esito positivo con un certificato scaduto.

Se davvero non è possibile supportare più certificati, è necessario un tempo di inattività sincronizzato . Innanzitutto, il firmatario viene rimosso e svuota tutti i messaggi non inviati; quindi, dopo che il verificatore ha terminato l'elaborazione di tutti i messaggi in sospeso, il verificatore viene rimosso. Dopo che entrambi gli assistenti hanno aggiornato i loro certificati, i servizi possono essere ripristinati. Se il firmatario è in grado di mettere in coda i messaggi non inviati per essere rispediti più tardi, il firmatario può ripristinare il servizio in qualsiasi momento dopo che il verificatore è stato confermato inattivo; altrimenti il firmatario ha dovuto aspettare che il verificatore fosse attivo prima di iniziare.

Se davvero non puoi tollerare i tempi di inattività ogni volta che il certificato scade, allora quello che potresti fare è usare una verifica della catena di certificati. In questo schema, dovresti creare un certificato radice di lunga durata (ad esempio 10 anni o più), che viene utilizzato per certificare certificati foglia a vita breve (ad esempio sei mesi, annuale); il verificatore accetta i certificati ancorati al certificato di origine. Dovresti comunque sincronizzare i tempi di inattività per sostituire un certificato di origine, ma la sostituzione dei certificati foglia non dovrebbe essere sincronizzata. Avresti però bisogno di proteggere molto il tuo certificato di root, perché questo certificato di root è difficile da sostituire se compromesso.

    
risposta data 25.10.2016 - 17:21
fonte
0

Puoi risolvere questo problema utilizzando strumenti di distribuzione come Chef o Ansible.

In particolare su Chef, hai Chef Push per inviare qualsiasi libro di cucina (ad esempio i file chiave) a tutti i nodi (cioè i server).

    
risposta data 27.06.2016 - 11:43
fonte

Leggi altre domande sui tag