Certificado comodín autofirmado

Tengo un agujero instalado en casa, por lo que quiero poder manejar las solicitudes de cualquier sitio web con mi propio servidor, para mostrar una página "este sitio ha sido bloqueado".

Estoy intentando hacer esto creando un certificado autofirmado para cualquier url e instalándolo en mi dispositivo. Los comandos que utilicé para generar el certificado:

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

He instalado este certificado en mi dispositivo Windows, y Windows muestra que es un certificado válido.

Sin embargo, Chrome me da un NET::ERR_CERT_COMMON_NAME_INVALID, y edge me da un error similar ( DLG_FLAGS_SEC_CERT_CN_INVALID)

¿Por qué es esto? ¿ CN = *Simplemente no está permitido? ¿Cómo podría lograr lo que quiero?

No esta permitido. Como una adición específica del protocolo a la validación estándar del nombre de host TLS, todos los principales navegadores web (clientes HTTPS) básicamente han acordado restringir los certificados comodín a "eTLD + 1", es decir, debe haber un "TLD efectivo" más uno más -componente de tarjeta salvaje.

En general, esto se traduce en requerir al menos dos componentes ( *.example.netestá bien, pero *.netno lo está, ni está al descubierto *). La regla de "TLD efectivo" amplía esto a sufijos de varios niveles, ya co.ukque las personas usan como "TLD" indivisibles en la práctica. (Entonces *.example.ac.ukestá permitido pero *.ac.ukno lo está).

Puede inspeccionar cómo se implementa la lista de sufijos públicos en Chromium y en Mozilla .

Consulte la discusión relacionada en Security.SE, que tiene una cita de los Requisitos de línea de base del foro CA-Browser (que solo se aplican a las CA públicas de WebPKI, pero aún reflejan la implementación general de todos modos):

Las CA DEBERÁN revocar cualquier certificado donde haya caracteres comodín en la primera posición de la etiqueta inmediatamente a la izquierda de una etiqueta "controlada por el registro" o "sufijo público".

Para evitar esta restricción, cree una autoridad de certificación que emita certificados "a pedido" para cualquier sitio web que intente visitar. No sé cómo se implementaría eso en cualquier servidor web normal, pero este es un método común utilizado por los sistemas comerciales de interceptación TLS; programas antivirus y otro malware; y herramientas de desarrollo como la suite Burp Proxy.

Por ejemplo, el servidor web OpenResty (básicamente Nginx-with-Lua) tiene una ssl_certificate_by_luaopción para implementar la generación dinámica de certificados. El proxy Squid admite la imitación de certificados en su función ssl-bump.

También tenga en cuenta que las SAN anulan completamente el Asunto-CN si ambos están presentes. Esto hace que incluir el CN ​​sea en su mayoría redundante (a menos que el software de su cliente sea tan antiguo que carezca de soporte SAN), y para los navegadores web de CA públicas ya ni siquiera lo aceptan.

Solo puede haber un solo comodín en un certificado (es decir, no *.*.example.com), puede coincidir con una sola etiqueta (es decir www, solo , no www.example.com), solo puede estar en la posición más a la izquierda (es decir, *.www.example.compero no www.*.example.com) y no puede estar dentro del sufijo público (es decir, no *.com).