Dieser Blog ist die Fortsetzung einer Reihe von Blogs, die sich mit den Gefahren des Hinzufügens von Subject Alternate Name (SAN)-Informationen zu einem Certificate Signing Request (CSR) befassen.
In früheren Blogs habe ich beschrieben, wie Konfigurationen, die erforderlich sind, um SAN-Informationen zu bestehenden Zertifikatsignierungsanforderungen hinzuzufügen, die eigene Zertifizierungsstelle anfällig für Imitationsangriffe machen können. Das heißt, wenn Ihr Arbeitsablauf für die Ausstellung von Zertifikaten davon abhängt, dass die SAN-Informationen des Zertifikats nach der Erstellung einer CSR hinzugefügt werden, kann Ihre CA wahrscheinlich auf bösartige Weise verwendet werden.
Warum ist das so?
Um SAN-Informationen sicher zu einem Zertifikat hinzufügen zu können, müssen die SAN-Informationen im signierten Teil der Zertifikatsanforderung enthalten sein. SAN-Informationen können innerhalb eines CSR oder neben diesem eingereicht werden. Microsoft CA kann so konfiguriert werden (durch Setzen des "EDITF_ATTRIBUTESUBJECTALTNAME2"-Richtlinienflags), dass beim Hinzufügen von SAN-Informationen zu einem Zertifikat beiden Stellen vertraut wird und diese verwendet werden. Die CSS empfiehlt jedoch im Allgemeinen nicht, dieses Flag zu verwenden.
Das Hinzufügen der SAN-Informationen , nachdem eine CSR signiert wurde, bedeutet, dass man die SAN-Informationen des Zertifikats nicht in den signierten Teil einfügen kann. Daher müssen die SAN-Informationen am Ende der CSR hinzugefügt werden. Bei dieser Methode werden die SAN-Informationen der CSR in Form eines Zertifikatsanforderungsattributs hinzugefügt. Ein Zertifikatsanforderungsattribut kann in diesem Fall nur außerhalb des signierten Teils der ursprünglichen Anforderung liegen und gilt daher nicht als sicher. Das Hinzufügen von SAN-Informationen auf diese Weise bedeutet, dass die SAN-Informationen jederzeit und von jedem geändert werden können. Dies wird in der Regel nicht als sicher angesehen und ist der Grund, warum Microsoft und CSS dringend vor dieser Methode warnen.
Leider haben viele Administratoren ihren CSR-Workflow genau so strukturiert. Eine CSR wird von einem Anwendungsteam erstellt und dann zur Unterzeichnung an den Zertifikatsbeauftragten gesendet. Der Zertifikatsbeauftragte fügt dann alle entsprechenden SAN-Informationen zur Anforderung hinzu, signiert die CSR und sendet das signierte Zertifikat zurück. Kommt Ihnen das bekannt vor?
Leider sehe ich diese Art von Konfiguration nur allzu oft. Und bis zu einem gewissen Grad ist das auch verständlich.
Aber was ist die Alternative?
In der Vergangenheit habe ich vorgeschlagen, dass der beste Ansatz darin besteht, sicherzustellen, dass das Anwendungsteam weiß, wie die entsprechenden SAN-Informationen lauten sollten, und dafür zu sorgen, dass alle SAN-Informationen als Teil des CSR-Generierungsprozesses aufgenommen werden. Ablehnung aller CSRs, denen die entsprechenden SAN-Informationen fehlen, und Unterzeichnung nur derjenigen, die korrekt sind.
Das ist immer noch ein guter Rat.
Aber für die Umgebungen, in denen dieser Ansatz einfach nicht funktioniert, gibt es vielleicht eine Alternative.
Rücktritt der CSRs
Eine sicherere Option zum Hinzufügen von SAN-Informationen zu einer bereits signierten CSR ist die Verwendung eines EA-Zertifikats (Enrollment Agent), um die ursprüngliche Anforderung erneut zu signieren. Sie können dann die richtigen SAN-Informationen angeben und die ursprüngliche Anforderung mit dem EA-Zertifikat neu signieren.
Dadurch können die SAN-Informationen nach der ursprünglichen Erstellung des Zertifikats aufgenommen werden, aber immer noch in einem signierten Teil einer CSR enthalten sein.
So geht's:
- Erwerben Sie ein Enrollment Agent Zertifikat
- Ändern Sie eine SSL Zertifikatsvorlage so, dass ein EA-Zertifikat für die Ausstellung erforderlich ist.
- Erwerben Sie einen CSR, der SAN-Informationen benötigt
- Verwenden Sie das EA-Zertifikat, um die CSR zurückzutreten, während Sie die SAN-Informationen hinzufügen.
Im Folgenden finden Sie einen kurzen Überblick über diese 4 Schritte. Dieser Blog ist keine präskriptive Anleitung, sondern soll einen Überblick über den Prozess geben.
1.) Erwerben Sie ein Zertifikat für die Zulassungsstelle
Dies ist ein Zertifikat, das auf der Standardvorlage des Registrierungsagenten basiert. Das resultierende EA-Zertifikat muss die Anwendungsrichtlinienerweiterung "Certificate Request Agent" enthalten. (1.3.6.1.4.1.311.20.2.1.)
Dieses Zertifikat (und der zugehörige private Schlüssel) sollten sich auf einer Arbeitsstation befinden, auf die der Administrator Zugriff hat. Es ist dieses Zertifikat, das ein Zertifikatsbeauftragter auswählen würde, wenn er während des Resignierungsprozesses gefragt wird.
2.) Änderung einer SSL Zertifikatsvorlage, um ein EA-Zertifikat für die Ausstellung zu verlangen
Ändern Sie Ihre bestehende SSL Vorlage so, dass eine EA-Signatur erforderlich ist. Diese Vorlage sollte auch so konfiguriert werden, dass der Betreff in der Anfrage selbst akzeptiert wird.
Das bedeutet, dass nur diejenigen, die über ein EA-Zertifikat verfügen, diese Vorlage verwenden können. Und obwohl eingeschränkte Registrierungsagenten nicht das Thema dieses Blogbeitrags sind, könnten Sie in Erwägung ziehen, einen bestimmten Registrierungsagenten für die spezielle SSL Vorlage anzugeben, die für diese Übung getestet wird.
3.) Erwerben Sie einen CSR, der SAN-Informationen benötigt
Die Erstellung eines CSR kann auf unzählige Arten erfolgen. In diesem Blogbeitrag wird davon ausgegangen, dass ein CSR bereits existiert. Hier ist ein Überblick über einen bestehenden CSR:
PKCS10 Certificate Request:
Version: 1
Subject:
CN=Demonstration Web Server v1
Name Hash(sha1): ded0833a1bb48a7a747a06598988c9e12ef97342
Name Hash(md5): bd27f43381a77a239a935f86206424e5
2.5.29.17: Flags = 0, Length = 1f
Subject Alternative Name
DNS Name=Banana.css-vstc.com
DNS Name=Banana
Signature matches Public Key
Key Id Hash(rfc-sha1): bc bd 57 27 3a cc 63 79 01 dc 57 9c 2e 38 05 37 09 55 7b 2c
Key Id Hash(sha1): 53 bb 85 45 53 3f 9a ef aa 59 08 91 37 da b1 c7 c4 29 9d 2d
Wie Sie sehen können, hat dieser CSR einen Betreff und einen alternativen Namen für den Betreff.
Zu Demonstrationszwecken werden wir die SAN-Informationen ändern.
4.) Verwenden Sie das EA-Zertifikat, um die CSR erneut zu signieren, und fügen Sie die SAN-Informationen hinzu
Mit einer einfachen certreq.exe commandkönnen Sie das EA-Zertifikat verwenden, um die obige Anfrage mit der folgenden Zeile command neu zu signieren:
certreq -policy -config "CA1.csstest.com\CSS Test CA 1" "ORIGINAL-SERVER-REQUEST.REQ" "Server-policy.inf" "Corrected-Server-Request.req"
Wie man sieht, gibt diese command die ursprüngliche Anforderungsdatei an, um eine neue "korrigierte" Anforderungsdatei zu erstellen.
Diese Zeile command gibt eine Richtliniendatei namens "Server-policy.inf" um korrekte neue SAN-Informationen anzugeben. Hier ist, was mein "Server-policy.inf" sieht so aus:
[Extensions]
2.5.29.17 = "{text}"
_continue_ = "[email protected]&"
_continue_ = "DNS=Orange.css-vstc.com"
Wie Sie sehen, handelt es sich dabei nur um eine einfache Textdatei, die die korrigierten SAN-Informationen als Erweiterung enthält.
Das obige certreq command verwendet die Datei "Server-policy.inf" und mein EA-Zertifikat, um die neuen SAN-Informationen hinzuzufügen und dann die ursprüngliche CSR erneut zu signieren und eine neue Datei zu erstellen.
Innerhalb der neuen, resultierenden CSR umhüllt der Prozess die ursprüngliche CSR mit neuen Informationen. Der ursprüngliche CSR-Inhalt ist immer noch vorhanden, er ist nur in den neuen Inhalt eingebettet. Hier sehen Sie in Kurzform, wie die neue (nun umhüllte) CSR aussieht:
PKCS7/CMS Message:
CMSG_SIGNED(2)
CMSG_SIGNED_DATA_CMS_VERSION(3)
Content Type: 1.3.6.1.5.5.7.12.2 CMC Data
PKCS7 Message Content:
================ Begin Nesting Level 1 ================
CMS Certificate Request:
Tagged Attributes: 1
Extensions: 1
2.5.29.17: Flags = 0, Length = 2f
Subject Alternative Name
RFC822 [email protected]
DNS Name=Orange.css-vstc.com
================ Begin Nesting Level 2 ================
Element 0:
PKCS10 Certificate Request:
Version: 1
Subject:
CN=Demonstration Web Server v1
Name Hash(sha1): ded0833a1bb48a7a747a06598988c9e12ef97342
Name Hash(md5): bd27f43381a77a239a935f86206424e5
2.5.29.17: Flags = 0, Length = 1f
Subject Alternative Name
DNS Name=Banana.css-vstc.com
DNS Name=Banana
2.5.29.14: Flags = 0, Length = 16
Subject Key Identifier
bc bd 57 27 3a cc 63 79 01 dc 57 9c 2e 38 05 37 09 55 7b 2c
Signature matches Public Key
Key Id Hash(rfc-sha1): bc bd 57 27 3a cc 63 79 01 dc 57 9c 2e 38 05 37 09 55 7b 2c
Key Id Hash(sha1): 53 bb 85 45 53 3f 9a ef aa 59 08 91 37 da b1 c7 c4 29 9d 2d
---------------- End Nesting Level 2 ----------------
Tagged Content Info: 0
Tagged Other Messages: 0
---------------- End Nesting Level 1 ----------------
Wie Sie sehen können, ist die ursprüngliche CSR immer noch vorhanden, aber jetzt mit neuen SAN-Informationen versehen und mit dem EA-Zertifikat signiert.
Dieser neue CSR würde dann einfach bei der zuständigen Behörde eingereicht werden:
Certreq -submit -config "CA1.csstest.com\CSS Test CA 1" "Corrected-Server-Request.req" "Server.cer"
Die Übermittlung dieses Zertifikats an die CA führt zu einem Zertifikat, dessen SAN-Informationen von einem Certificate Officer aktualisiert werden. Noch wichtiger ist, dass dies ohne das Setzen des Richtlinienflags EDITF_ATTRIBUTESUBJECTALTNAME2" erreicht wird.
In diesem Fall, von Banana.css-vstc.com to Orange.css-vstc.com.
Das Richtlinienmodul der CA wird diese Anfrage nicht ablehnen, da diese neuen SAN-Informationen immer noch in einem signierten Teil der Zertifikatsignierungsanfrage enthalten sind und tatsächlich signiert werden. Diese Lösung führt zu einer CA, deren Sicherheit erhalten bleibt und die gleichzeitig die Flexibilität bietet, SAN-Informationen auf sichere und kontrollierte Weise zu bestehenden CSRs hinzuzufügen.
Zusammenfassung
Wenn Sie für eine Unternehmens-PKI verantwortlich sind und erwägen, das Richtlinienflag "EDITF_ATTRIBUTESUBJECTALTNAME2" auf Ihrer CA zu setzen, um die SAN-Workflow-Anforderungen zu erfüllen, würde ich vorschlagen, dass Sie eine Alternative zu dieser Richtlinieneinstellung in Betracht ziehen.
Ziehen Sie stattdessen die Verwendung eines EA-Zertifikats in Betracht, um CSRs erneut zu signieren und dabei die korrekten SAN-Informationen anzugeben.
Neuunterzeichnung Ihrer CSRs mit Certreq.exe mit einem Enrollment-Agent-Zertifikat ermöglicht das sichere Hinzufügen von SAN-Informationen zu einer CSR *nach* deren Erstellung, aber auf eine Weise, die Ihre PKI nicht anfällig für Impersonationsangriffe macht.
