14

У меня дома настроен pihole, поэтому я хочу иметь возможность обрабатывать запросы для любого веб-сайта со своим собственным сервером, чтобы показать страницу "этот сайт был заблокирован".

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

openssl genrsa 2048 > pihole.key
openssl req -new -x509 -nodes -days 36500\
    -key pihole.key \
    -subj "/C=NL/ST=Utrecht, Inc./CN=*" \
    -reqexts SAN \
    -config <(cat /etc/ssl/openssl.cnf \
        <(printf "\n[SAN]\nsubjectAltName=DNS:*,DNS:*")) \
    -out pihole.cert
openssl x509 -noout -fingerprint -text < pihole.cert > pihole.info
cat pihole.cert pihole.info > pihole.pem
service apache2 reload

Я установил этот сертификат на моем устройстве Windows, и Windows показывает, что это действительный сертификат.

Тем не менее, Chrome дает мне NET::ERR_CERT_COMMON_NAME_INVALID , а edge дает мне похожую ошибку (DLG_FLAGS_SEC_CERT_CN_INVALID)

Почему это? CN = * просто не разрешен? Как я могу достичь того, чего хочу?

2 ответа2

35

Это не разрешено. В качестве специфичного для протокола дополнения к стандартной проверке имени хоста TLS все основные веб-браузеры (клиенты HTTPS) в основном согласились ограничить использование групповых сертификатов «eTLD +1», то есть должен существовать "эффективный TLD" плюс еще один Компонент

Как правило, это означает, что требуется как минимум два компонента (*.example.net - это нормально, но *.net - нет, да и не голый *). "Эффективное TLD" правило расширяет это суффиксы многоуровневых как co.uk , которые люди используют в качестве неделимой "ДВОЙ" на практике. (Так что *.example.ac.uk разрешен, а *.ac.uk - нет.)

Вы можете проверить, как реализован общедоступный список суффиксов в Chromium и Mozilla.

См. Соответствующее обсуждение в разделе « Безопасность».SE, которая содержит цитату из базовых требований форума CA-Browser (которые применяются только к общедоступным CA WebPKI, но все равно отражают общую реализацию):

ЦС ДОЛЖНЫ аннулировать любой сертификат, в котором подстановочный знак находится в первой позиции метки непосредственно слева от метки, «контролируемой реестром» или «открытого суффикса».


Чтобы избежать этого ограничения, создайте центр сертификации, который выдает сертификаты "по требованию" для любого веб-сайта, который вы пытаетесь посетить. Я не знаю, как это будет реализовано на любом обычном веб-сервере, но это распространенный метод, используемый в коммерческих системах перехвата TLS; антивирусные программы и другие вредоносные программы; и инструменты разработки, такие как пакет Burp Proxy.

Например, веб-сервер OpenResty (в основном Nginx-with-Lua) имеет опцию ssl_certificate_by_lua для реализации динамического создания сертификата. Прокси-сервер Squid поддерживает имитацию сертификатов в своей функции ssl-bump.

Также обратите внимание, что SAN полностью перекрывают Subject-CN, если присутствуют оба. Это делает включение CN в основном избыточным (если ваше клиентское программное обеспечение не является настолько древним, что в нем отсутствует поддержка SAN), а для общедоступных CA веб-браузеры даже не принимают его больше.

4

В сертификате может быть только один подстановочный знак (т.е. нет *.*.example.com), он может соответствовать только одной метке (т. е. только www , а не www.example.com), он может быть только в самой левой позиции (т. е. *.www.example.com но не www.*.example.com), и он не может быть внутри общедоступного суффикса (т.е. не *.com).

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .