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 satisfont plus au RFC.
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 via 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 au RFC et n'est plus accepté par ces navigateurs.
Création d'une demande de certificat
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.
Le processus de demande d'un certificat conforme à la RFC 2818 auprès de l'autorité de certification Microsoft est décrit ci-dessous. Nous avons délibérément choisi une méthode qui est divisée en plusieurs étapes et qui peut donc être adaptée à d'autres systèmes (par exemple Linux).
Création manuelle de la demande de certificat
Cette méthode convient aux systèmes qui ne sont pas membres de la même structure globale Active Directory que l'autorité de certification. Voir l'article „Demande manuelle d'un certificat de serveur web„ .
Création de la demande de certificat via la console de gestion Microsoft (MMC)
Cette méthode s'impose lorsque le serveur web et l'autorité de certification sont membres de la même structure globale Active Directory et qu'il est donc possible de recourir aux modèles de certificats déposés dans Active Directory.
La première étape consiste à générer une paire de clés et une demande de certificat (CSR) sur le système cible. Cette étape dépend du système d'exploitation cible (Windows, Linux, etc.) et doit être effectuée par le propriétaire du service informatique concerné (le demandeur, Enrollee).
Pour Windows, il faut démarrer la console de gestion des certificats pour le compte de l'ordinateur (certlm.msc) et cliquer avec le bouton droit sur Certificates sous Personal. Dans le menu contextuel, on sélectionne All Tasks - Advanced Operations - Create Custom Request.
On choisit ici le modèle de certificat et on clique ensuite sur Next.
Avant de générer la demande de certificat, il faut encore cliquer sur Properties dans la boîte de dialogue suivante sous Details. Pour un certificat de serveur web, c'est généralement le demandeur qui donne l'identité, celle-ci doit encore être configurée.
Conformément à la RFC 2818, le Subject du certificat peut être vide s'il existe un Subject Alternative Name. L'extension Subject Alternative Name se comporte comme suit pour l'autorité de certification Microsoft, conformément à la RFC 2818 :
- Si le Subject est vide, l'extension Subject Alternative Name est définie comme suit critique car elle contient la seule possibilité de déterminer l'identité.
- S'il existe un nom commun au sein du Subject, l'extension Subject Alternative Name doit être utilisée en tant que non critique pour permettre aux applications de revenir en arrière si elles ne comprennent pas l'extension SAN.
L'expérience montre en effet qu'il est tout à fait possible qu'un certificat soit utilisé par une application qui n'a pas été programmée conformément à la RFC 2818. Celle-ci ne connaîtrait éventuellement pas l'extension Subject Alternative Name et l'ignorerait alors. Si l'extension SAN est marquée comme critique, le traitement du certificat devrait dans ce cas être interrompu.
Pour cette raison, il est tout à fait recommandé de continuer à remplir le nom commun. Le RFC 2818 n'est pas violé pour autant, car une extension SAN est disponible pour toutes les applications conformes.
La demande de certificat peut maintenant être sauvegardée dans un fichier. Le codage choisi est secondaire.
Une paire de clés et une demande de certificat sont alors générées. Celle-ci doit être envoyée à l'autorité de certification à l'étape suivante.
Envoi de la demande de certificat à l'autorité de certification
Indépendamment de la manière dont la demande de certificat a été générée (Windows, Linux, etc.), le fichier CSR peut maintenant être envoyé à l'autorité de certification compétente.
Cela peut se faire à partir de n'importe quel ordinateur Windows dans la structure globale d'Active Directory, mais l'utilisateur exécutant doit avoir le droit d'enrôlement sur le modèle de certificat cible.
certreq -submit {Zertifikatanforderung}.req
Pour les demandes de certificat qui n'ont pas été générées avec la MMC de Microsoft, aucune information sur le modèle de certificat n'est disponible. Cette information doit être fournie manuellement lors de la demande :
certreq -attrib "CertificateTemplate:{Name-der-Zertifikatvorlage}" -submit {Zertifikatanforderung}.req
On est alors invité à choisir une autorité de certification cible.
La demande de certificat est ensuite envoyée à l'autorité de certification. Si le modèle de certificat est configuré de telle sorte que la demande doit d'abord être vérifiée par un gestionnaire de certificats, on est averti de cette situation et on ne reçoit pas encore de certificat en retour. Il est important de noter le RequestId émis, car il est nécessaire pour récupérer le certificat.
Récupération du certificat délivré par l'autorité de certification
Une fois que le certificat a été émis par un gestionnaire de certificats, il peut être récupéré auprès de l'autorité de certification à l'aide de la commande suivante.
certreq -reqtrieve {Request-ID}
Il faut à nouveau choisir l'organisme de certification cible.
Le certificat peut ensuite être sauvegardé sous forme de fichier.
Associer le certificat délivré à la clé privée
Cette étape dépend à nouveau du système cible (Windows, Linux). Le certificat émis doit maintenant encore être associé à la clé privée créée précédemment avant de pouvoir être utilisé. Pour cela, des droits d'administrateur sont nécessaires si la demande de certificat a été créée dans le contexte de la machine.
certreq -accept {Zertifikat}.cer
Lier le certificat à l'application
Le certificat émis et installé doit maintenant être lié à l'application cible. Cette étape dépend de l'application cible (par exemple IIS, Apache, NGINX). Pour le service d'enregistrement des périphériques réseau (NDES) on trouve ici un exemple.
Liens complémentaires :
- Issue 308330 : Suppression de la prise en charge des noms communs dans les certificats ; prise en charge uniquement des noms de sujets anciens (Projet Chromium)
- RFC 2818 - HTTP sur TLS (Internet Engineering Task Force)
Français 
Deutsch 
English
Les commentaires sont fermés.