Selbstsigniertes Wildcard-Zertifikat

3155
Daniël van den Berg

Ich habe zu Hause ein Loch eingerichtet, also möchte ich Anfragen für jede Website mit meinem eigenen Server bearbeiten können, um eine Seite "Diese Website wurde blockiert" anzuzeigen.

Ich versuche dies, indem ich ein selbstsigniertes Zertifikat für eine beliebige URL erstellt und dieses auf meinem Gerät installiert. Die Befehle, die ich zum Generieren des Zertifikats verwendet 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 einen NET::ERR_CERT_COMMON_NAME_INVALIDund Rand gibt mir einen ähnlichen Fehler ( DLG_FLAGS_SEC_CERT_CN_INVALID).

Warum ist das? Ist CN = *einfach nicht erlaubt? Wie kann ich erreichen, was ich will?

13
Als Randbemerkung: Bei großen Websites akzeptiert Ihr Browser wahrscheinlich kein Zertifikat, das Sie erstellen möchten. Diese Sites verwenden ein Zertifikat-Pinning und übermitteln Fingerabdrücke ihrer TLS-Zertifikate zur Aufnahme in diese Browser. Ihr Zertifikat stimmt nicht mit dem gespeicherten Fingerabdruck überein und wird gesperrt. Hier finden Sie weitere Informationen: https://noncombatant.org/2015/05/01/about-http-public-key-pinning/ Martijn Heemels vor 6 Jahren 0
Selbst signierte Zertifikate können problematisch sein, wie Sie entdeckt haben. Sie können stattdessen nach einer "richtigen" Zertifizierung von letsencrypt.org suchen - sie sind kostenlos und unterstützen Platzhalter. Abhängig davon, wie viele Hosts Sie mit dem tatsächlich benötigten * versorgen wollten, könnten Sie eines oder mehrere Zertifikate von letsencrypt verwenden Dave Smylie vor 6 Jahren 0
@DaveSmylie ist für einen Adblocker, ich besitze die Domains nicht. Daniël van den Berg vor 6 Jahren 1
https://letsencrypt.org/ gibt Ihnen signierte Zertifikate kostenlos Stewart vor 6 Jahren 0
@Stewart bitte meinen vorherigen Kommentar lesen. Daniël van den Berg vor 6 Jahren 0
Außerdem ist zu beachten: Wenn Sie dies für einen Adblocker verwenden, ist es möglicherweise besser, die Verbindungen zu den entsprechenden Servern still zu lassen, anstatt eine alternative Seite anzuzeigen. 90% der modernen Anzeigen werden anfänglich über JavaScript geladen. Daher ist es unwahrscheinlich, dass Ihre alternative Seite echte Sichtbarkeit auf der Seite hat. Es wird wahrscheinlich Sachen kaputt machen, die versuchen, Nicht-JavaScript-Ressourcen als Javascript zu laden. Nzall vor 6 Jahren 1

2 Antworten auf die Frage

34
grawity

Es ist nicht erlaubt. Als protokollspezifische Ergänzung zur Standard-TLS-Hostnamenvalidierung haben alle großen Webbrowser (HTTPS-Clients) grundsätzlich zugestimmt, Wildcard-Zertifikate auf "eTLD + 1" zu beschränken. Das heißt, es muss eine "effektive TLD" plus eine weitere Nicht-URL geben -wildcard-Komponente

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

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

Siehe verwandte Diskussionen in Security.SE, die ein Angebot aus den CA-Browser-Forum-Grundanforderungen enthalten (die nur für öffentliche WebPKI-Zertifizierungsstellen gelten, jedoch immer noch die allgemeine Implementierung widerspiegeln):

CAs MÜSSEN alle Zertifikate widerrufen, bei denen ein Platzhalterzeichen an der ersten Position des Labels unmittelbar links von einem "registrierungskontrollierten" Label oder einem "öffentlichen Suffix" steht.


Um diese Einschränkung zu vermeiden, erstellen Sie eine Zertifizierungsstelle, die Zertifikate "on demand" für jede Website ausstellt, die Sie besuchen möchten. Ich weiß nicht, wie dies in einem normalen Webserver implementiert werden würde, aber dies ist eine gängige Methode, die von kommerziellen TLS-Abfangsystemen verwendet wird. Antivirus-Programme und andere Malware; und Entwicklungstools wie die Burp Proxy-Suite.

Beispielsweise hat der OpenResty-Webserver (im Wesentlichen Nginx-with-Lua) die ssl_certificate_by_luaMöglichkeit, eine dynamische Zertifikaterstellung zu implementieren. Der Squid-Proxy unterstützt in seiner Funktion "ssl-bump" das Nachahmen von Zertifikaten .

Beachten Sie auch, dass SANs den Subject-CN vollständig überschreiben, wenn beide vorhanden sind. Dies bedeutet, dass der CN weitgehend redundant ist (es sei denn, Ihre Client-Software ist so alt, dass SAN-Unterstützung fehlt). Für öffentliche Zertifizierungsstellen akzeptieren Webbrowser dies nicht mehr.

Ich habe die TLD + 1-Grenze hier in einem früheren Projekt bereits empirisch gefunden. Danke, dass Sie es angelegt haben. +1 Rui F Ribeiro vor 6 Jahren 0
Vielen Dank für Ihre ausführliche Antwort, ich denke, das erklärt es ja. Kennen Sie zufällig einen anderen Ansatz, den ich verwenden könnte? Daniël van den Berg vor 6 Jahren 0
Die strategische Platzierung von "und anderer Malware" wurde verbessert. Džuris vor 6 Jahren 20
@ DaniëlvandenBerg: Ich habe im Post selbst einen vorgeschlagen. Ich habe gerade Links zu Nginx- und Squid-Beispielen hinzugefügt. grawity vor 6 Jahren 0
3
Steffen Ullrich

Es kann nur einen einzigen Platzhalter in einem Zertifikat geben (dh nein *.*.example.com), es kann nur ein einziges Label (dh nur www, nicht www.example.com) zugeordnet werden, es darf sich nur auf der linken Seite befinden (dh, *.www.example.comaber nicht www.*.example.com), und es darf sich nicht innerhalb des öffentlichen Suffix befinden (dh nein *.com).