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

Как заставить его работать Закрепление сертификата (HPKP) и самоподписанный сертификат в локальной сети?

Мне нужно использовать SSL в локальной сети, и я хочу избежать ошибки недействительного сертификата браузера.

Моя идея - создать самоподписанный сертификат, а затем использовать привязку сертификата (HPKP), чтобы сообщить браузеру, что только этому сертификату можно доверять?

В настоящее время я изучаю все варианты, связанные с этой идеей. Я тестировал самоподписанный сертификат и заголовок HPKP (Public-Key-Pins) со значением, например:

"pin-sha256="somedataencodedbase64=";pin-max-age=10;includeSubDomains"

Браузер не считает это безопасным. Мне все еще нужно завершить этот тест (с другим самоподписанным сертификатом, и мне нужно убедиться, что SPKI рассчитан правильно ...

Теперь вопросы:

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

Является ли самоподписанный сертификат, выданный для данного имени локального хоста (например, mylocalserver) и закрепленный в ответе сервера, действительным? Это вообще сработает?

Да, HPKP просто объявляет подпись для данного сертификата x.509. Браузер (или любой веб-клиент) просто кеширует его на указанный период, а затем проверяет эту подпись при последующих посещениях.

Работает ли закрепление сертификата для имен локальных хостов (это означает, что оно работает только с доменными именами)?

Имя локального хоста - это имя хоста, как и любое другое. Даже если коротко. Даже если у него есть локальный TLD. Дело в том, как ваш клиент решает эту проблему и что он запрашивает в Host: заголовок HTTP-запроса. Если он разрешает хост foobar на правильный IP, а затем спрашивает это Host: в HTTP-запросе, а для самозаверяющего сертификата CN установлено значение foobar, тогда вся схема начинает работать.

Должен ли закрепленный сертификат быть сначала действительным или выдвинутым центром сертификации (это будет означать, что самоподписанные сертификаты не могут быть закреплены - если они не добавлены в хранилище доверия на клиенте)?

Нет, это не так. Однако каким-то образом ваш веб-клиент должен иметь возможность доверять сертификату сервера. Либо он помещается в список сертификатов доверенных серверов, либо вы создаете исключения (это фактически то же самое, что и предыдущее), либо вы создаете локальный ЦС и подписываете сертификат сервера своим сертификатом локального ЦС. Самозаверяющий сертификат сервера - это просто способ пропустить создание локального центра сертификации. Кстати, все официальный CA использует самозаверяющий сертификат в качестве корневой точки своей инфраструктуры открытых ключей. Это законный способ создания CA. An официальный ЦС - это просто ЦС, сертификат которого добавляется в хранилище доверенных сертификатов наиболее известного программного обеспечения, такого как операционные системы, браузеры и т. Д. Договоренность о добавлении стоит денег, поэтому большинство из них платные.

Каким будет самый простой способ иметь действующий SSL локально, чтобы мне не нужно было настраивать клиент (клиентское хранилище доверия)?

Получение самозаверяющего сертификата для каждой имеющейся у вас службы. Если у вас мало таких сервисов, вы имеете дело с самозаверяющими сертификатами, если у вас их десятки, вы создаете свой локальный ЦС. Существует также законный бесплатный способ получить публично принятые сертификаты X.509 - просто используйте LetsEncrypt центр сертификации - это бесплатно. Однако они не предоставляют сертификаты с подстановочными знаками - те, которые имеют *, а это может стать проблемой, если у вас огромное количество сервисов.

Можем ли мы рассматривать закрепление сертификатов как альтернативу надежному ЦС? Я где-то читал, это просто дополнительно, значит, сначала должна быть действительна цепочка сертификатов, а затем вы можете закрепить ее?

Нет. Закрепление сертификата - это мера противодействия человек посередине атаки, когда кто-то выдает себя за целевой ЦС. Для этого этот «кто-то» должен уже поместить свой сертификат корневого CA в ваше хранилище доверенных сертификатов, но это другая проблема.

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

Вы определенно любите.

После дальнейших исследований я действительно хотел докопаться до реальной спецификации.

Итак, RFC 7469 говорит:

2.3.1. Обработка поля заголовка ответа Public-Key-Pins

Если UA получает по защищенному транспорту ответ HTTP, который включает поле заголовка PKP, соответствующее грамматике, указанной в разделе 2.1, и нет никаких основных ошибок безопасного транспорта или предупреждений ...

Итак, теперь официально ясно, что сначала должно произойти надлежащее подтверждение SSL (включая проверку цепочки сертификации), а затем может произойти HPKP ...