Могу ли я установить Public-Key-Pins, когда я настраиваю cronjob для обновления сертификата LetsEncrypt каждые 30 дней?
Если сертификат обновляется, то PIN-код также обновляется, верно?
Несколько слов предостережения для начала:
Могу ли я использовать контакты с открытым ключом с LetsEncrypt?
Если сертификат обновляется, то PIN-код также обновляется, верно?
Повторил бы все, что сказала gf_.
Однако, чтобы ответить на вопрос, да, вы можете.
По умолчанию Let's Encrypt воссоздает ключ и сертификат при обновлении. Это затрудняет реализацию HPKP, если вы хотите закрепить на листе, что вам, вероятно, следует делать в случае промежуточных изменений (как это было в марте 2016).
Итак, у вас есть несколько вариантов решения этой проблемы, если вы все еще хотите использовать HPKP:
Я только что реализовал это, используя обезвоженный клиент с проверкой 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: