Чи можна використовувати шпильки відкритого ключа з LetsEncrypt?

Чи можу я встановити відкриті ключі, коли я встановлюю cronjob для поновлення сертифіката LetsEncrypt кожні 30 днів?

Якщо сертифікат буде поновлено, то відкритий ключ-ключ також поновлюється, чи не так?

Деякі обережні слова для початку:

• Знайте, що ви робите, якщо плануєте впровадити HPKP.
• Якщо ви не зробите це правильно, або "якщо трапляються погані речі", які не знаходяться під вашим контролем, ви можете зробити свій домен непридатним.
• Не забудьте протестувати налаштування з доменом, який не так важливий, або з дуже коротким часом кешу, наприклад, десять секунд.
• Подумайте, які серти ви хотіли б прикріпити: кореневі, проміжні, листові ...
• Подумайте, чи є сенс закріпити інший (резервний) сертифікат, це проміжні сертифікати та ваш листовий сертифікат.
• Краще безпечно, ніж вибачте: подумайте, чи є сенс зафіксувати ще одну резервну копію CA / cert, щоб мати дві.
• Якщо ці пункти і питання звучать для вас "новими": перед тим , як це втілити, прочитайте, що стосується HPKP та загальні пастки та застереження .

Чи можна використовувати шпильки відкритого ключа з LetsEncrypt?

• Так.

Якщо сертифікат буде поновлено, то відкритий ключ-ключ також поновлюється, чи не так?

• Це залежить від того, на який сертифікат ви посилаєтесь і на який сертифікат (-ла), який ви закріплюєте.

Було б перегукуватися з усім, що сказав gf_.

Однак відповісти на питання, так можна.

За замовчуванням давайте шифрувати відтворює ключ та cert при поновленні. Це ускладнює реалізацію HPKP, якщо ви хочете зафіксувати листок, що, мабуть, слід зробити у випадку проміжних змін ( як це було в березні 2016 року ).

Тож у вас є кілька варіантів цього, якщо ви все ще хочете зробити HPKP:

1. Використовуйте власний фіксований КСВ, а не стандартного клієнта, який створює КСВ для вас кожен раз, щоб клавіша аркуша не змінювалася. У цьому дописі в блозі пояснено, як це зробити конкретно, оскільки автор використовує HPKP.
2. Використовуйте короткі терміни дії HPKP та поновлюйте їх протягом цього терміну та змініть політику, щоб мати як старі, так і нові ключі до того, як фактично змінити сертифікат, з достатньою кількістю часу для того, щоб нові політики могли підібрати будь-які відвідувачі.
3. Закріпіть корінь Let’s Encrypt замість листа або cert.

Я щойно реалізував це за допомогою зневодненого клієнта з dns01 валідацією. Гак dns01 є каналом, тому що наш DNS розміщується в Azure.

Редагувати: коли я говорю про приватні ключі, я, звичайно, завжди маю на увазі, що ви лише перетворюєте частини відкритого ключа на шпильки. Приватні ключі, як випливає з назви, завжди повинні залишатися приватними. Перегляньте мій власний гачок, щоб отримати детальну інформацію про впровадження

Вам потрібен перехід приватного ключа, щоб зробити це можливим. Тобто у вас завжди є під рукою поточний приватний ключ (називайте його A) та майбутній приватний ключ (називайте його B), щоб ви могли додати їх як до своїх шпильок. Тож у цей момент ваші шпильки - це A і B. Коли настає день оновлення cert, приватний ключ A стає застарілим, а B стає активним. Одночасно ви отримуєте новий майбутній приватний ключ, називаєте його C. Ви регенеруєте свій список контактів, щоб він містив B і C. Отже, так ви перевертаєте свої приватні ключі. зневоднене підтримує це зараз .

Крім того, вам потрібен гачок, який викликається щоразу, коли ви поновлюєте сертифікати і таким чином перевертаєте ваші приватні ключі. Я реалізував це самостійно .

Нарешті, якщо я зрозумію це право, ви повинні переконатися, що:

HPKP age x 2 < days between cert renewals

Наприклад, якщо ваш вік HPKP становить 50 днів, і ви поновлюєте сертифікати кожні 30 днів, клієнт, який відвідував ваш сайт в перший день, буде застрягнути приватними ключами A і B, і ви перейдете на B і C в день 31. сервер має B і C, у клієнта A і B, є відповідність навіть на 50 день і клієнт відкриває сайт правильно.

Але давайте подивимось, чи вік HPKP становить 70 днів. Ви поновлюєте сертифікати кожні 30 днів, і клієнт відвідував ваш веб-сайт в перший день, тому, знову ж таки, у нього є лише приватні ключі A і B. Ви переходили на B і C в день 31, і переходили на C і D в день 61 . На вашому сервері є C і D, у клієнта A і B, немає відповідності, і клієнт отримує середній палець від 61-го до 71-го дня, коли його політика HPKP закінчується.

Інший, напевно, більш безпечний і, звичайно, набагато простіший варіант - використання одного і того ж приватного ключа кожен раз і генерування одного або декількох резервних приватних ключів, а потім жорстке кодування їх у конфігурацію HPKP і робити це з ним.

Так, це складно, і можуть бути застереження, про які я не думав, але ми побачимося з часом. Очевидно, я розмістив його на некритичному субдомені з коротким (15-денним) віком HPKP, щоб він не спричинив великих проблем.

Редагувати: Я написав кілька сценаріїв, щоб допомогти вам налаштувати HPKP за допомогою програми "Шифрувати та зневоднювати" за допомогою Nginx:

HPKPinx