Nur wenige Unternehmen können sich den Luxus leisten, einen professionellen PKI-Mitarbeiter in Vollzeit zu beschäftigen. Typischer sind die Unternehmen, die diese Aufgabe jemandem zuweisen, der eine andere Hauptaufgabe hat, z. B. AD-Engineering. Daher stelle ich fest, dass viele PKI-Fachleute PKI-Kenntnisse nicht als primäre Qualifikation besitzen. Es ist leicht nachvollziehbar, dass sich in die betrieblichen PKI-Prozesse eine Mentalität des "einfach nur funktionieren lassen" einschleichen kann. Allzu oft übertrumpft die betriebliche Effizienz leicht die wahrgenommenen Sicherheitsrisiken.
Aber wenn ein Ansatz, der nur darauf abzielt, dass es funktioniert, seinen Weg in die Bereitstellung von SAN-Zertifikaten findet, ist es meiner Meinung nach an der Zeit, eine Pause einzulegen und zu überprüfen, was genau auf dem Spiel steht. Dieser Blog hat drei grundlegende Absichten:
- Aufzeigen der Risiken, die mit der falschen Eingabe von alternativen Subjektnamen verbunden sind
- Überprüfen Sie die MS SAN Best Practices (sie sind immer noch relevant)
- Einen besseren Ansatz empfehlen
Aus einer Vielzahl von Gründen ist es nicht ungewöhnlich, dass die Arbeitsabläufe bei der Beantragung von Zertifikaten so weit gehen, dass der Eigentümer der Anwendung oder des Servers eine einfache Zertifikatsanforderung (Certificate Signing Request, CSR) erstellt und diese CSR zur Vervollständigung oder Signatur an eine Zertifizierungsstelle übermittelt. Der Eigentümer der PKI ist für die "Fertigstellung" dieser CSR verantwortlich, indem er der Anforderung den korrekten Hostnamen, die DNS Adressen, die E-Mail-Adresse oder die IP-Adresse hinzufügt. Auf einer Microsoft CA wird dies durch die Aktivierung des “EDITF_ATTRIBUTESUBJECTALTNAME2”
Richtlinienkennzeichen der CA.
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
Durch Setzen dieses Kennzeichens können SAN-Informationen als "Anfrageattribut" aufgenommen werden. Das heißt, nachdem der CSR erstellt wurde, können die Attribute des CSR verwendet werden, um SAN-Informationen nachträglich aufzunehmen, was den oben erwähnten Arbeitsablauf ermöglicht. Diese Einstellungsorgt dafür, dass es"einfach funktioniert".Der Effekt dieser Einstellung ist, dass Anfragen mit einer Vielzahl von Methoden geändert werden können, einschließlich AD/CS Web Enrollment, CertReq und anderen.
Beispiel: certreq -submit -attrib "SAN:DNS=someotherserver.csstest.com" someserver.req someserver.cer
Doch welche Auswirkungen hat diese Konfigurationsoption? Wenn diese Einstellung aktiviert ist, sieht die Richtlinienkonfiguration der Zertifizierungsstelle jetzt etwa so aus:
(Certutil –getreg policy)
EditFlags REG_DWORD = 35014e (3473742)
EDITF_REQUESTEXTENSIONLIST -- 2
EDITF_DISABLEEXTENSIONLIST -- 4
EDITF_ADDOLDKEYUSAGE -- 8
EDITF_BASICCONSTRAINTSCRITICAL -- 40 (64)
EDITF_ENABLEAKIKEYID -- 100 (256)
EDITF_ENABLEDEFAULTSMIME -- 10000 (65536)
EDITF_ATTRIBUTESUBJECTALTNAME2 -- 40000 (262144)
EDITF_ENABLECHASECLIENTDC -- 100000 (1048576)
EDITF_AUDITCERTTEMPLATELOAD -- 200000 (2097152)
Wenn dies in den Richtlinienflags einer Zertifizierungsstelle angezeigt wird, bedeutet dies, dass die Zertifizierungsstelle SAN-Informationen, die in den Anforderungsattributen des Zertifikats enthalten sind, nicht mehr ablehnt. Diese Einstellung gilt also für die gesamte Zertifizierungsstelle und alle anderen Zertifikatsvorlagen, die von dieser Zertifizierungsstelle ausgestellt werden.
Nehmen wir an, diese Einstellung ist in der Zertifizierungsstelle aktiviert, weil das "Web-Team" dies als Teil der SSL Zertifikatsbereitstellung benötigt. Das bedeutet, dass die Zertifizierungsstelle so konfiguriert ist, dass sie Zertifikate sowohl für das Web-Server-Team des Unternehmens ausstellt, dessen Betreff in der Anforderung enthalten sein muss, als auch für die Benutzerzertifikate des Unternehmens, deren Betreff so konfiguriert ist, dass er automatisch aus Active Directory erstellt wird.
Abbildung 1: Konfiguration der CA-Vorlage.
Die benutzerdefinierten Registrierungsanfragen für die Web SSL -Zertifikate funktionieren einwandfrei, und die Benutzer werden automatisch registriert, wie von der Benutzervorlage erwartet. Keine Probleme, richtig?
Vielleicht. Was ist, wenn ein unzufriedener Benutzersaboteur beschließt, böswillig zu handeln? Die Verwendung dieser Flaggeneinstellung bedeutet, dass es in dieser Konfiguration nichts gibt, was einen Benutzer daran hindern würde, zu werden, wer immer er sein möchte, indem er vielleicht das Folgende tut.
Erstellen Sie einen neuen CSR:
certreq -new UserCert.inf UserCert.req
Certreq ist ein weit verbreitetes Dienstprogramm ( command ), mit dem eine CSR erstellt werden kann.
Dieser Prozess verwendet dieselbe Zertifikatsvorlage, für die der Benutzer bereits eine Berechtigung hat.
(Hier ist die referenzierte usercert.inf)
NewRequest]
Exportable=FALSE
KeyLength=2048
KeySpec=1
RequestType=cmc
PrivateKeyArchive=FALSE
[RequestAttributes]
CertificateTemplate=CorporateUserCertificate
Reichen Sie diesen CSR bei der zuständigen Behörde ein.
Certreq -submit -config "CA.csstest.com\CSS Test CA 1" UserCert.req UserCert.cer
Daraus ergibt sich ein CA-signiertes Zertifikat, dessen Betreff CN=Alice User enthält. Das automatisch hinzugefügte SAN würde wie folgt aussehen: [email protected].
Und da die Vorlage "CorporateUserCertificate" so konfiguriert ist, dass sie die automatische Registrierung verwendet, werden die daraus resultierenden Zertifikate automatisch genehmigt. Es ist keine Genehmigung durch einen Zertifikatsbeauftragten erforderlich.
Abbildung 2: Typisches Benutzerzertifikat für Alice.
Dies ist ein ziemlich unkomplizierter Prozess.
Was aber, wenn Alice böswillig gehandelt hat? Was wäre, wenn sie dieselbe Anfragedatei nehmen und sie erneut einreichen würde?
Übermitteln Sie die CSR an die CA, jetzt in böser Absicht.
Dieselbe Anfragedatei wie oben, aber zusätzlich zum automatischen Auffüllen des alternativen Namens des Betreffs des Zertifikats aus AD, fügen wir unseren eigenen Namen in Form eines CSR-Anforderungsattributs hinzu. So geht's.
Certreq -submit -config "CA.csstest.com\CSS Test CA 1" -attrib "SAN:[email protected]&[email protected]" UserCert.req UserCert.cer
Nun, wegen der CA's ”EDITF_ATTRIBUTESUBJECTALTNAME2”
gesetzt ist, und die Tatsache, dass die "CorporateUserCertificate" Vorlage keine Genehmigung erfordert, konnte Alice Bobs UPN willkürlich zu ihrem eigenen Zertifikat hinzufügen. Auch wenn die Vorlage diese Informationen von AD hat.
Abbildung 3: Alice hat Bobs UPN zu ihrem Zertifikat hinzugefügt.
Tatsächlich ist Alice jetzt sowohl Bob als auch Alice. Oder nur Bob, oder nur Eve, oder der CFO, oder wer auch immer. Man kann sich vorstellen, dass dieses Verfahren für Malware oder einen böswilligen Benutzer interessant sein könnte.
Auch dies ist die Benutzerzertifikat für Unternehmen Vorlage, die nur für die automatische Anmeldung von Unternehmensbenutzern gedacht ist. Alle benutzerdefinierten SAN-Einträge sollen nur für die anderen Benutzer verwendet werden. Unternehmens-Webserver Zertifikate, sondern weil die EDITF_ATTRIBUTESUBJECTALTNAME2
Einstellung gilt für die gesamte CA, alle Alle Vorlagen und alle daraus resultierenden Zertifikate sind von Imitationsangriffen bedroht.
Aus diesem Grund empfiehlt Microsoft u. a. Folgendes:
"Aktivieren Sie EDITF_ATTRIBUTESUBJECTALTNAME2 nicht auf einer Unternehmens-CA."
Ich schließe mich dieser Empfehlung an und empfehle jedem, die gesamten Empfehlungen von Microsoft zu lesen und sich mit ihnen vertraut zu machen. Microsoft Security Best Practices für die Zulassung von SANs in Zertifikaten
Ich würde vorschlagen, dass zusätzlich zu diesen bewährten Praktiken, Unternehmen, die das EDITF_ATTRIBUTESUBJECTALTNAME2
Flagge Folgendes tun:
- Tun Sie das nicht
- Stellen Sie stattdessen sicher, dass es aktuelle Richtlinien für den Inhalt von Zertifikaten für App-Besitzer gibt
- Sicherstellen, dass es festgelegte Verfahren für die Anforderung von Zertifikaten mit dem richtigen Inhalt gibt
- Alle Informationen zum Zertifikatsgegenstand (einschließlich SAN) sollten in der ursprünglichen Zertifikatsanforderung enthalten sein.
- Alle Zertifikate mit benutzerdefinierten SAN-Anforderungen sollten vor der Unterzeichnung durch die CA von einem Zertifikatsbeauftragten geprüft und genehmigt werden.
Es ist von entscheidender Bedeutung, dass Unternehmen die Art und Weise, wie Anwendungseigentümer Zertifikate anfordern, neu bewerten, um die mit benutzerdefinierten SAN-Informationen verbundenen Risiken zu minimieren, selbst wenn dies einen auf "Just Make It Work" basierenden Zertifikats-Workflow beeinträchtigt.