Czy mogę używać pinów klucza publicznego z LetsEncrypt?

Czy mogę skonfigurować szpilki z kluczem publicznym, gdy konfiguruję cronjob, aby odnawiać certyfikat LetsEncrypt co 30 dni?

Jeśli certyfikat zostanie odnowiony, odnawia się również klucz publiczny, prawda?

Kilka słów ostrożności na początek:

• Wiedz, co robisz, jeśli planujesz wdrożyć HPKP.
• Jeśli nie zrobisz tego dobrze lub „jeśli zdarzy się coś złego”, na co nie masz wpływu, możesz uniemożliwić korzystanie z domeny.
• Należy przetestować konfigurację w domenie, która nie jest tak ważna, lub w bardzo krótkim czasie buforowania, na przykład dziesięć sekund.
• Zastanów się, które certyfikaty chcesz przypiąć: root, średni, liść ...
• Zastanów się, czy sensowne jest przypięcie innego (zapasowego) ośrodka certyfikacji, certyfikatów pośrednich i certyfikatu typu liść.
• Bezpieczniej niż przykro: zastanów się, czy sensowne jest przypięcie kolejnego zapasowego urzędu certyfikacji / certyfikatu, aby mieć dwa.
• Jeśli te punkty i pytania brzmią dla ciebie „nowe”: przeczytaj, o co chodzi w HPKP oraz typowe pułapki i zastrzeżenia, zanim to zaimplementujesz.

Czy mogę używać pinów klucza publicznego z LetsEncrypt?

• Tak.

Jeśli certyfikat zostanie odnowiony, odnawia się również klucz publiczny, prawda?

• Zależy to od tego, do którego certyfikatu się odwołujesz i które certyfikaty przypinasz.

Powtórzyłby wszystko, co powiedział gf_.

Jednak, aby odpowiedzieć na pytanie, tak, możesz.

Domyślnie Let's Encrypt odtwarza klucz i certyfikat przy odnawianiu. Utrudnia to wdrożenie HPKP, jeśli chcesz przypiąć liść, co prawdopodobnie powinieneś zrobić w przypadku pośrednich zmian ( tak jak miało to miejsce w marcu 2016 r .).

Masz więc kilka opcji, jeśli nadal chcesz robić HPKP:

1. Użyj własnego ustalonego CSR zamiast standardowego klienta, który tworzy CSR za każdym razem, aby klucz liścia nie zmienił się. Ten post na blogu wyjaśnia, jak to zrobić, ponieważ autor korzysta z HPKP.
2. Użyj krótkich okresów ważności HPKP i odnów w tym czasie wygaśnięcia oraz zmień zasady, aby mieć zarówno stare, jak i nowe klucze przed faktyczną zmianą certyfikatu, z wystarczającą ilością czasu na przyjęcie nowych zasad przez wszystkich odwiedzających.
3. Przypnij korzeń Let's Encrypt zamiast liścia lub certyfikatu.

Właśnie zaimplementowałem to za pomocą odwodnionego klienta z walidacją dns01. Hak dns01 jest certyfikowany, ponieważ nasz DNS jest hostowany na platformie Azure.

Edycja: kiedy mówię o kluczach prywatnych, oczywiście zawsze mam na myśli, że zamieniasz tylko części klucza publicznego w szpilki. Klucze prywatne, jak sama nazwa wskazuje, powinny zawsze pozostać prywatne. Zobacz mój własny hak, aby uzyskać szczegóły dotyczące implementacji.

Aby to umożliwić, potrzebujesz rolowania klucza prywatnego. Oznacza to, że zawsze masz pod ręką aktualny klucz prywatny (nazywaj go A) i przyszły klucz prywatny (nazywaj go B), abyś mógł dodać oba klucze do swoich pinów. W tym momencie twoje szpilki to A i B. Kiedy nadejdzie dzień odnowienia certyfikatu, klucz prywatny A staje się przestarzały, a B zaczyna działać. W tym samym czasie otrzymujesz nowy przyszły klucz prywatny, nazywaj go C. Regenerujesz listę pinów, aby zawierała teraz B i C. W ten sposób przewracasz klucze prywatne. odwodnione obsługuje to teraz .

Potrzebny jest także hak, który jest wywoływany przy każdym odnawianiu certyfikatów, a tym samym do przewracania kluczy prywatnych. Zaimplementowałem to sam .

Wreszcie, jeśli dobrze to zrozumiem, musisz upewnić się, że:

HPKP age x 2 < days between cert renewals

Na przykład, jeśli Twój wiek HPKP wynosi 50 dni, a odnawiasz certyfikaty co 30 dni, klient, który odwiedził Twoją witrynę w pierwszym dniu, utknie z kluczami prywatnymi A i B, a ty przejdziesz do B i C w dniu 31. Twój serwer ma B i C, klient ma A i B, mecz jest nawet w dniu 50, a klient poprawnie otwiera stronę.

ALE zobaczmy, czy wiek HPKP wynosi 70 dni. Odnawiasz certyfikaty co 30 dni, a klient odwiedził Twoją witrynę pierwszego dnia, więc znowu ma tylko klucze prywatne A i B. Przeniesiono do B i C w dniu 31, a przeniesiono do C i D w dniu 61 Twój serwer ma C i D, klient ma A i B, nie ma zgodności, a klient otrzymuje środkowy palec od 61 do 71 dnia, kiedy wygasną jego zasady HPKP.

Inną, prawdopodobnie bezpieczniejszą i na pewno znacznie prostszą opcją jest użycie tego samego klucza prywatnego za każdym razem i wygenerowanie jednego lub kilku zapasowych kluczy prywatnych, a następnie zakodowanie ich na stałe w konfiguracji HPKP i gotowe.

Tak, to trudne i mogą istnieć zastrzeżenia, o których nie myślałem, ale zobaczymy na dłuższą metę. Oczywiście wdrożyłem go w bezkrytycznej subdomenie z krótkim (15 dni) wiekiem HPKP, aby nie powodował wielkich problemów.

Edycja: Napisałem kilka skryptów, które pomogą ci skonfigurować HPKP z Let's Encrypt i odwodnić za pomocą Nginx:

HPKPinx