Могу ли я использовать Public-Key-Pins с LetsEncrypt?

Могу ли я настроить Public-Key-Pins при установке cronjob для обновления сертификата LetsEncrypt каждые 30 дней?

Если сертификат продлен, то Public-Key-Pin также обновляется, верно?

Несколько слов предостережения для начала:

• Знайте, что вы делаете, если планируете внедрять HPKP.
• Если вы сделаете это неправильно или «если случится что-то плохое», которое не находится под вашим контролем, вы можете сделать свой домен непригодным для использования.
• Обязательно протестируйте настройки с доменом, который не так важен, или с очень коротким временем кэширования, например, десять секунд.
• Подумайте, какие сертификаты вы хотели бы прикрепить: корневые, промежуточные, листовые ...
• Подумайте, имеет ли смысл закреплять другой (резервный) центр сертификации, это промежуточные сертификаты и ваш листовой сертификат.
• Лучше безопасно, чем потом сожалеть: подумайте, есть ли смысл прикрепить другой резервный CA / cert, чтобы иметь два.
• Если эти вопросы и вопросы кажутся вам «новыми»: прочитайте, что такое HPKP, а также распространенные ловушки и предостережения, прежде чем приступить к реализации.

Могу ли я использовать Public-Key-Pins с LetsEncrypt?

• Да.

Если сертификат продлен, то Public-Key-Pin также обновляется, верно?

• Это зависит от того, к какому сертификату вы обращаетесь и какие сертификаты вы прикрепляете.

Повторял бы все, что сказал gf_.

Однако ответить на вопрос да можно.

По умолчанию Let's Encrypt воссоздает ключ и сертификат при обновлении. Это затрудняет внедрение HPKP, если вы хотите закрепить лист, что, вероятно, следует сделать в случае промежуточных изменений ( как это было в марте 2016 года ).

Так что у вас есть несколько вариантов, если вы все еще хотите сделать HPKP:

1. Используйте свой собственный фиксированный CSR вместо стандартного клиента, который создает CSR для вас каждый раз, чтобы конечный ключ не менялся. В этом блоге объясняется, как это сделать, потому что автор использует HPKP.
2. Используйте короткий срок действия HPKP и обновите его в течение этого срока, а также измените политику, чтобы иметь как старые, так и новые ключи перед тем, как фактически изменить сертификат, с достаточным временем для того, чтобы новые политики могли быть получены любыми посетителями.
3. Прикрепите корень Let's Encrypt вместо листа или сертификата.

Я только что реализовал это, используя обезвоженный клиент с проверкой dns01. Хук dns01 является certzure, потому что наш DNS размещен в Azure.

Редактировать: когда я говорю о закрытых ключах, я всегда имею в виду, что вы превращаете только части открытого ключа в контакты. Закрытые ключи, как следует из названия, всегда должны оставаться закрытыми. Смотрите мой собственный хук для деталей реализации.

Вам нужен ролловер с закрытым ключом, чтобы сделать это возможным. То есть у вас всегда есть текущий закрытый ключ (назовите его A) и будущий закрытый ключ (назовите его B), чтобы вы могли добавить их оба к своим контактам. Таким образом, в этот момент ваши контакты - A и B. Когда наступает день обновления сертификата, закрытый ключ 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 с Let's Encrypt и обезвожены с помощью Nginx:

HPKPinx