Sostituzione di un certificato TLS quando il vecchio è bloccato (HPKP)

Question

Sostituzione di un certificato TLS quando il vecchio è bloccato (HPKP)

#1 da (3 voti)
#2 da (0 voti)

1

Supponiamo che la mia età massima per la chiave pubblica sia di 60 giorni. Quando posso distribuire un nuovo certificato? 60 giorni da oggi? Ma per quanto riguarda i browser che si connettono per la prima volta al mio sito tra oggi e tra 60 giorni?

Questo sito dice :

When GitHub [who uses HPKP] wants to replace its TLS certificate, the new certificate must be signed by either DigiCert or Symantec – otherwise, none of the key hashes in the new certificate chain would match the existing HPKP policy, and its users would be blocked from accessing the site.

Quindi, non posso distribuire un nuovo certificato firmato da una CA diversa (ad esempio, Let's Encrypt's) rispetto a quello di quello che ho originariamente bloccato (ad esempio, Verisign)?

Questo è il motivo per cui si consiglia di fissare un certificato di backup da un'altra CA?
^{cf. p. 315 di Ivan Ristić SSL Bulletproof e TLS (2014)}

apache webserver tls letsencrypt hpkp

posta Geremia 13.10.2016 - 17:29

fonte

2 risposte

0

Quello che devi fare è aggiungere un hash SHA-256 del nuovo certificato e catena, oltre a quelli già presenti. Quindi, in 60 giorni, puoi rimuovere gli hash SHA-256 dei vecchi certificati.

risposta data 13.10.2016 - 18:15

fonte

Leggi altre domande sui tag apache webserver tls letsencrypt hpkp

Il framework BeEF funziona ancora per le versioni più recenti dei browser? Come comunicare la mia connessione HTTPS a un sito utilizza PFS?

score 3 · Accepted Answer

Dovresti SEMPRE avere due (o più) pin nelle intestazioni: una per il certificato corrente e una (o più) per i certificati di backup (tenuta separatamente da quella corrente, la migliore offline).
Se il tuo attuale certificato non è stato compromesso, non è necessario toccare i pin o emettere un nuovo certificato - puoi semplicemente rinnovare il certificato esistente (chiedi a CA di emettere nuovi CRT usando lo stesso CSR di prima).
Se il tuo sistema è stato compromesso, puoi passare al certificato di backup che hai bloccato (per almeno la massima età) QUALSIASI MOMENTO - UA lo accetterà, perché il pin è valido (era precedentemente presente nelle intestazioni).
Puoi chiedere a qualsiasi CA che è considerata affidabile dal client per firmare il tuo CSR (corrente o backup).
Se si desidera aggiungere un nuovo pin, è necessario attendere il periodo di validità massima (in genere 60 giorni) prima di utilizzare il certificato corrispondente, per eliminare il rischio che UA respinga la connessione. Vedi lo scenario sotto e nota le differenze tra i client X e Y:
- giorno 1: configuri pin A + crt A, imposta max-age a 60 giorni,
- giorno 2: il client X si connette e impara che A è sicuro per 60 giorni,
- giorno 3: il cliente Y si connette e impara che A è sicuro per 60 giorni,
- giorno 20: aggiungi il pin B alle intestazioni,
- giorno 21: il client X si connette (si fida di A) e apprende che sia A che B sono sicuri per 60 giorni,
- giorno 40: si passa a crt B,
- giorno 41: il client X si connette (si fida sia di A che di B),
- giorno 42: il client Y rifiuta la connessione - non è riuscito a imparare il nuovo pin da A attendibile (come il client X ha fatto), quindi rifiuterà tutto tranne A fino al giorno 63.

Se sei ancora in dubbio, consulta la sezione 2.6. Convalida delle connessioni appuntate e Appendice B. Guida alla distribuzione in RFC 7469 .