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?

ssl certificate

— Daniël van den Berg
fuente

Como nota al margen: para los principales sitios web, su navegador probablemente no aceptará ningún certificado que logre generar. Esos sitios utilizan la fijación de certificados y envían huellas digitales de sus certificados TLS para su inclusión en esos navegadores. Su certificado no coincidirá con la huella digital almacenada y será bloqueado. Aquí hay más información: noncombatant.org/2015/05/01/about-http-public-key-pinning

— Martijn Heemels

Los certificados autofirmados pueden ser problemáticos como ha descubierto. En su lugar, podría buscar obtener una certificación "adecuada" de letsencrypt.org: son gratuitos y admiten comodines. Dependiendo de cuántos de los hosts que intentaba cubrir con ese * que realmente necesita, uno (o más) certificados de letsencrypt podrían cubrirlo

— Dave Smylie

@DaveSmylie es para un bloqueador de anuncios, no soy dueño de los dominios.

— Daniël van den Berg

@ Stewart por favor lea mi comentario anterior.

— Daniël van den Berg

También hay que tener en cuenta: si está usando esto para un bloqueador de anuncios, podría ser mejor simplemente soltar silenciosamente las conexiones a los servidores relevantes en lugar de mostrar una página alternativa. El 90% de los anuncios modernos se cargan inicialmente a través de JavaScript, por lo que es poco probable que su página alternativa tenga una visibilidad real en la página. Probablemente va a romper cosas, en realidad, tratar de cargar recursos que no sean JavaScript como Javascript.

— Nzall

Respuestas:

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.

— usuario1686
fuente

Ya descubrí ese límite de TLD + 1 empíricamente aquí en un proyecto anterior. Gracias por exponerlo. +1

— Rui F Ribeiro

Gracias por su elaborada respuesta, supongo que eso lo explica, sí. ¿Conoces un enfoque diferente que yo podría usar?

— Daniël van den Berg

Upvoted para la colocación estratégica de "y otro malware".

— Džuris

@ DaniëlvandenBerg: Sugerí uno en la publicación. Acabo de agregar enlaces a ejemplos de Nginx y Squid.

— usuario1686

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).

— Steffen Ullrich
fuente