Bases : Contraintes de nom (Name Constraints)

Les restrictions de noms font partie de la norme X.509 et sont définies dans le RFC 5280 ont été décrits. Ils constituent un outil qui peut être utilisé dans le cadre subordination qualifiée peut être utilisé pour contrôler finement la portée d'un certificat d'autorité de certification.

Digression sur la subordination qualifiée

L'objectif de la subordination qualifiée est de limiter le degré de confiance accordé à une autorité de certification ou à une hiérarchie d'autorités de certification.

Les composantes de la subordination qualifiée peuvent être :

Composant	Description
Limitation de la longueur du chemin (Contrainte de longueur de chemin)	Cela permet de définir combien de niveaux hiérarchiques (donc d'autorités de certification subordonnées) peuvent suivre l'autorité de certification concernée.
Limitations de l'utilisation étendue des clés (Extended Key Usage Constraints)	Il permet de définir les utilisations de clés étendues qui peuvent être acceptées dans les certificats délivrés par l'autorité de certification.
Restrictions des politiques d'exposition (Issuance Policies)	Cela permet de définir les directives de certification pour lesquelles l'organisme de certification peut confirmer la conformité dans les certificats délivrés.
Restrictions de nom (Contraintes de nom)	Cette option permet de définir les espaces de noms pour lesquels l'autorité de certification peut émettre des certificats.

Connaissez-vous TameMyCerts? TameMyCerts est un add-on pour l'autorité de certification Microsoft (Active Directory Certificate Services). Il étend la fonction de l'autorité de certification et permet de Application de la réglementationIl s'agit d'un logiciel de gestion des certificats qui permet d'automatiser l'émission de certificats en toute sécurité. TameMyCerts est unique dans l'écosystème Microsoft, a déjà fait ses preuves dans d'innombrables entreprises du monde entier et est disponible sous une licence libre. Il peut téléchargé via GitHub et être utilisé gratuitement. Une maintenance professionnelle est également proposée.

Motivation pour l'engagement

Ne pas oublier que : La PKI est un système distribué. L'autorité de certification racine peut appartenir à une autre organisation que les autorités de certification subordonnées.

Les motivations pour l'utilisation de restrictions de nom peuvent être par exemple

En tant qu'opérateur PKI, vous déléguez des certificats d'autorité de certification à vos clients et souhaitez limiter leur champ d'utilisation afin d'éviter les abus.
On gère une autorité de certification dont la délivrance des certificats est déléguée à des tiers. Par exemple, les demandes de certificats faites manuellement, celles qui sont envoyées par le biais de l'interface de l'autorité de certification. Service d'enregistrement des périphériques réseau ou ceux fournis par les systèmes de gestion des appareils mobiles (MDM).
On souhaite limiter les dommages potentiels en cas de compromission d'une autorité de certification.

Un bon exemple de l'utilisation systématique de la subordination qualifiée, et en particulier des restrictions de nom, est le SSL-CA-2015-01 bavaroisLes certificats de l'autorité de certification peuvent être consultés par le public.

Spécification dans le RFC

Les restrictions de nom sont indiquées dans le RFC 5280 ne sont pas spécifiées. Ils ne peuvent être appliqués qu'à des certificats d'autorité de certification subordonnés.

Les restrictions définies peuvent prendre la forme d'une liste d'espaces de noms autorisés et/ou d'une liste d'espaces de noms interdits pour le Subject Distinguished Name et les Subject Alternative Names des certificats délivrés. Si des espaces de noms interdits sont définis, ils ont la priorité sur les espaces de noms autorisés.

Les types de restrictions suivants sont notamment possibles :

Type	Description
directoryName	Restrictions de la Noms distinctifs relatifs (RDN) dans le Subject Distinguished Name.
rfc822Nom	Restrictions des adresses e-mail dans le Subject Alternative Name.
uniformResourceIdentifier	Restrictions des URLs dans le Subject Alternative Name.
dNSName	Restrictions sur les noms DNS dans le Subject Alternative Name.
iPAddress	Restrictions des adresses IP dans le Subject Alternative Name.

Au minimum, le RFC exige que les applications qui vérifient les certificats comprennent au moins les restrictions sur le directoryName et recommande qu'elles comprennent également au moins le rfc822Name, uniformResourceIdentifier, dNSName et iPAddress.

Veuillez noter que les restrictions de nom ne peuvent pas forcer la présence d'un des contenus de la partie Subject ou Subject Alternative Name définie. Si la partie définie n'est pas présente dans la demande de certificat, cela est considéré comme valable (des restrictions sont parfois possibles) :

Les restrictions ne s'appliquent que si le formulaire de nom spécifié est présent. Si aucun nom de type ne figure dans le certificat, le certificat est acceptable.
https://tools.ietf.org/html/rfc5280#section-4.2.1.10

Afin que tous les participants parlent le même langage, les normes sont définies par l'IETF dans des RFC (Request for Comment). La norme applicable aux profils de certificats dans l'infrastructure à clé publique (PKI) est la suivante RFC 5280 exige sans équivoque que l'extension de certificat "Name Constraints" soit marquée comme critique.

Conforming CAs MUST mark this extension as critical
https://tools.ietf.org/html/rfc5280#section-4.2.1.10

Les applications qui vérifient la chaîne de certificats et qui ne connaissent pas l'extension de certificat "Name Constraints" ne pourront donc pas la traiter et ne pourront donc pas accepter les certificats émis.

Remarque sur la compatibilité : Apple ne joue pas le jeu

Pour Mac OS, le traitement correct des extensions de nom a été amélioré. avec la version 10.13.3 a été mis en œuvre. Il y a des indices non confirmésIl est possible que les restrictions de noms soient désormais prises en charge par l'iOS d'Apple.

Comme souvent dans le domaine de l'infrastructure à clé publique, on peut dire une fois de plus que "tout dépend de l'implémentation dans l'application".

Et Malheureusement, tous les produits Apple ne sont pas conformes à la RFC 5280.car ils ne supportent pas les restrictions de nom. En conséquence, ils refuseront les certificats provenant d'autorités de certification correctement restreintes (après tout, cette partie est mise en œuvre conformément au RFC).

Les applications conformes à ce profil DOIVENT pouvoir traiter les contraintes de nom [...] l'application DOIT soit traiter la contrainte, soit rejeter le certificat.
https://tools.ietf.org/html/rfc5280#section-4.2.1.10

Comme Apple ne laisse pas non plus le choix aux fabricants de navigateurs et d'applications d'utiliser leurs propres bibliothèques de crypto-programmation, il n'est donc pas possible d'utiliser des appareils Apple avec des restrictions de noms, ou pas de restrictions de noms avec des appareils Apple.

La seule solution restante du côté de l'ICP serait d'enfreindre le RFC et de ne pas marquer l'extension pour les restrictions de nom comme critique.

L'exemple positif cité précédemment SSL-CA-2015-01 bavarois fait d'ailleurs exactement cela et ne respecte donc pas complètement le RFC 5280, car l'extension pour les restrictions de nom dans le certificat d'autorité de certification n'est justement pas marquée comme critique - la raison est évidente.

On retrouve la même déclaration chez l'un des inventeurs des Active Directory Certififcate Services, qui a également représenté Microsoft au sein de l'IETF :

Pour les clients, cela signifie que si vous devez interagir avec Opera ou Safari (oui, même sur iPad et iPhone) l'utilisation d'un certificat avec une extension "Critical" "Name Constraints" dans celui-ci aura pour conséquence que la chaîne de certificats aura l'air invalide. [...] Ce problème peut être résolu en ne marquant pas l'extension Critical, si cela est fait, les clients qui comprennent les Name Constraints continueront à respecter les politiques exprimées dans celle-ci et ceux qui ne le font pas ignoreront simplement l'extension. Il s'agit bien entendu d'un compromis de sécurité en échange de la compatibilité, avec bien plus de compromis positifs que négatifs.
Autorités de certification de dernier recours et subordonnées (Ryan Hurst)

Mise en œuvre dans l'infrastructure à clés publiques Microsoft

Microsoft Active Directory Certificate Services refusera d'émettre des certificats qui ne respectent pas les restrictions de nom. Cela peut toutefois être corrigé à l'aide du drapeau CRLF_IGNORE_INVALID_POLICIES désactiver (non recommandé), ou bien on pourrait directement Émettre des certificats en utilisant directement la clé privée. Les restrictions de dénomination n'ont donc pas (seulement) pour objectif de Exposition de certificats non valides, mais d'empêcher leur (non-)utilisation.Acceptation de la part de ceux qui doivent les vérifier ou les utiliser.

Les restrictions de nom sont inscrites dans le certificat d'autorité de certification de l'autorité de certification concernée (elles sont définies par l'instance supérieure respective).

Les restrictions peuvent être intégrées soit dans la demande de certificat de l'autorité de certification concernée (capolicy.inf), ou l'autorité de certification supérieure applique une configuration appropriée avant de délivrer le certificat d'autorité de certification.

La définition se présente comme suit dans la construction de base :

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

[PermittedSubtrees]
; Direktiven hier

[ExcludedSubtrees]
; Direktiven hier

La définition peut également être écrite de la manière alternative suivante :

[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

Les directives suivantes sont possibles :

Définition selon la RFC 5280	Entrée dans capolicy.inf	Exemple
directoryName (Subject)	Nom du répertoire	DC=intra,DC=adcslabor,DC=fr
dNSName (SAN)	DNS	intra.adcslabor.de .intra.adcslabor.de
rfc822Nom (SAN) emailAddress (Sujet)	Email	@adcslabor.de .adcslabor.de
iPAddress (SAN)	IPAddress	10.0.0.0, 255.0.0.0 172.16.0.0, 255.255.0.0 192.168.0.0, 255.255.255.0
(non spécifié) userPrincipalName	UPN	intra.adcslabor.de .intra.adcslabor.de

Le type SAN userPrincipalName n'est pas spécifié dans le RFC 5280, car il appartient de manière propriétaire à l'écosystème Microsoft. Il n'est donc pas garanti que d'autres implémentations PKI puissent l'interpréter correctement (ou même l'interpréter du tout).

Il est également possible de spécifier le mot-clé "empty". Celui-ci permet d'interdire explicitement certains types de Subject Alternative Name. Cette directive n'est pas utilisable pour les types directoryName. Ce mot-clé n'a aucun effet sur les espaces de noms autorisés.

Remarque sur certaines documentations erronées

Courant Documentations prétendent qu'il est nécessaire de placer un point devant un espace de noms DNS défini, par exemple pour autoriser les sous-domaines. En réalité, cela n'est pas nécessaire. Voir à ce sujet le passage correspondant dans le RFC pertinent.

Les restrictions de noms DNS sont exprimées sous la forme host.example.com. Tout nom DNS qui peut être construit en ajoutant simplement zéro ou plusieurs étiquettes à la partie gauche du nom satisfait la contrainte de nom. Par exemple, www.host.example.com satisferait la contrainte mais pas host1.example.com.
https://tools.ietf.org/html/rfc5280

En fait, le demandeur ou l'autorité de certification peut choisir librement la partie "gauche" du nom DNS, y compris les sous-domaines.

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

Problème Subject Distinguished Name

Si l'on met en place des Name Constraints uniquement pour les noms DNS, toutes les identités peuvent continuer à être demandées comme Subject Distinguished Name. La seule possibilité de restreindre le Subject Distinguished Name est de définir des restrictions de type "directoryName".

Il n'est cependant pas possible avec ce dernier de créer un nom de domaine pour le commonName, qui n'est qu'une partie du Subject Distinguished Name et à partir de laquelle l'identité est souvent formée, de fixer des restrictions. Soit on autorise toutes les valeurs, soit on n'en autorise aucune.

Il n'est donc pas possible de restreindre le commonName à certaines identités (par exemple uniquement les hôtes en dessous de intra.adcslabor.de).

Des exceptions judicieuses

Il existe certains types de certificats qui sont nécessaires au fonctionnement de l'autorité de certification et dont les Subject Distinguished Names devraient donc toujours être inclus dans la liste des directoryNames autorisés :

Type de certificat	Description
Échange d'organismes de certification	Est en principe délivré par l'autorité de certification. Contient le commonName de l'autorité de certification avec un suffixe "-Xchg" ainsi que tous les autres RDN qui apparaissent également dans le certificat de l'autorité de certification. Si l'exception pour cela manque, ces certificats ne peuvent pas être générés. De ce fait, des demandes de certificats échouées atterrissent régulièrement dans la base de données et le fichier pkiview.msc n'est pas entièrement utilisable.
Agent d'enregistrement des certificats	Est utilisé pour les Autorité d'enregistrement Certificats du Service d'enregistrement des périphériques réseau utilisé. En l'absence de cette exception, NDES ne peut pas être utilisé avec cette autorité de certification.
Répondant en ligne	Est utilisé pour les certificats de signature de réponse du Onlineresponders est utilisé. En l'absence de cette exception, aucun répondeur en ligne ne peut être utilisé avec cette autorité de certification.

Une solution pour certains cas (mais pas tous)

Dans l'exemple suivant, essayons donc d'appliquer des restrictions de nom à une autorité de certification qui n'utilise que des noms de domaine. Certificats pour serveur web de l'entreprise.

Supposons que nous souhaitions restreindre une autorité de certification qui ne délivre des certificats que pour les noms d'hôtes au sein du domaine DNS intra.adcslabor.de doit émettre. Nous savons que nous ne pouvons pas restreindre le commonName de manière significative.

L'inscription de noms de serveurs dans le sujet n'était d'ailleurs pas prévue lors de la définition de la norme X.509. C'est pourquoi la norme RFC 2818 pour HTTPS, l'utilisation du Subject Alternative Name sous la forme de l'attribut dNSName au lieu du commonName dans le Subject.

Si une extension subjectAltName de type dNSName est présente, elle DOIT être utilisée comme identité. Sinon, le champ Nom commun (le plus spécifique) dans le champ Sujet du certificat DOIT être utilisé. Bien que l'utilisation du nom commun soit une pratique existante, elle est dépréciée et les autorités de certification sont encouragées à utiliser le dNSName à la place.
https://tools.ietf.org/html/rfc2818

Le site RFC 5280 spécifie à nouveau que dans ce cas, le champ Subject peut être vide :

En outre, si la seule identité de sujet incluse dans le certificat est une forme de nom alternative (par exemple, une adresse de courrier électronique), le nom de la distinction du sujet DOIT être vide (une séquence vide) et l'extension du vieux nom du sujet DOIT être présente. Si le champ sujet contient une séquence vide, l'extension subjectAltName DOIT être marquée comme étant critique.
https://tools.ietf.org/html/rfc5280

Le champ sujet identifie l'entité associée à la clé publique stockée dans le champ de la clé publique du sujet. Le nom du sujet PEUT être porté dans le champ sujet et/ou dans l'extension subjectAltName.
[...]
Si l'information sur le nom du sujet n'est présente que dans l'extension subjectAltName (par exemple, une clé liée uniquement à une adresse e-mail ou URI), alors le nom du sujet DOIT être une séquence vide et l'extension subjectAltName DOIT être critique.
https://tools.ietf.org/html/rfc5280

Pour ce cas d'application, on pourrait donc tout de même définir une restriction de nom pour un certificat d'autorité de certification qui n'accepte pas les commonNames dans le Subject - ce qui, au regard du RFC2818 (et donc uniquement dans l'esprit du Certificats de serveur web) mais serait tout à fait acceptable.

Cela ne fonctionne donc que si l'autorité de certification est utilisée exclusivement pour des certificats de serveur web. Les identités dans les certificats peuvent uniquement être représentées dans le Subject Alternative Name sous la forme d'un dNSName (ou d'une iPAddress, ce qui n'est toutefois pas traité ici).

Il faut donc impérativement définir une contrainte Directory Name pour qu'aucun commonName non autorisé ne puisse être utilisé dans la demande de certificat, mais uniquement les commonNames définis.

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 erreichen.

Un contenu correspondant dans un minimum de capolicy.inf ressemblerait à ceci :

[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

En outre, il est fortement recommandé, limiter les Extended Key Usages pour l'autorité de certification de telle sorte queque seuls les cas d'utilisation définis sont pris en charge. De même, une Limitation de la longueur du chemin très utile.

Test de fonctionnement

Pour le test, nous nous faisons délivrer un certificat d'autorité de certification avec les restrictions définies.

Les tests ont été réalisés avec le PSCertificateEnrollment module PowerShell.

Si nous demandons un certificat pour un nom DNS au sein de intra.adcslabor.de, la demande de certificat est approuvée.

Si nous demandons un certificat pour un nom DNS au sein d'un domaine DNS non défini, la demande de certificat est, comme on pouvait s'y attendre, refusée.

Si nous demandons un certificat pour un nom DNS au sein de intra.adcslabor.de, et un commonName non défini, la demande de certificat est refusée, comme on pouvait s'y attendre.

Évaluation de l'aptitude à la pratique

Les restrictions de nom permettent d'exercer une certaine influence sur le contenu du certificat. L'avantage est que les infractions sont également détectées lors de la vérification d'un certificat (...peuvent être - si mis en œuvre) et que de tels certificats ne seraient alors pas acceptés.

Les restrictions ne peuvent toutefois être mises en œuvre que de manière incomplète. Par exemple, il n'est possible de limiter l'émission de certificats qu'aux identités au sein de certains espaces de noms DNS. Il n'est toutefois pas possible de limiter les identités qui sont demandées ici.

De même, il ne faut pas oublier que le RFC exige seulement que les restrictions sur le directoryName soient comprises. Il n'est donc pas possible de garantir que toutes les applications participantes utiliseront également les autres types comprendre.

D'une manière générale, l'ensemble de la construction est bien sûr aussi très rigide, car il n'est pas possible d'apporter des modifications a posteriori sans re-signer le certificat d'autorité de certification.

Une alternative plus flexible peut être le Module de politique de TameMyCerts pour l'organisme de certification.

Conclusion

Dans certains cas, les restrictions de nom selon le RFC 5280 sont donc totalement inadaptées. Même s'il n'y a pas d'obstacles techniques, elles ne conviennent que partiellement aux cas où le demandeur peut apporter l'identité dans la demande de certificat.

Liens complémentaires :

Sources externes

Contraintes : ce qu'elles sont et comment elles sont utilisées (Microsoft)
Extension du certificat X.509 Name Constraints - tout ce que vous devez savoir (Vadims Podans)
Extension des contraintes de nom (PKI Solutions, Inc.)
RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (Internet Engineering Task Force)
RFC 2818 - HTTP sur TLS (Internet Engineering Task Force)
Puis-je restreindre une autorité de certification à la signature de certains domaines uniquement ? (discussion sur security.stackexchange.com)
Les contraintes de nom X.509 sur les certificats sont-elles supportées sur OS X ? (discussion sur security.stackexchange.com)
Objet 407093 : Validation incorrecte de la contrainte de nom (Projet Chromium)
EJBCA - Autorité de certification Open Source PKI - Guide de l'utilisateur (PrimeKey)
Bug d'Apple iOS 9 concernant les contraintes de nom de CA (Ivo Vitorino sur LinkedIn)
À propos du contenu de sécurité de macOS High Sierra 10.13.3, de la mise à jour de sécurité 2018-001 Sierra, et de la mise à jour de sécurité 2018-001 El Capitan (Apple)