Posso usare pin chiave pubblica con LetsEncrypt?

Posso impostare Pin chiave pubblica quando installo un cronjob per rinnovare il certificato LetsEncrypt ogni 30 giorni?

Se il certificato viene rinnovato, anche il PIN chiave pubblica viene rinnovato, giusto?

Alcune parole di cautela per cominciare:

• Scopri cosa stai facendo, se hai intenzione di implementare HPKP.
• Se non lo fai nel modo giusto o "se accadono cose brutte", che non sono sotto il tuo controllo, potresti rendere inutilizzabile il tuo dominio.
• Assicurati di testare la tua configurazione con un dominio che non è così importante o con un tempo di cache molto breve, ad esempio dieci secondi.
• Pensa a quali certificati vuoi appuntare: radice, intermedio, foglia ...
• Pensa se ha senso bloccare un'altra autorità di certificazione (backup), i certificati intermedi e il certificato foglia.
• Meglio prevenire che curare: pensa se ha senso bloccare un altro CA / certificato di backup, per averne due.
• Se questi punti e domande ti sembrano "nuovi": leggi di cosa tratta HPKP e le trappole e le avvertenze comuni, prima di implementarlo.

Posso usare pin chiave pubblica con LetsEncrypt?

• Sì.

Se il certificato viene rinnovato, anche il PIN chiave pubblica viene rinnovato, giusto?

• Questo dipende dal certificato a cui ti riferisci e da quali certificati stai bloccando.

Farebbe eco a tutto ciò che GF_ ha detto.

Tuttavia, per rispondere alla domanda, sì, è possibile.

Per impostazione predefinita Let's Encrypt ricrea la chiave e il certificato al rinnovo. Ciò rende difficile l'implementazione di HPKP se si desidera bloccare la foglia, cosa che probabilmente si dovrebbe fare in caso di modifiche intermedie ( come nel marzo 2016 ).

Quindi hai diverse opzioni a riguardo se vuoi ancora fare HPKP:

1. Usa il tuo CSR fisso anziché il client standard che crea il CSR per te ogni volta in modo che la chiave foglia non cambi. Questo post sul blog spiega come farlo specificatamente perché l'autore utilizza HPKP.
2. Usa brevi scadenze HPKP e rinnova entro tale termine e modifica la politica per avere le chiavi vecchie e nuove prima di modificare effettivamente il certificato, con il tempo sufficiente affinché i nuovi criteri vengano rilevati da tutti i visitatori.
3. Pin la radice Let's Encrypt invece della foglia o del certificato.

Ho appena implementato questo usando il client disidratato con validazione dns01. L'hook dns01 è sicuro perché il nostro DNS è ospitato in Azure.

Modifica: quando parlo di chiavi private, ovviamente intendo sempre che trasformi solo le parti della chiave pubblica in pin. Le chiavi private, come suggerisce il nome, dovrebbero sempre rimanere private. Vedi il mio gancio per i dettagli di implementazione.

È necessario il rollover della chiave privata per renderlo possibile. Cioè, hai sempre la chiave privata corrente (chiamala A) e la chiave privata futura (chiamala B) a portata di mano, in modo da poterle aggiungere entrambe ai tuoi pin. Quindi a questo punto i pin sono A e B. Quando arriva il giorno del rinnovo della certificazione, la chiave privata A diventa obsoleta e B diventa attiva. Allo stesso tempo ottieni una nuova chiave privata futura, chiamala C. Rigenera la tua lista pin quindi ora contiene B e C. Quindi è così che arrotoli le tue chiavi private. disidratato supporta questo ora .

Inoltre, hai bisogno di un hook che viene chiamato ogni volta che rinnovi i certificati e quindi arrotoli le tue chiavi private. L'ho implementato da solo .

Infine, se ho capito bene, devi assicurarti che:

HPKP age x 2 < days between cert renewals

Ad esempio, se la tua età HPKP è di 50 giorni e rinnovi i certificati ogni 30 giorni, un cliente che ha visitato il tuo sito il primo giorno sarà bloccato con le chiavi private A e B e passerai a B e C al giorno 31. Il tuo il server ha B e C, il client ha A e B, c'è una corrispondenza anche il giorno 50 e il client apre correttamente il sito.

Ma vediamo se l'età di HPKP è di 70 giorni. Rinnovi i certificati ogni 30 giorni e il cliente ha visitato il tuo sito il primo giorno, quindi di nuovo ha solo le chiavi private A e B. Sei passato a B e C al giorno 31 e passato a C e D al giorno 61 Il tuo server ha C e D, il client ha A e B, non c'è corrispondenza e al client viene assegnato il dito medio dal giorno 61 al giorno 71, quando scade la sua politica HPKP.

Un'altra opzione, probabilmente più sicura e sicuramente molto più semplice, è quella di utilizzare sempre la stessa chiave privata e generare una o più chiavi private di backup, quindi codificarle nella configurazione HPKP e procedere con essa.

Sì, è difficile e potrebbero esserci avvertimenti a cui non ho pensato, ma vedremo a lungo termine. Ovviamente l'ho distribuito su un sottodominio non critico con una breve HPKP (15 giorni) in modo che non causasse grossi problemi.

Modifica: ho scritto alcuni script per aiutarti a configurare HPKP con Let's Encrypt e disidratato usando Nginx:

HPKPinx