Ist es möglich, die Verwendung eines Stammzertifikats auf eine Domäne zu beschränken?

Mein Kunde verwendet ein selbstsigniertes Zertifikat, damit eine Anwendung funktioniert. Um arbeiten zu können, muss ich das Stammzertifikat installieren, mit dem das Zertifikat signiert wurde.

Ist es möglich, ein Stammzertifikat so zu konfigurieren, dass es nur für eine Domäne gültig ist?

certificate restrictions

— MichaelD
quelle

Es könnte nur ich sein, aber mir ist nicht klar, was Sie eigentlich fragen. Welchen Endzustand wollen Sie erreichen? Wenn Sie das Stammzertifikat in die Domänencontroller-Vertrauensstellung importieren, können nur die Systeme unter dieser Domäne eine Validierung durchführen ...

— Gravy

Es hört sich so an, als würden Sie selbstsignierte Zertifikate mit der Verwendung einer nicht öffentlich vertrauenswürdigen Stammzertifizierungsstelle verwechseln. Eine Anwendung, die für die Verwendung eines selbstsignierten Zertifikats konfiguriert ist, ist sehr schlecht, da die Anwendung so konfiguriert werden muss, dass Fehler bei der Zertifikatüberprüfung ignoriert werden. Die Verwendung einer nicht öffentlich vertrauenswürdigen Stammzertifizierungsstelle ist tatsächlich weit verbreitet.

— Greg Askew

Haben Sie einen internen CA-Server?

— Crypt32,

Eine Zertifizierungsstelle kann sich auf bestimmte Domänen mit Namensbeschränkungen beschränken . Die rückwirkende Anwendung von Beschränkungen auf die Zertifizierungsstelle einer anderen Person ist jedoch eine andere Angelegenheit.

— Matt Nordhoff

es gibt keinen Unterschied. Sie können Namensbeschränkungen auch auf Zertifizierungsstellen von Drittanbietern anwenden. Sie signieren einfach das Root-CA-Zertifikat eines Drittanbieters mithilfe Ihrer privaten CA und veröffentlichen das generierte Gegenzertifikat. In diesem Fall wird die ausländische Kette durch ein eingeschränktes Gegenzertifikat zu Ihrer privaten Kette.

— Crypt32

Antworten:

Als Faustregel gilt:

Nein . Wenn Sie dem CA-Zertifikat des Kunden vertrauen, müssen Sie jedem Zertifikat vertrauen, das von dieser CA signiert wurde.

Ich kenne keine Anwendungen / Bibliotheken mit einer einfachen Option, mit der Sie als Endbenutzer auswählen können, dass Sie Ihren Kunden oder anderen CA-Zertifikaten nur für bestimmte (Sub-) Domains, dh nur für *, vertrauen. example.com und * .example.org und sonst nichts.

Mozilla hat eine ähnliche Besorgnis über derzeit vertrauenswürdige Regierung CA als gesponserte offene Aufmerksamkeit Punkt und zum Beispiel Chrome hat extra gebaut Kontrollen für den Zugriff auf Google - Websites, die waren , wie der Schurke * .google.com Zertifikat und der Kompromiss der DigiNotar CA Öffentlichkeit wurden .

Aber auch wenn Sie der Zertifizierungsstelle nicht vertrauen, können Sie ein bestimmtes von dieser Zertifizierungsstelle signiertes Serverzertifikat importieren / vertrauen, wodurch SSL-Warnungen für die Hostnamen in diesem Zertifikat verhindert werden. Damit sollte Ihre Bewerbung fehler- und beschwerdefrei funktionieren.

Ausnahmen:

Eine sehr wenig genutzte Option des X.509v3-PKI-Standards ist die Namensbeschränkungserweiterung , die es einem CA-Zertifikat ermöglicht, White- und Blacklists von Domainnamenmustern zu enthalten, für die es Zertifikate ausstellen darf.

Möglicherweise haben Sie Glück und Ihr Kunde hat sich zurückgehalten, als er seine PKI-Infrastruktur eingerichtet und diese Namensbeschränkung in sein CA-Zertifikat aufgenommen hat. Dann können Sie ihr CA-Zertifikat direkt importieren und wissen, dass es nur einen begrenzten Bereich von Domain-Namen validieren kann.

— HBruijn
quelle

@CryptoGuy: Eine interne Zertifizierungsstelle kann auch Zertifikate für externe Domänen ausstellen. Sobald Sie Ihre interne CA dort Vertrauen ist keine Einschränkung , so dass nur Zertifikate für die eigene (Active Directory oder DNS) Domäne example.comoder *.ad.example.com gültig sind. Ihre interne Zertifizierungsstelle kann auch Zertifikate ausstellen, um *.example.bankeinen netten Man-in-the-Middle-Angriff zu ermöglichen und Ihre Online-Banking-Anmeldeinformationen zu erheben.

— HBruijn

Nun, "alles" stimmt nicht ganz. Es gibt Dinge wie Zertifikatsperrlisten. Daran ändert sich aber nichts.

— Ben Voigt

Entschuldigung, Sie sind wieder falsch. Sie können die Zertifizierungsstelle eines Drittanbieters einschränken, um Zertifikaten (von dieser Zertifizierungsstelle) zu vertrauen, die für eine von Ihnen gewünschte Namensliste ausgestellt wurden. In Bezug auf Ihre eigene interne Zertifizierungsstelle gehe ich davon aus, dass das Vertrauen zweifelsfrei ist. Wenn Sie Ihrer eigenen Zertifizierungsstelle nicht vertrauen, stimmt etwas nicht mit Ihrer IT. Ich möchte sagen, dass OP durch eine private Zertifizierungsstelle eine teilweise Vertrauenswürdigkeit gegenüber einer Zertifizierungsstelle eines Drittanbieters herstellen kann (indem Namen, denen sie vertrauen, eingeschränkt werden).

— Crypt32

Zu Ihrem bearbeiteten Beitrag: Auch wenn Drittanbieter-Zertifizierungsstellen keine Namensbeschränkungserweiterung haben, ist es möglich, diese mithilfe eines eigenen internen Zertifizierungsstellenservers über eine Gegenzertifizierung anzuwenden. In diesem Fall lautet die Zertifikatskette wie folgt: Blatt-SSL-Zertifikat -> Gegenzertifikat -> Ihr CA-Zertifikat -> Ihr internes Stammzertifikat. Der Trick ist, dass Sie die Zertifizierungsstelle eines Drittanbieters mit Ihrer internen Zertifizierungsstelle signieren. Für Gegenzertifikate gelten alle erforderlichen Einschränkungen.

— Crypt32

Laut CryptoGuy ist dies möglich, aber es ist schwierig, Implementierungsdetails zu finden. Wie wäre es mit einer Antwort, die beschreibt, wie dies erreicht werden kann? Und vielleicht eine Diskussion darüber, welche Plattformen nameConstraints unterstützen.

— Jorfus

@ CryptoGuy hatte hier eine ziemlich gute Antwort, aber ich wollte es erweitern.

Umschreiben:

Sie können die Zertifizierungsstelle eines Drittanbieters einschränken, um Zertifikaten (von dieser Zertifizierungsstelle) zu vertrauen, die für eine von Ihnen gewünschte Namensliste ausgestellt wurden. Auch wenn die Drittanbieter-Zertifizierungsstelle keine Namensbeschränkungserweiterung hat, können Sie diese über eine Gegenzertifizierung mithilfe Ihres eigenen internen Zertifizierungsstellenservers anwenden. Der Trick besteht darin, dass Sie die Zertifizierungsstelle eines Drittanbieters mit Ihrer internen Zertifizierungsstelle signieren.

Blatt SSL-Zertifikat -> Gegenzertifikat -> Ihr CA-Zertifikat -> Ihr internes Stammzertifikat.

Und so funktioniert das (mithilfe der OpenSSL-Befehlszeilen-CA)

Erstellen Sie eine einfache Zertifizierungsstelle

openssl req -new -x509 -days 3650 -newkey rsa:2048 -sha256 -out root-ca.crt -keyout root-ca.key -subj "/CN=My Root CA"

Sie können das Erstellen einer Zwischenzertifizierungsstelle überspringen

Erstellen Sie eine Zwischenzertifizierungsstellenanforderung mit Namensbeschränkungen.

openssl req -new -days 3650 -newkey rsa:2048 -out domain-ca.req -sha256 -keyout domain-ca.key -config ossl_domain_com.cfg

Mit diesem in der ossl_domain_com.cfgDatei:

[ req ]
prompt=no
distinguished_name=req_distinguished_name
req_extensions=domain_ca

[ req_distinguished_name ]
CN=somedomain.com trust CA

[ domain_ca ]
basicConstraints=critical,CA:true,pathlen:1
nameConstraints=critical,permitted;DNS:.somedomain.com

Unterschreiben Sie dann diese Zwischen-Domänen-Zertifizierungsstelle mit Ihrer Zertifizierungsstelle.

openssl x509 -req -in domain-ca.req -CA root-ca.crt -CAkey root-ca.key -sha256 -set_serial 1 -out domain-ca.crt -extensions domain_ca -extfile ossl_domain_com.cfg

Wenn Sie das Erstellen des Zwischenprodukts übersprungen haben, signieren Sie mit Ihrer Stammzertifizierungsstelle

Signieren Sie nun die CA der ursprünglichen Domain unter Ihrer Autorität mit ihrem Zertifikat neu. Hier können Sie die CA-Erweiterungen hinzufügen.

openssl x509 -in third_party_ca.crt -CA domain-ca.crt -CAkey domain-ca.key -set_serial 47 -sha256 -extensions domain_ca -extfile ossl_domain_com.cfg -out domain-cross-ca.crt

Möglicherweise müssen Sie das -x509-to-reqArgument verwenden, um eine Anfrage zu erstellen, die Sie genauso wie das Zwischenprodukt oben signieren würden.

Fügen Sie nun Ihre Stammzertifizierungsstelle, Zwischenzertifizierungsstelle und die domänenübergreifende Zertifizierungsstelle zur Vertrauensdatenbank Ihres Browsers hinzu.

— davenpcj
quelle

MacOS unterstützt keine nameConstraints. Nur FIY für alle, die an einer namensbeschränkten internen Zertifizierungsstelle arbeiten. security.stackexchange.com/questions/95600/… archive.is/6Clgb

— jorfus

F: Wie ist der Status dieser Lösung? In welchen Systemen funktioniert es heutzutage (2018)? // Ich wollte dies jedes Mal, wenn ich gezwungen bin, noch ein selbstsigniertes Zertifikat eines Unternehmens zu installieren. und jedes Mal denke ich an die Hong Kong Post oder Symantec. // Ich denke, es ist mir egal, dass niemand die so beschriebene Verengung implementiert, solange er nicht versehentlich eine Erweiterung implementiert.

— Krazy Glew

@KrazyGlew Ich habe eine Batch-Datei, die ich dafür verwende, und ich verwende sie immer noch regelmäßig. Gelegentlich muss ich die Zwischenzertifikate neu ausgeben, wenn sie ablaufen oder rotieren. Es ist also etwas mehr manuell, aber es war kein Problem. Ich stoße gelegentlich auf Websites, die von Behörden verwaltet werden und denen mein Browser aufgrund der Verwendung einer anderen zwischengeschalteten Behörde oder eines zusätzlichen Domänennamens, den sie hinzugefügt haben, nicht vertraut.

— Davenpcj

Ich habe es gerade erfolgreich benutzt, danke. Es funktioniert hervorragend ohne Zwischenzertifikat. Gibt es einen Vorteil bei der Verwendung eines Zertifikats? Außerdem basicConstraintsscheint die Zeile in der Konfigurationsdatei dazu zu führen, dass die Einschränkungserweiterung zweimal im Zertifikat enthalten ist, wodurch Firefox das Zertifikat mit einer kryptischen Fehlermeldung ablehnt. Ich denke, es kann sicher entfernt werden.

— Wrtlprnft

Ich erhalte eine Fehlermeldung an den letzten Schritt: error with certificate to be certified - should be self signed. Was bedeutet das und wie kann man das lösen? pastebin.ubuntu.com/p/QHhpQh2N6J

— mymedia