Selbstsigniertes Wildcard-Zertifikat

Ich habe ein Pihole zu Hause eingerichtet, daher möchte ich in der Lage sein, Anfragen für jede Website mit meinem eigenen Server zu bearbeiten, um die Seite "Diese Website wurde blockiert" anzuzeigen.

Ich versuche dies, indem ich ein selbstsigniertes Zertifikat für eine beliebige URL erstelle und dieses auf meinem Gerät installiere. Die Befehle, mit denen ich das Zertifikat erstellt habe:

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

Ich habe dieses Zertifikat auf meinem Windows-Gerät installiert und Windows zeigt an, dass es ein gültiges Zertifikat ist.

Chrom gibt mir jedoch eine NET::ERR_CERT_COMMON_NAME_INVALIDund Kante gibt mir einen ähnlichen Fehler ( DLG_FLAGS_SEC_CERT_CN_INVALID)

Warum ist das? Ist CN = *nur nicht erlaubt? Wie könnte ich erreichen, was ich will?

Es ist nicht erlaubt. Als protokollspezifische Ergänzung zur standardmäßigen TLS-Hostnamenvalidierung haben sich alle gängigen Webbrowser (HTTPS-Clients) grundsätzlich darauf geeinigt, Platzhalterzertifikate auf "eTLD + 1" zu beschränken - dh es muss eine "effektive TLD" plus eine weitere nicht vorhanden sein -Wildcard-Komponente.

Im Allgemeinen bedeutet dies, dass mindestens zwei Komponenten erforderlich sind ( *.example.netist in Ordnung, *.netist es aber nicht, und ist es auch nicht *). Die "effektive TLD" -Regel erweitert dies auf mehrstufige Suffixe, da co.ukdiese in der Praxis als unteilbare "TLDs" verwendet werden. (So *.example.ac.ukist erlaubt, aber *.ac.uknicht.)

Sie können überprüfen, wie die öffentliche Suffixliste in Chromium und Mozilla implementiert ist .

Siehe verwandte Diskussion in Security.SE, in der ein Zitat aus den Grundanforderungen des CA-Browser-Forums enthalten ist (die nur für öffentliche WebPKI-CAs gelten, aber dennoch die allgemeine Implementierung widerspiegeln):

CAs MÜSSEN jedes Zertifikat widerrufen, bei dem Platzhalterzeichen an der ersten Etikettenposition unmittelbar links von einem „registrierungsgesteuerten“ Etikett oder einem „öffentlichen Suffix“ vorkommen.

Um diese Einschränkung zu vermeiden, erstellen Sie eine Zertifizierungsstelle, die Zertifikate "on demand" für jede Website ausgibt, die Sie besuchen möchten. Ich weiß nicht, wie das auf einem normalen Webserver implementiert wird, aber dies ist eine übliche Methode, die von kommerziellen TLS-Abhörsystemen verwendet wird. Antivirenprogramme und andere Malware; und Entwicklungstools wie die Burp Proxy Suite.

Zum Beispiel kann der OpenResty Web - Server (im Grunde Nginx-mit-Lua) hat eine ssl_certificate_by_luaOption dynamisches Zertifikat Generation zu implementieren. Der Squid-Proxy unterstützt die Nachahmung von Zertifikaten in seiner SSL-Funktion.

Beachten Sie auch, dass SANs den Subject-CN vollständig überschreiben, wenn beide vorhanden sind. Dies macht das Hinzufügen des CN zum größten Teil überflüssig (es sei denn, Ihre Client-Software ist so alt, dass es keine SAN-Unterstützung gibt), und für öffentliche Zertifizierungsstellen akzeptieren Webbrowser dies nicht einmal mehr.

Ein Zertifikat darf nur einen einzigen Platzhalter enthalten (dh keinen *.*.example.com), es darf nur mit einem einzigen Etikett übereinstimmen (dh nur www, nicht www.example.com), es darf sich nur ganz links befinden (dh *.www.example.comaber nicht www.*.example.com) und es darf sich nicht innerhalb des öffentlichen Suffixes befinden (dh nein *.com).