Свідоцтво про підписання підстановки

У мене вдома налаштована програма "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 показує, що це дійсний сертифікат.

Однак, хром дає мені NET::ERR_CERT_COMMON_NAME_INVALID, а край дає мені подібну помилку ( DLG_FLAGS_SEC_CERT_CN_INVALID)

Чому це? Це CN = *просто не дозволено? Як я міг досягти того, що хочу?

Це не дозволено. Як додаток, що стосується протоколу, до стандартної перевірки імені хостів TLS, усі основні веб-браузери (клієнти HTTPS) по суті погодилися обмежувати сертифікати підстановки на "eTLD + 1" - тобто повинен бути "ефективний TLD" плюс ще один -видовий компонент.

Як правило, це означає, що потрібні принаймні два компоненти ( *.example.netце нормально, але *.netце не так, і це не є голою *). Правило "ефективного TLD" розширює це на багаторівневі суфікси, оскільки co.ukлюди на практиці використовують як нероздільні "TLD". (Так *.example.ac.ukдозволено, але *.ac.ukце не так.)

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

Дивіться відповідну дискусію в Security.SE, яка містить цитату з базових вимог форуму CA-браузера (які стосуються лише публічних ЦО WebPKI, але все одно відображають загальну реалізацію):

CAs ОБОВ'ЯЗКОВО відкликати будь-який сертифікат, коли символ wildcard з'являється в першій позиції етикетки відразу зліва від мітки "керованого реєстром" або "загальнодоступного суфікса".

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

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

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

У сертифікаті може бути лише одна підстановка (тобто ні *.*.example.com), вона може відповідати лише одній мітці (тобто лише www, не www.example.com), вона може бути лише в крайній лівій позиції (тобто, *.www.example.comале не www.*.example.com), і вона не може знаходитись у загальнодоступному суфіксі (тобто ні *.com).