Grundlagen: Namenseinschränkungen (Name Constraints)

Autor Uwe GradeneggerVeröffentlicht am Kategorien Security, Zertifizierungsstelle, Zertifizierungsstellen-InstallationSchlagwörter , , , , , , ,

Namenseinschränkungen sind ein Teil des X.509 Standard und im RFC 5280 beschrieben. Sie sind ein Werkzeug, das im Rahmen der qualifizierten Subordinierung eingesetzt werden kann, um den Gültigkeitsbereich eines Zertifizierungsstellenzertifikats feingranular zu steuern.

Exkurs qualifizierte Subordinierung

Ziel der qualifizierten Subordinierung ist die Einschränkung, inwieweit einer Zertifizierungsstelle oder einer Zertifizierungsstellen-Hierarchie Vertrauen eingeräumt wird.

Komponenten der Qualifizierten Subordinierung können sein:

KomponenteBeschreibung
Einschränkung der Pfadlänge
(Path Length Constraint)		Hiermit lässt sich festlegen, wie viele Hierarchie-Ebenen (also untergeordnete Zertifizierungsstellen) nach der betreffenden Zertifizierungsstelle folgen dürfen.
Einschränkungen der erweiterten Schlüsselverwendung (Extended Key Usage Constraints)Hiermit lässt sich festlegen, welche erweiterten Schlüsselverwendungen in von der Zertifizierungsstelle ausgestellten Zertifikaten akzeptiert werden dürfen.
Einschränkungen der Ausstellungsrichtlinien (Issuance Policies)Hiermit lässt sich festlegen, für welche Zertifikatrichtlinien die Zertifizierungsstelle deren Konformiität in ausgestellten Zertifikaten bestätigen darf.
Namenseinschränkungen (Name Constraints)Hiermit lässt sich festlegen, für welche Namensräume die Zertifizierungsstelle Zertifikate ausstellen darf.

Motivation für den Einsatz

Nicht vergessen: PKI ist ein verteiltes System. Die Stammzertifizierungsstelle kann zu einer anderen Organisation gehören als die untergeordneten Zertifizierungsstellen.

Motivatoren für den Einsatz von Namenseinschränkungen können beispielsweise sein:

  • Als PKI-Betreiber delegiert man Zertifizierungsstellen-Zertifikate an seine Kunden und möchte deren Verwendungsbereich eingrenzen, um Missbrauch vorzubeugen.
  • Man betreibt eine Zertifizierungsstelle, deren Zertifikatausstellung an dritte delegiert wird. Beispiele hierfür wären manuell gestellte Zertifikatanforderungen, solche, die über den Registrierungsdienst für Netzwerkgeräte gestellt werden, oder solche, die durch Mobile Device Management (MDM) Systeme gestellt werden.
  • Man möchte das Schadenspotential bei Kompromittierung einer Zertifizierungsstelle begrenzen.

Ein gutes Beispiel für die konsequente Anwendungen von qualifizierter Subordinierung und insbesondere Namenseinschränkungen ist die Bayerische SSL-CA-2015-01, deren CA-Zertifikat öffentlich einsehbar ist.

Spezifikation im RFC

Namenseinschränkungen sind im RFC 5280 spezifiziert. Sie können ausschließlich auf untergeordnete Zertifizierungsstellenzertifikate angewendet werden.

Die definierten Einschränkungen können in Form einer Liste erlaubter und/oder in Form einer Liste verbotener Namensräume für den Subject Distinguished Name und die Subject Alternative Names ausgestellter Zertifikate festgelegt werden. Sofern verbotene Namensräume definiert sind, haben diese Vorrang vor erlaubten Namensräumen.

Folgende Arten von Einschränkungen sind unter Anderem möglich:

TypBeschreibung
directoryNameEinschränkungen der Relative Distinguished Names (RDNs) im Subject Distinguished Name.
rfc822NameEinschränkungen der E-Mail Adressen im Subject Alternative Name.
uniformResourceIdentifierEinschränkungen von URLs im Subject Alternative Name.
dNSNameEinschränkungen von DNS-Namen im Subject Alternative Name.
iPAddressEinschränkungen von IP-Adressen im Subject Alternative Name.

Als Minimum fordert das RFC, dass Anwendungen, die Zertifikate prüfen, mindestens Einschränkungen auf den directoryName verstehen und empfiehlt, dass auch mindestens der rfc822Name, uniformResourceIdentifier, dNSName und iPAddress verstanden werden.

Bitte beachten, dass die Namenseinschränkungen nicht das Vorhandensein eines der definierten Subject oder Subject Alternative Name Teils Inhaltes erzwingen können. Ist der definierte Teil in der Zertifikatanforderung nicht vorhanden, gilt dies als gültig (teils sind Einschränkungen möglich):

Restrictions apply only when the specified name form is present. If no name of the type is in the certificate, the certificate is acceptable.

https://tools.ietf.org/html/rfc5280#section-4.2.1.10

Damit alle Teilnehmer möglichst eine gemeinsame Sprache sprechen, werden Standards von der IETF in RFCs (engl. Request for Comment) festgelegt. Das für Zertifikatprofile in der PKI einschlägige RFC 5280 fordert unmissverständlich, dass die "Name Constraints" Zertifikaterweiterung als kritisch markiert sein muss.

Conforming CAs MUST mark this extension as critical

https://tools.ietf.org/html/rfc5280#section-4.2.1.10

Anwendungen, die die Zertifikatkette prüfen und die "Name Constraints" Zertifikaterweiterung nicht kennen, werden sie also nicht verarbeiten können und somit die ausgestellten Zertifikate nicht akzeptieren können.

Hinweis zur Kompatibilität: Apple spielt nicht mit

Für Mac OS wurde die korrekte Verarbeitung von Namenserweiterungen mit Version 10.13.3 umgesetzt. Es gibt unbestätigte Hinweise, dass Namenseinschränkungen mittlerweile von Apple iOS unterstützt werden könnten.

Wie oft im Bereich Public Key Infrastruktur heißt es hier wieder einmal: "Es kommt immer auf die Implementierung in der Anwendung an".

Und leider gibt es hier das Problem, dass alle Apple-Produkten nicht konform zum RFC 5280 sind, da sie keine Namenseinschränkungen unterstützen. Entsprechend werden sie Zertifikate von korrekt eingeschränkten Zertifizierungsstellen ablehnen (immerhin ist dieser Teil RFC-konform umgesetzt).

Applications conforming to this profile MUST be able to process name constraints […] the application MUST either process the constraint or reject the certificate.

https://tools.ietf.org/html/rfc5280#section-4.2.1.10

Da Apple den Browser- und Appherstellern auch nicht die Wahl lässt, eigene Crypto-Programmier-Bibliotheken einzusetzen, können also entweder keine Apple Geräte mit Namenseinschränkungen verwendet werden oder keine Namenseinschränkungen mit Apple Geräten.

Der einzig verbleibende Ausweg auf Seite der PKI wäre, gegen das RFC zu verstoßen und die Erweiterung für Namenseinschränkungen nicht als kritisch zu markieren.

Die zuvor als positives Beispiel genannte Bayerische SSL-CA-2015-01 macht übrigens genau das und hält sich somit nicht vollständig an das RFC 5280, da die Erweiterung für Namenseinschränkungen im Zertifizierungsstellen-Zertifikat eben nicht als kritisch markiert ist – der Grund ist offensichtlich.

Die gleiche Aussage findet sich auch bei einem der Erfinder der Active Directory Certififcate Services, welcher auch in der IETF als Vertreter von Microsoft auftrat:

For customers this means if you must interoperate with Opera or Safari (yes even on iPad and iPhone) the use of a certificate with a “Critical” “Name Constraints extension” in it will result in the certificate chain looking invalid. […] This issue can be addressed by not marking the extension Critical, when this is done the clients that understand Name Constraints will continue to honor the policies expressed in it and those that do not will simply ignore the extension. This is of course a trade-off of security in exchange for compatibility, with that said one with far more positive trade-offs than negative ones.

Least Privilege and Subordinate Certificate Authorities (Ryan Hurst)

Umsetzung in der Microsoft PKI

Microsoft Active Directory Certificate Services wird die Ausstellung von Zertifikaten, die gegen die Namenseinschränkungen verstoßen, verweigern. Dies lässt sich jedoch mit dem Flag CRLF_IGNORE_INVALID_POLICIES abschalten (nicht empfohlen), oder es ließen sich auch direkt Zertifikate unter direkter Verwendung des privaten Schlüssels ausstellen. Namenseinschränkungen haben somit nicht (nur) das Ziel, die Ausstellung ungültiger Zertifikate zu verhindern, sondern deren (Nicht-)Akzeptanz bei denjenigen, welche diese überprüfen bzw. verwenden sollen, sicherzustellen.

Die Namenseinschränkungen werden in das Zertifizierungsstellen-Zertifikat der betreffenden Zertifizierungsstelle geschrieben (sie werden von der jeweils übergeordneten Instanz festgelegt).

Die Einschränkungen können entweder in den Zertifikatantrag der betreffenden Zertifizierungsstelle (capolicy.inf) eingetragen werden, oder die übergeordnete Zertifizierungsstelle wendet eine entsprechende Konfiguration an, bevor sie das Zertifizierungsstellen-Zertifikat ausstellt.

Die Definition sieht in Grundkonstrukt wie folgt aus:

[NameConstraintsExtension]
Include = PermittedSubtrees
Exclude = ExcludedSubtrees
Critical = True

[PermittedSubtrees]
; Direktiven hier

[ExcludedSubtrees]
; Direktiven hier

Die Definition kann auch in folgender alternativer Schreibweise erfolgen:

[Strings]
szOID_NAME_CONSTRAINTS = "2.5.29.30"
  
[Extensions]
Critical = %szOID_NAME_CONSTRAINTS%
%szOID_NAME_CONSTRAINTS% = "{text}"
_continue_ = "SubTree=Include&"
_continue_ = ; Direktiven hier, jede Zeile mit & beenden
_continue_ = "SubTree=Exclude&"
_continue_ = ; Direktiven hier, jede Zeile mit & beenden

Möglich sind folgende Direktiven:

Definition nach RFC 5280Eintrag in capolicy.infBeispiel
directoryName (Subject)DirectoryNameDC=intra,DC=adcslabor,DC=de
dNSName (SAN)DNSintra.adcslabor.de
.intra.adcslabor.de
rfc822Name (SAN)
emailAddress (Subject)		Email@adcslabor.de
.adcslabor.de
iPAddress (SAN)IPAddress10.0.0.0, 255.0.0.0
172.16.0.0, 255.255.0.0
192.168.0.0, 255.255.255.0
(nicht spezifiziert) userPrincipalNameUPNintra.adcslabor.de
.intra.adcslabor.de

Die SAN-Type userPrincipalName ist nicht im RFC 5280 spezifiziert, da er proprietär zum Microsoft-Ökosystem gehört. Es ist daher nicht garantiert, dass andere PKI-Implementierungen ihn korrekt (oder überhaupt) interpretieren können.

Es ist außerdem möglich, das "empty" Schlüsselwort zu spezifizieren. Mit diesem können bestimmte Subject Alternative Name Typen explizit untersagt werden. Für den directoryName Typen ist diese Direktive nicht verwendbar. Für den Bereich erlaubter Namensräume hat das Schlüsselwort keinen Effekt.

Hinweis zu einigen fehlerhaften Dokumentationen

Gängige Dokumentationen behaupten, dass es erforderlich sei, dass ein Punkt vor einen definierten DNS-Namensraum zu setzen ist, um beispielsweise Subdomänen zu erlauben. Tatsächlich ist dies aber gar nicht erforderlich. Siehe hierzu die entsprechende Passage im einschlägigen RFC.

DNS name restrictions are expressed as host.example.com. Any DNS name that can be constructed by simply adding zero or more labels to the left-hand side of the name satisfies the name constraint. For example, www.host.example.com would satisfy the constraint but host1.example.com would not.

https://tools.ietf.org/html/rfc5280

Effektiv kann der Antragsteller bzw. die Zertifizierungsstelle den "linken" Teil des DNS-Namens frei wählen, inklusive Subdomänen.

Es ist jedoch durchaus sehr sinnvoll, einen Punkt voranzusetzen da somit nur die Ausstellung von Identitäten unterhalb der angegebenen Domain erlaubt wird, nicht aber für die Domain selbst.

Problemfall Subject Distinguished Name

Richtet man Name Constraints nur für DNS-Namen ein, können weiterhin alle beliebigen Identitäten als Subject Distinguished Name beantragt werden. Die einzige Möglichkeit, den Subject Distinguished Name einzuschränken ist, Einschränkungen vom Typ "directoryName" zu definieren.

Es ist mit diesem aber nicht möglich, für den commonName, der nur ein Teil des Subject Distinguished Name ist und aus welchem in vielen Fällen die Identität gebildet wird, Einschränkungen festzulegen. Entweder man erlaubt alle Werte oder gar keine.

Somit ist es nicht möglich, den commonName auf bestimmte Identitäten (z.B. nur Hosts unterhalb von intra.adcslabor.de) einzuschränken.

Sinnvolle Ausnahmen

Es gibt einige Zertifikattypen, die für den Zertifizierungsstellenbetrieb notwendig sind und deren Subject Distinguished Names daher immer in die Liste für erlaubte directoryNames aufgenommen werden sollten:

ZertifikattypBeschreibung
ZertifizierungsstellenaustauschWird grundsätzlich von der Zertifizierungsstelle ausgestellt. Beinhaltet den commonName der Zertifizierungsstelle mit einem "-Xchg" Suffix sowie alle weiteren RDNs die auch im Zertifizierungsstellenzertifikat vorkommen.
Fehlt die Ausnahme hierfür, können diese Zertifikate nicht generiert werden. Dadurch landen regelmäßig fehlgeschlagene Zertifikatanforderungen in der Datenbank und die pkiview.msc ist nicht vollständig benutzbar.
Zertifikatregistrierungs-AgentWird für die Registration Authority Zertifikate des Registrierungsdienstes für Netzwerkgeräte benutzt.
Fehlt die Ausnahme hierfür, kann NDES nicht mit dieser Zertifizierungsstelle verwendet werden.
OnlineresponderWird für die Antwortsignaturzertifikate des Onlineresponders verwendet.
Fehlt die Ausnahme hierfür, kann kein Onlineresponder mit dieser Zertifizierungsstelle verwendet werden.

Eine Lösung für manche (aber nicht alle) Fälle

Versuchen wir im folgenden Beispiel also, Namenseinschränkungen für eine Zertifizierungsstelle, die ausschließlich Webserver-Zertifikate ausstellen soll, festzulegen.

Nehmen wir an, wir möchten eine Zertifizierungsstelle einschränken, die nur Zertifikate für Hostnamen innerhalb der DNS Domain intra.adcslabor.de ausstellen soll. Wir wissen, dass wir den commonName nicht sinnvoll einschränken können.

Die Eintragung von Servernamen im Subject war bei der Definition des X.509 Standards auch auch gar nicht vorgesehen. Daher fordert das RFC 2818 für HTTPS auch bereits seit dem Jahr 2000 die Verwendung des Subject Alternative Name im Form des dNSName Attributs anstelle des commonName im Subject.

If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.

https://tools.ietf.org/html/rfc2818

Das RFC 5280 spezifiziert wiederum, dass in einem sollchen Fall das Subject Feld leer sein darf:

Further, if the only subject identity included in the certificate is an alternative name form (e.g., an electronic mail address), then the subject distinguished name MUST be empty (an empty sequence), and the subjectAltName extension MUST be present. If the subject field contains an empty sequence, the subjectAltName extension MUST be marked critical.

https://tools.ietf.org/html/rfc5280

The subject field identifies the entity associated with the public key stored in the subject public key field. The subject name MAY be carried in the subject field and/or the subjectAltName extension.
[…]
If subject naming information is present only in the subjectAltName extension (e.g., a key bound only to an email address or URI), then the subject name MUST be an empty sequence and the subjectAltName extension MUST be critical.

https://tools.ietf.org/html/rfc5280

Man könnte für diesen Anwendungsfall also immerhin eine Namenseinschränkung für ein Zertifizierungsstellen-Zertifikat definieren, welches keine commonNames im Subject akzeptiert – was in Hinsicht auf das RFC2818 (und somit nur im Sinne von Webserver-Zertifikaten) aber völlig akzeptabel wäre.

Dies funktioniert folglich nur, wenn die Zertifizierungsstelle ausschließlich für Webserver-Zertifikate eingesetzt wird. Die Identitäten in den Zertifikaten können ausschließlich im Subject Alternative Name in Form eines dNSName (oder einer iPAddress abgebildet werden, was hier aber nicht behandelt wird).

Es muss also unbedingt ein Directory Name Constraint gesetzt werden, damit keine unzulässigen, sondern nur die definierten commonNames in der Zertifikatanforderung verwendet werden kann.

Das Ziel kann beispielsweise dadurch realisiert werden, dass der Constraint bei den erlaubten Namensräumen auf einen vordefinierten Wert gesetzt wird, z.B. "CN=INVALID". Damit ist entweder nur noch ein leerer Subject Distinguished Name oder einer der definierten Werte möglich. Es reicht grundsätzlich aber aus, wenn eine der Ausnahmen für die oben beschriebene Fälle vorhanden ist, um dieses Ziel zu ereichen.

Ein entsprechender Inhalt in einer minimalen capolicy.inf sähe wie folgt aus:

[Version]
Signature= "$Windows NT$"

[Strings]
szOID_NAME_CONSTRAINTS = "2.5.29.30"

[Extensions]
Critical = %szOID_NAME_CONSTRAINTS%
%szOID_NAME_CONSTRAINTS% = "{text}"
_continue_ = "SubTree=Include&"
_continue_ = "DNS = .intra.adcslabor.de&"
_continue_ = "DIRECTORYNAME = CN=ADCS Labor Test Issuing CA 1-Xchg&"

[Certsrv_Server]
LoadDefaultTemplates=0

Zusätzlich ist es sehr empfehlenswert, die Extended Key Usages für die Zertifizierungsstelle derart einzuschränken, dass nur die definierten Anwendungsfälle unterstützt werden. Ebenso ist eine Einschränkung der Pfadlänge sehr sinnvoll.

Funktionstest

Für den Test lassen wir uns ein Zertifizierungsstellen-Zertifikat mit den definierten Einschränkungen ausstellen.

Die Tests wurden mit dem PSCertificateEnrollment PowerShell Modul durchgeführt.

Beantragen wir ein Zertifikat für einen DNS Namen innerhalb von intra.adcslabor.de, wird die Zertifikatanforderung genehmigt.

Beantragen wir ein Zertifikat für einen DNS Namen innerhalb einer nicht definierten DNS Domäne, wird die Zertifikatanforderung erwartungsgemäß abgelehnt.

Beantragen wir ein Zertifikat für einen DNS Namen innerhalb von intra.adcslabor.de, und einem nicht definierten commonName wird die Zertifikatanforderung erwartungsgemäß abgelehnt.

Einschätzung zur Praxistauglichkeit

Namenseinschränkungen erlauben eine gewisse Einflussnahme auf den Zertifikatinhalt. Vorteilhaft ist, dass Verstöße auch beim Überprüfen eines Zertifikats bei der Zertifikatprüfung erkannt werden (…können – wenn implementiert) und solche Zertifikate dann nicht akzeptiert würden.

Die Einschränkungen können allerdings nur lückenhaft umgesetzt werden. Beispielsweise ist es nur möglich, die Zertifikatausstellung auf Identitäten innerhalb bestimmter DNS-Namensräume einzuschränken. Welche Identitäten hier aber beantragt werden, kann nicht eingeschränkt werden.

Ebenso sollte nicht vergessen werden, dass das RFC nur fordert, dass Einschränkungen auf den directoryName verstanden werden. Es kann also nicht garantiert werden, dass alle teilnehmenden Anwendungen auch die anderen Typen verstehen.

Generell ist das ganze Konstrukt natürlich auch sehr unflexibel, da im Nachhinein keine Änderungen möglich sind, ohne das Zertifizierungsstellen-Zertifikat neu zu signieren.

Eine flexiblere Alternative kann das TameMyCerts Policy Modul für die Zertifizierungsstelle sein.

Fazit

Für manche Fälle sind Namenseinschränkungen gemäß RFC 5280 somit völlig ungeeignet. Auch wenn keine technischen Hindernisse bestehen, eignen sie sich nur bedingt für Fälle, bei denen der Antragsteller die Identität im Zertifikatantrag mitbringen kann.

Weiterführende Links:

Externe Quellen

de_DEDeutsch
en_USEnglish de_DEDeutsch