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 »

Pour les certificats approuvés publiquement, la valeur (champ) unité organisationnelle n’est pas obligatoire. D'après 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 (si vous ne fournissez pas de valeur pour l’unité organisationnelle), 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 quelques 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)

Si vous vous contentez de saisir un trait d'union à 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), ce dernier ne posera pas de problème à l’AC pour la validation 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 ? Par ailleurs, vous envisagez de valider l’organisation pour les certificats à validation étendue (EV) ?
    Si c’est le cas, assurez-vous que l’ensemble nom de l’organisation + nom d’emprunt ne dépasse pas les 64 caractères, espaces comprises.
  • Rue 1
  • Rue 2
  • 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 :

  • Nom commun de l’objet
  • Autres noms de l’objet (SAN)

À compter du 1er octobre 2018, nous ne pouvons émettre 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 (‐)

À l’heure actuelle, vous ne pouvez inclure d'underscore que dans les autres valeurs du certificat, telles que l'unité organisationnelle 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 en vigueur dans l'industrie sont susceptibles de changer et de vous imposer de retirer les underscores de ces valeurs également.