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

Будет повторять все, что сказал 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. Вот как вы переносите свои закрытые ключи. dehydrated теперь поддерживает это .

Кроме того, вам нужен перехватчик, который вызывается каждый раз, когда вы обновляете свои сертификаты и, таким образом, переключаете свои закрытые ключи. Я реализовал это самостоятельно .

Наконец, если я все понимаю, вы должны убедиться, что:

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