Google est très actif avec le projet Chromium et les produits basés sur ce dernier, tels que Google Chrome et Microsoft Edge ont commencé à appliquer la loi sur la protection des données adoptée en 2000. RFC 2818 et de ne plus faire confiance aux certificats qui ne remplissent plus cette condition.
Pour nous, la phrase suivante est d'une grande acuité :
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
Veuillez noter que les déclarations concernant la représentation de l'identité au sein d'un certificat dans cet article visent exclusivement le cas d'application HTTP sur SSL (HTTPS).
Le RFC exige donc que l'identité d'une page web ne soit plus formée à partir du champ "Common Name" au sein du Subject, mais à partir d'une ou plusieurs entrées dNSName au sein de l'extension Subject Alternative Name (SAN) au sein du certificat. Ainsi, un certificat sans extension SAN n'est pas conforme à la RFC et n'est plus accepté par ces navigateurs.
Malheureusement, de nombreuses applications - en particulier les anciennes appliances - ne permettent souvent pas de créer une demande de certificat contenant un Subject Alternative Name.
Google Chrome se déconnectera avec le code d'erreur ERR_CERT_COMMON_NAME_INVALID refusent de le faire. Comme Microsoft Edge est désormais également basé sur Google Chrome, le message d'erreur y sera identique.
Mozilla Firefox refusera de se connecter de la même manière. Le code d'erreur est ici SSL_ERROR_BAD_CERT_DOMAIN.
Il existe certes différentes manières d'ajouter un Subject Alternative Name, même ultérieurement, avant que le certificat ne soit délivré. En voici quelques-unes mais sont extrêmement incertainsLes méthodes d'évaluation de la qualité de l'enseignement et de la formation ont toutes en commun le fait qu'elles doivent être effectuées manuellement et qu'elles sont sujettes à des erreurs.
Cela est désormais terminé ! Le module TameMyCerts Policy pour les Microsoft Active Directory Certificate Services est capable de reconnaître les noms DNS dans le Subject Distinguished Name et de les transférer automatiquement dans un Subject Alternative Name.
TameMyCerts a entre-temps fait ses preuves dans l'exploitation productive de nombreuses entreprises et administrations de renom. Cerise sur le gâteau : TameMyCerts est open source et peut être utilisé gratuitement.
TameMyCerts est open source et peut être utilisé gratuitement. Toutefois, pour une utilisation en entreprise, il est recommandé d'utiliser le Conclusion d'un contrat de maintenance. Cela garantit que vous recevrez un soutien qualifié et que le module pourra être développé à long terme avec une qualité élevée.
La mise en œuvre
Pour gérer un modèle de certificat par TameMyCerts, un fichier de configuration est nécessaire. Lors de l'installation du module sur l'autorité de certification, un répertoire est indiqué dans lequel les fichiers de configuration sont enregistrés.
Le fichier doit être nommé selon le modèle de certificat. Il est important de préciser qu'il s'agit du nom de l'objet LDAP et non du nom d'affichage. Le nom de l'objet peut être trouvé via la console d'administration pour les modèles de certificats, en cliquant avec le bouton droit sur le modèle de certificat et en sélectionnant l'option "Change Names...".
Supposons que le nom d'objet de notre modèle de certificat soit "ADCSLaboratoireServeur webnous appellerons le fichier de configuration "fichier de configuration".ADCSLaboratoireWebServer.xml„ .
Chaque fichier de configuration commence par un nœud appelé CertificateRequestPolicyLe fichier de configuration est un fichier dans lequel les directives de configuration sont inscrites.
<CertificateRequestPolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<!-- here we will place our rules -->
</CertificateRequestPolicy>
Comme notre cas d'utilisation est une Hors ligne-Si nous sommes un modèle de certificat, nous devons d'abord définir une règle pour le contenu de la demande de certificat. Le minimum requis est une règle pour le Subject Distinguished Name. Ceci est réalisé par une SubjectRule à l'intérieur de la zone Sujet est atteint.
En règle générale, une demande de certificat comprendra un "nom commun". TameMyCerts fonctionne selon le principe "ce qui n'est pas défini est interdit". Les demandes de certificat dont le contenu n'est pas défini seront refusées.
Il est donc nécessaire d'établir une règle correspondante pour le commonName champ peut être créé. En plaçant le Mandatory permet de s'assurer que les demandes de certificat qui ne contiennent pas de "Common Name" sont également automatiquement rejetées.
Dans la liste des Patterns sera un Pattern-et un nœud Expression est définie. Dans ce cas, nous indiquons par une expression régulière que seuls les noms DNS à l'intérieur du domaine "adcslabor.de sont acceptés. Ainsi, si le "nom commun" s'écarte de cette règle, la demande de certificat entrante est automatiquement rejetée.
<CertificateRequestPolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Subject>
<SubjectRule>
<Field>commonName</Field>
<Mandatory>true</Mandatory>
<Patterns>
<Pattern>
<Expression>^[\-_a-zA-Z0-9]*\.adcslabor\.de$</Expression>
</Pattern>
</Patterns>
</SubjectRule>
</Subject>
</CertificateRequestPolicy>
D'autres règles peuvent être définies en option. Typiquement, on inclurait encore les éléments suivants :
- Champs supplémentaires (Relative Distinguished Names, RDNs) dans le Subject Distinguished Name (DN) tels que organizationName, organizationalUnitName etc... Pour une liste des RDN possibles, voir aussi l'article "Noms distinctifs relatifs (RDN) autorisés dans le Subject Distinguished Name (DN) des certificats délivrés„ .
- Une règle pour les Subject Alternative Names (SAN) dans la demande de certificat. Après tout, la demande de certificat pourrait déjà en contenir un.
Letztendlich wird noch die SupplementDnsNames est définie dans cette directive. Celle-ci indique à TameMyCerts de reprendre les noms DNS trouvés dans le "Common Name" dans le Subject Alternative Name (SAN).
<SupplementDnsNames>true</SupplementDnsNames>
Si un certificat est demandé pour le modèle de certificat configuré, TameMyCerts s'assure automatiquement que le certificat délivré contient un Subject Alternative Name valide.
Français 
Deutsch 
English