Dans le champ nom commun du DN d'un certificat X509, tel que défini dans la notation ASN.1 pour OID "2.5.4.3", quelles sont les valeurs autorisées?
Je sais que la limite peut atteindre 64 caractères, mais tous les caractères sont-ils autorisés? Des chiffres?
Par exemple. sont .
s est autorisé? Une adresse IP (x.x.x.x) est-elle une séquence valide selon la définition ASN?
Un nom de domaine est-il autorisé?
L'attribut de nom commun dans un nom distinctif est codé comme suit:
X520CommonName ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-common-name)),
printableString PrintableString (SIZE (1..ub-common-name)),
universalString UniversalString (SIZE (1..ub-common-name)),
utf8String UTF8String (SIZE (1..ub-common-name)),
bmpString BMPString (SIZE (1..ub-common-name)) }
où ub-common-name
est 64. Les trois derniers encodages permettent d'utiliser tous les points de code nicode (en utilisant UTF-16 pour les points de code au-delà de 0xFFFF avec bmpString
); UTF-8 est le codage préféré (du moins les normes le disent).
En ce qui concerne X.509 (voir RFC 528 ), le contenu des éléments DN n'est pas pertinent au-delà des comparaisons d'égalité; ce qui signifie que vous pouvez mettre la séquence de caractères que vous souhaitez, tant que vous le faites de manière cohérente. La RFC 5280 impose des comparaisons insensibles à la casse pour les éléments de nom codés UTF-8, et ce n'est pas facile dans le contexte général d'Unicode: voir la section 7.1, qui établit un lien avec la RFC 4518 et 454 . De plus, le "nom commun" est fréquemment affiché pour l'utilisateur (au moins sur les systèmes utilisant des certificats X.509 qui ont un affichage et un utilisateur physique), donc vous voudrez probablement utiliser une chaîne qui soit significative ou du moins pas trop effrayante pour un humain, et vous pouvez essayer d'éviter les scripts non latins.
Mettre un nom DNS dans l'attribut "nom commun" est une pratique courante pour les certificats de serveur HTTPS: voir RFC 2818 (les certificats de serveur contiennent le nom du serveur, que le client compare avec le nom du serveur dans l'URL; normalement, l'extension Subject Alt Name est préférée pour cela, mais le nom commun est un peu plus largement pris en charge par les clients).
Quelles chaînes sont autorisées dans l'attribut "nom commun" dans un certificat X.509?
Je ne peux pas vraiment répondre à ce qui s'y trouve, mais je peux vous dire ce qui y va pas: les noms de serveur, comme les noms d'hôte (www.example.com), les noms internes (comme www) et Adresses IP (comme 127.0.0.1 ou 100.100.100.100).
Placer un nom DNS ou un nom de serveur dans le nom commun (CN) est déconseillé par les forums IETF et CA/Browser. Bien que déconseillé, il n'est actuellement pas interdit. Le CA/B est important parce que c'est ce que les navigateurs suivent - les navigateurs font pas suivent l'IETF.
L'IETF a déconseillé la pratique dans la RFC 6125, section 2.3, tandis que le CA/B a déconseillé la pratique dans les exigences de base, section 9.1.1.
Tous les noms de serveur vont dans le nom alternatif du sujet (SAN). Le placement des noms de serveur dans le SAN est requis par les exigences de base CA/B, section 9.2.1. L'IETF est plus indulgent lors de l'émission avec RFC 5280, mais l'exige lors de la validation sous la section 6.4.4 de RFC 6125.
Bien que les réponses ci-dessus couvrent ce que vous y trouverez généralement, n'oubliez pas que, car il s'agit de X.509, vous pouvez réellement y mettre à peu près n'importe quoi. Le certificat ci-dessous, par exemple, utilise 0.9.2342.19200300.100.1.5 qui est la `` boisson préférée '' (Voir http://www.alvestrand.no/objectid/0.9.2342.19200300.100.1.5.html ) . Openssl comprend cela, donc le nom commun est affiché comme CN=example.com/[email protected]/favouriteDrink=tequila. Il existe de nombreux autres champs qui peuvent être mis dans le nom commun du certificat.
Vous pouvez utiliser openssl x509 -text pour vérifier que le certificat s'affiche comme je l'ai décrit.
-----BEGIN CERTIFICATE-----
MIIDOzCCAiOgAwIBAgIBCzANBgkqhkiG9w0BAQUFADCBqzEmMCQGA1UEAxMdV2Vz
dHBvaW50IENlcnRpZmljYXRlIFRlc3QgQ0ExEzARBgNVBAgTCkxhbmNhc2hpcmUx
CzAJBgNVBAYTAlVLMR0wGwYJKoZIhvcNAQkBFg5jYUBleGFtcGxlLmNvbTFAMD4G
A1UEChM3V2VzdHBvaW50IENlcnRpZmljYXRlIFRlc3QgUm9vdCBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eTAeFw0xMTA3MzEyMTAxMTdaFw0yMTA3MjgyMTAxMTdaMFAx
FDASBgNVBAMTC2V4YW1wbGUuY29tMR8wHQYJKoZIhvcNAQkBFhB0ZXN0QGV4YW1w
bGUuY29tMRcwFQYKCZImiZPyLGQBBRMHdGVxdWlsYTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAuCqI3aNbSkRpA9VuGOmeVQ010Oaawsz4tcW2FQChJDOv6PuT
ucy5IijvaVewotDjnuVzPpBVW5EmC8Qapradomhb6FtFPyH/hGSnhLtht3Ln6stJ
ZkAjvr/wjWDy+3Gy/P5r5weUNWVm2AaQgk2xumx49EIXyzwOEHAhqTE7iEECAwEA
AaNIMEYwCQYDVR0TBAIwADA5BggrBgEFBQcBAQQtMCswKQYIKwYBBQUHMAGGHWh0
dHA6Ly9vY3NwLmV4YW1wbGUuY29tOjg4ODgvMA0GCSqGSIb3DQEBBQUAA4IBAQBL
oz035PphO4yUx7FJVaZjxLgTM4wLrcn2ONGm015/ECO+1Uxj3hWb6/EIDDKV/4e8
x0HDF69zyawYLD1th5tBcZLkV/Dat/Tzkt3boLOCGo2I1P+yjqxlb7BZCk7PEs3+
zjWF2hMcXtAwOIrsRuvXp4eTGwigKLAt/H02US/fa2dXFbOnz91V7oH8ZvynIl/n
hpELPzVWX/pBnHEGA9Bi0jviCKuvQisfaJ8XCiA73qH6CkSoZ2fClnrs+pJNj8i6
vtcMx8htn7FsyB3puVww86JSQ+VDKlQkFbPVla/4Aavzwz8djjVYEWwSgm+tw3jB
zUP/k5Aln5cXNo50KOip
-----END CERTIFICATE-----
Si votre problème principal est de savoir si vous pouvez (ou devez) mettre ou non une adresse IP dans le nom commun du nom distinctif du sujet, la réponse est non.
Ce n'est pas lié au format X.509, mais aux spécifications qui expliquent comment interpréter ce qu'ils lisent.
En ce qui concerne HTTPS, RFC 2818 dit ce qui suit à propos des adresses IP:
Dans certains cas, l'URI est spécifié en tant qu'adresse IP plutôt qu'en tant que nom d'hôte. Dans ce cas, le
iPAddress
subjectAltName
doit être présent dans le certificat et doit correspondre exactement à l'IP dans l'URI.
Cela signifie que le CN ne doit pas être utilisé du tout pour une adresse IP et que le type d'entrée SAN doit être par adresse IP, pas DNS. (Certains navigateurs, ne l'implémenteront pas complètement , donc ils pourraient être plus tolérants. Le Java vérificateur de nom d'hôte par défaut sera strict.)
Les meilleures pratiques pour la vérification de l'identité des certificats sont également définies dans RFC 6125 , mais il prend en compte adresses IP hors de portée (il vaut la peine de lire cette section pour des arguments contre l'utilisation d'adresses IP là-bas) . Si vous passez par les extraits de RFC concernant d'autres protocoles , certains ont des contraintes similaires concernant les adresses IP (par exemple LDAP).