Certificats publics – Entrées de données non conformes aux normes de l'industrie
Exigences de base et violation de la norme RFC 5280
Pour les certificats approuvés publiquement, les normes en vigueur (exigences de base et RFC 5280) exigent que les entrées de données répondent à certains critères. Le non-respect de ces normes au moment de la commande d'un certificat empêche l’autorité de certification (AC) d'émettre celui-ci.
Non-respect de la valeur « unité organisationnelle »
Important
DigiCert considère désormais le champ Unité organisationnelle (OU) comme obsolète, ceci afin de simplifier la commande de certificats TLS/SSL publics. Pour de plus amples informations sur l’obsolescence passage du champ OU, consultez l’article de notre base de connaissance DigiCert va abandonner le champ Unité organisationnelle.
Pour les certificats approuvés publiquement, la valeur (champ) unité organisationnelle n’est pas obligatoire.
Selon les exigences de base, les autorités de certification (AC) ne doivent valider la valeur « unité organisationnelle » que si celle-ci est effectivement fournie. Si vous laissez ce champ vide, les AC ont pour instruction de ne pas inclure le champ au certificat.
Les exigences de base interdisent également que cette valeur soit, ou semble être, constituée de données « corrompues » ou d’indication de non-applicabilité (N/A, ? etc.) afin de ne pas surcharger inutilement les certificats. Le fait de garder des certificats de taille plus réduite permet de maintenir l'accessibilité de TLS à tous les types de publics et d'opérateurs de sites.
Vous trouverez ci-dessous des caractères qui, utilisés seuls pour le champ « unité organisationnelle », ne représentent pas une valeur acceptable.
« - » (trait d'union)
« » (espace)
« . » (point)
« ? » (point d'interrogation)
« na » (non applicable)
« NA » (Non applicable)
Avertissement
Si vous saisissez un trait d'union seul à titre d'unité organisationnelle, l’AC ne sera pas en mesure de valider cette valeur.
Cependant, si vous saisissez un nom d'organisation contenant un trait d'union (par ex. Dev-Ops), l’AC pourra toujours valider la valeur de votre unité organisationnelle.
Non-respect de la limite de 64 caractères
Pour les certificats approuvés publiquement, nous ne pouvons pas autoriser les valeurs (saisies de données) de plus de 64 caractères, espaces comprises.
Nom commun
La valeur « nom commun » ne peut dépasser la limite de 64 caractères. Cependant, la valeur pour les autres noms d'objet (SAN) ne subit pas les mêmes restrictions en nombre de caractères que celle du nom commun. Les SAN inclus à votre commande de certificat (par exemple dans le cas d'une commande de certificat Multi-Domain SSL) peuvent dépasser les 64 caractères.
Organisation
L’organisation comprend un nom d’emprunt ? Vous envisagez de valider cette organisation en vue d’obtenir des certificats à validation étendue (EV) ? Assurez vous que les valeurs nom d'organisation + nom d’emprunt ne dépassent pas les 64 caractères, espaces comprises.
Voie
Voie (suite)
Ville
État
Code postal
Non-respect des règles d'usage de l’underscore
Pour les certificats approuvés publiquement, nous ne pouvons plus accepter l’utilisation d'underscores ( _ ) dans les champs suivants :
Noms communs de l’objet
Autres noms de l’objet (SAN)
Nous n’émettons de certificats que pour les domaines et sous-domaines utilisant les caractères suivants :
Lettres minuscules (a-z)
Lettres majuscules (A-Z)
Chiffres (0-9)
Caractères spéciaux : point (.) et traits d'union (-)
Important
À l’heure actuelle, vous ne pouvez inclure d'underscore que dans les autres valeurs du certificat, telles que les unités organisationnelles ou les noms d’organisation. Cependant, la question de l’usage de l’underscore dans ces valeurs est en cours de réévaluation. Les normes du secteur sont susceptibles de changer et de vous imposer de retirer les underscores de ces valeurs également.
Violation de l'utilisation des doubles tirets
Le Forum Certificate Authority/Browser (CA/B a clarifié une exigence du Ballot 202 demandant aux AC de ne pas émettre de certificats TLS/SSL publics avec des noms de domaine internationalisés non valides.
À compter du 1er octobre 2021, pour les certificats TLS/SSL publics, nous n'autorisons plus l'utilisation de doubles tirets (--) dans les troisième et quatrième caractères des noms de domaine, sauf si les doubles tirets précèdent les lettres xn (xn--exemple.com).
Domaine | Autorisé ? |
|---|---|
Es--xyz.loudsquid.com | Non |
www.es--xyz.loudsquid.com | Non |
xn--xyz.loudsquid.com | OK |
xyz--loudsquid.com | OK |