Certificato jolly autofirmato

Ho installato Pihole a casa, quindi voglio essere in grado di gestire le richieste di qualsiasi sito Web con il mio server, per mostrare una pagina "questo sito è stato bloccato".

Sto tentando di farlo creando un certificato autofirmato per qualsiasi URL e installandolo sul mio dispositivo. I comandi che ho usato per generare il certificato:

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

Ho installato questo certificato sul mio dispositivo Windows e Windows mostra che è un certificato valido.

Tuttavia, chrome mi dà un NET::ERR_CERT_COMMON_NAME_INVALIDe edge mi dà un errore simile ( DLG_FLAGS_SEC_CERT_CN_INVALID)

Perchè è questo? Non CN = *è permesso? Come potrei ottenere ciò che voglio?

Non è permesso. Come aggiunta specifica del protocollo alla convalida del nome host TLS standard, tutti i principali browser Web (client HTTPS) hanno sostanzialmente concordato di limitare i certificati jolly a "eTLD + 1" - vale a dire, deve esserci un "TLD efficace" più un altro non -wildcard componente.

Generalmente questo si traduce nel richiedere almeno due componenti ( *.example.netva bene ma *.netnon lo è, né è nuda *). La regola "TLD efficace" espande questo a suffissi multilivello in quanto le co.ukpersone usano come "TLD" indivisibili nella pratica. (Quindi *.example.ac.ukè permesso ma *.ac.uknon lo è.)

Puoi controllare come viene implementato l' elenco dei suffissi pubblici in Chromium e in Mozilla .

Vedere la discussione correlata in Security.SE che contiene un preventivo dai requisiti di base del forum CA-Browser (che si applicano solo alle CA WebPKI pubbliche, ma che comunque riflettono comunque l'implementazione generale):

Le CA devono revocare qualsiasi certificato in cui il carattere jolly si trova nella prima posizione dell'etichetta immediatamente a sinistra di un'etichetta "controllata dal registro" o "suffisso pubblico".

Per evitare questa limitazione, crea un'autorità di certificazione che emetta certificati "su richiesta" per qualsiasi sito web che si tenta di visitare. Non so come sarebbe implementato in qualsiasi normale server Web, ma questo è un metodo comune utilizzato dai sistemi di intercettazione TLS commerciali; programmi antivirus e altro malware; e strumenti di sviluppo come la suite Burp Proxy.

Ad esempio, il server Web OpenResty (sostanzialmente Nginx-with-Lua) ha ssl_certificate_by_luaun'opzione per implementare la generazione dinamica di certificati. Il proxy Squid supporta l' imitazione di certificati nella sua funzione ssl-bump.

Si noti inoltre che le SAN sostituiscono completamente l'oggetto-CN se entrambi sono presenti. Ciò rende la CN in gran parte ridondante (a meno che il software client non sia così antico da non avere il supporto SAN) e per i browser Web delle CA pubbliche non lo accetti più.

In un certificato può esserci un solo carattere jolly (cioè no *.*.example.com), può corrispondere a una sola etichetta (cioè solo www, non www.example.com), può essere solo nella posizione più a sinistra (cioè *.www.example.comma non www.*.example.com) e non può essere all'interno del suffisso pubblico (cioè no *.com).