HPKP на веб-сервере работает путем добавления заголовков к ответам, содержащим хэши различных открытых ключей, так что хотя бы один из хэшей действительный = сертификата в цепочке сертификатов текущего сертификата сервера, и хотя бы один недействительным = не встречается в цепочке и считается резервным сертификатом. Существует несколько стратегий выбора сертификата для представления действительной записи:
Первый вариант проблематичен, поскольку он оставляет довольно большую поверхность для атаки (то есть кто-то может обмануть или принудить упомянутый CA подписать вредоносный сертификат для вашего хоста). Второй вариант страдает от этого в меньшей степени, но, что более важно, промежуточное звено может внезапно измениться при продлении, что приведет к блокированию вашего сайта (если вы не использовали резервную копию CSR для продления). Третий вариант является наиболее конкретным, но требует, чтобы вы изменили заголовок HPKP в соответствии с очень конкретным сроком и планированием на месяц или независимо от времени ожидания, которое вы используете с заголовком HPKP.
Интересно, может ли помочь перекрестное подписание с личным (ненадежным) центром сертификации, то есть: сработает ли следующий сценарий?
Я получил свой сертификат AAA из широко известного и проверенного центра сертификации XXX, которые используют промежуточный ГГГ подписывать AAA. Также я ставлю крестик на своих AAA сертификат с моим неясным и совершенно ненадежным и никогда не слышанным CA ZZZ. Теперь я настраиваю свой веб-сервер для выдачи заголовков HPKP с AAA, SSS, ZZZ, где SSS надежно хранимая резервная копия CSR, используемая в случае бедствий.
После продления я делаю то же самое со своим новым сертификатом BBB, т.е. у меня он подписан доверенным центром сертификации (возможно, другим, например XX2 и средний YY2) и подпишите его своим ZZZ; и я настраиваю заголовок HPKP для чтения BBB, SSS, ZZZ. (На самом деле, заголовок HPKP можно оставить на SSS, ZZZ с самого начала и никогда не менять)
Почему я думаю, что это должно работать? Допустим, посетитель заходит после перехода с AAA к BBB. Подключение TLS может быть инициировано, потому что мой сервер настроен на использование BBB и промежуточный сертификат YY2 так же как ZZZ. Клиента это устраивает, потому что как минимум YY2 подписано XX2 и это один из самых известных центров сертификации клиентов. Затем он проверяет заголовок HPKP. Это либо свежее, либо содержит BBB, ZZZ, SSS и так нормально. Или более старая версия AAA, ZZZ, SSS используется повторно, что тоже нормально, потому что ZZZ.
Вопрос: Возможен ли описанный выше метод? Будут ли с ним работать все браузеры, поддерживающие HPKP? Или это вообще запрещено спецификациями?
Дополнительный вопрос: Как вы на самом деле выполняли вышеуказанный план (с точки зрения openssl команды и apache конфигурация)?
Нет, не пойдет.
Браузер не знает о сертификате ZZZ - разве вы не собираетесь возвращать его, а также официальный промежуточный сертификат XXX и / или XX2? Даже если вы это сделаете, браузер полностью проигнорирует его как ненадежный и вместо этого построит путь только с доверенным корнем.
HPKP добавляет поверх доверенного корневого хранилища браузера - но не заменяет его.