Kann ich mit LetsEncrypt Public-Key-Pins verwenden?

Kann ich Public-Key-Pins einrichten, wenn ich einen Cronjob einrichte, um das LetsEncrypt-Zertifikat alle 30 Tage zu erneuern?

Wenn das Zertifikat erneuert wird, wird auch der Public-Key-Pin erneuert, oder?

Einige vorsichtige Worte:

• Wissen Sie, was Sie tun, wenn Sie HPKP implementieren möchten.
• Wenn Sie es nicht richtig machen oder "wenn schlimme Dinge passieren", die nicht unter Ihrer Kontrolle stehen, können Sie Ihre Domain unbrauchbar machen.
• Testen Sie Ihr Setup unbedingt mit einer Domain, die nicht so wichtig ist, oder mit einer sehr kurzen Cache-Zeit, z. B. zehn Sekunden.
• Überlegen Sie, welche Zertifikate Sie anheften möchten: Wurzel, Zwischenstufe, Blatt ...
• Überlegen Sie, ob es sinnvoll ist, eine andere (Sicherungs-) Zertifizierungsstelle, Zwischenzertifikate und Ihr Blattzertifikat anzuheften.
• Besser sicher als leid: Überlegen Sie, ob es sinnvoll ist, eine andere Sicherungszertifizierungsstelle / ein anderes Sicherungszertifikat anzuheften, um zwei zu haben.
• Wenn diese Punkte und Fragen für Sie "neu" klingen: Lesen Sie, worum es bei HPKP geht und welche allgemeinen Fallen und Einschränkungen auftreten, bevor Sie dies implementieren.

Kann ich mit LetsEncrypt Public-Key-Pins verwenden?

• Ja.

Wenn das Zertifikat erneuert wird, wird auch der Public-Key-Pin erneuert, oder?

• Dies hängt davon ab, auf welches Zertifikat Sie sich beziehen und welche Zertifikate Sie anheften.

Würde alles wiederholen, was gf_ gesagt hat.

Um die Frage zu beantworten, können Sie dies jedoch tun.

Standardmäßig erstellt Let's Encrypt den Schlüssel und das Zertifikat bei der Erneuerung neu. Dies erschwert die Implementierung von HPKP, wenn Sie das Blatt anheften möchten, was Sie wahrscheinlich bei Zwischenänderungen tun sollten ( wie im März 2016 ).

Sie haben also mehrere Möglichkeiten, wenn Sie HPKP noch ausführen möchten:

1. Verwenden Sie Ihre eigene feste CSR anstelle des Standardclients, der die CSR jedes Mal für Sie erstellt, damit sich der Blattschlüssel nicht ändert. In diesem Blogbeitrag wird speziell erklärt, wie dies gemacht wird, da der Autor HPKP verwendet.
2. Verwenden Sie kurze HPKP-Ablaufzeiten und verlängern Sie diese innerhalb dieser Ablaufzeit. Ändern Sie die Richtlinie, um sowohl alte als auch neue Schlüssel zu erhalten, bevor Sie das Zertifikat tatsächlich ändern. So bleibt genügend Zeit, damit neue Richtlinien von Besuchern abgerufen werden können.
3. Pin das Let's Encrypt-Stammverzeichnis anstelle des Blattes oder Zertifikats.

Ich habe dies gerade mit dem dehydrierten Client mit dns01-Validierung implementiert. Der dns01-Hook ist certzure, da unser DNS in Azure gehostet wird.

Bearbeiten: Wenn ich über private Schlüssel spreche, meine ich natürlich immer, dass Sie nur die öffentlichen Schlüsselteile in Pins verwandeln. Die privaten Schlüssel sollten, wie der Name schon sagt, immer privat bleiben. Einzelheiten zur Implementierung finden Sie in meinem eigenen Hook.

Sie benötigen einen Rollover für private Schlüssel, um dies zu ermöglichen. Das heißt, Sie haben immer den aktuellen privaten Schlüssel (nennen Sie es A) und den zukünftigen privaten Schlüssel (nennen Sie es B) zur Hand, so dass Sie beide zu Ihren Pins hinzufügen können. An diesem Punkt sind Ihre Pins also A und B. Wenn der Tag der Zertifikatserneuerung kommt, wird der private Schlüssel A veraltet und B wird aktiv. Gleichzeitig erhalten Sie einen neuen zukünftigen privaten Schlüssel, nennen Sie ihn C. Sie generieren Ihre PIN-Liste neu, sodass sie jetzt B und C enthält. So rollen Sie Ihre privaten Schlüssel um. dehydriert unterstützt dies jetzt .

Außerdem benötigen Sie einen Hook, der jedes Mal aufgerufen wird, wenn Sie Ihre Zertifikate erneuern und somit Ihre privaten Schlüssel rollen. Ich implementiert diese auf meinem eigenen .

Wenn ich das richtig verstehe, müssen Sie Folgendes sicherstellen:

HPKP age x 2 < days between cert renewals

Wenn Ihr HPKP-Alter beispielsweise 50 Tage beträgt und Sie alle 30 Tage Zertifikate erneuern, bleibt ein Kunde, der Ihre Site am ersten Tag besucht hat, mit den privaten Schlüsseln A und B hängen, und Sie werden am 31. Tag zu B und C gewechselt Server hat B und C, der Client hat A und B, es gibt sogar am Tag 50 eine Übereinstimmung und der Client öffnet die Site korrekt.

ABER mal sehen, ob das HPKP-Alter 70 Tage beträgt. Sie erneuern die Zertifikate alle 30 Tage, und der Kunde hat Ihre Site am ersten Tag besucht. Sie verfügt also wiederum nur über die privaten Schlüssel A und B. Sie haben am 31. Tag zu B und C und am 61. Tag zu C und D gewechselt Ihr Server hat C und D, der Client hat A und B, es gibt keine Übereinstimmung und der Client erhält den Mittelfinger von Tag 61 bis Tag 71, wenn seine HPKP-Richtlinie abläuft.

Eine andere, wahrscheinlich sicherere und sicherlich viel einfachere Option besteht darin, jedes Mal denselben privaten Schlüssel zu verwenden und einen oder mehrere private Sicherungsschlüssel zu generieren, diese dann in Ihre HPKP-Konfiguration fest zu codieren und damit fertig zu sein.

Ja, es ist schwierig und es könnte Vorbehalte geben, an die ich nicht gedacht habe, aber wir werden es auf lange Sicht sehen. Offensichtlich habe ich es auf einer unkritischen Subdomain mit einem kurzen HPKP-Alter (15 Tage) bereitgestellt, damit es keine großen Probleme verursacht.

Bearbeiten: Ich habe einige Skripte geschrieben, die Ihnen beim Einrichten von HPKP mit Let's Encrypt helfen und mit Nginx dehydriert werden sollen:

HPKPinx