Назад | Перейти на главную страницу

Могу ли я использовать контакты с открытым ключом с LetsEncrypt?

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

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

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

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

Могу ли я использовать контакты с открытым ключом с LetsEncrypt?

  • Да.

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

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

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

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

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

Итак, у вас есть несколько вариантов решения этой проблемы, если вы все еще хотите использовать HPKP:

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

Я только что реализовал это, используя обезвоженный клиент с проверкой dns01. Хук dns01 - это свидетельство потому что наш 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-й день, и клиент правильно открывает сайт.

НО посмотрим, возраст ХПКП 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