(modifié le 23 août 2018 à 18:08)

Si vous utilisez votre propre autorité de certification (Active Directory par exemple) il peut-être utile de générer une demande de signature de certificat (CSR) autorisant plusieurs noms communs (common name) dans le but d'obtenir un certificat HTTPS (X.509).

Voyons comment faire avec openssl.

Fonctionnement

Sur le serveur GNU/Linux nous allons générer :

  • une clé privée
  • une clé publique
  • une CSR (signée numérique avec la clé privée, contient aussi la clé publique)

Cette CSR sera ensuite soumise à l'autorité Active Directory qui retournera le certificat multi-domaine/SAN associé (les 2 sont possibles).

Noms alternatifs du sujet du certificat

Pour qu'un certificat HTTPS fonctionne le serveur doit être accessible via la même adresse que celle contenu dans le certificat. C'est le CN (common name) qui joue ce rôle. Mais il est possible de saisir plusieurs CN, on parle alors de "Subject Alternative Name" (SAN) ou "nom alternatif du sujet du certificat"

ex chez Digicert :

Ce type de certificat évite d'avoir à acheter plusieurs certificats, mais elle est aussi très pratique parce qu'un serveur peut être accessible via plusieurs adresses. Avec un répartiteur de charge, une URL différente en interne ou externe, etc.

Renseignement du fichier csr_details.txt

Cette méthode fonctionne sur tous les OS ayant OpenSSL de présent. Il l'est nativement sous GNU/Linux et téléchargeable sous Windows, même si personnellement je vous conseille de tout faire avec une machine GNU/Linux et de déplacer les clés sur votre machine Windows.

Voici les informations de notre serveur :

  • nom FQDN : srvweb01.bm.local
  • hostname : srvweb01
  • IP : 192.168.1.20

Nous voulons donc que le certificat soit valide pour ces 3 adresses :

  • https://srvweb01
  • https://srvweb01.bm.local
  • https://192.168.1.20

Nous devons préciser ces informations dans un fichier texte pour que openssl prenne en compte ces noms alternatifs :

Vous pouvez aussi faire un copier/coller dans un fichier csr_details.txt en cas d'erreur avec la commande cat.

Voici à quoi correspondent les champs :

  • C : Country (pays)
  • ST : State (état ou région)
  • L : City (ville)
  • O : Organization (nom entreprise)
  • OU : Organization Unit (service / département)
  • emailAddress : contact administratif du certificat
  • CN : Common Name (nom commun)

source

Génération de la CSR

Passons maintenant à la génération de la clé privée et de la CSR (contenant aussi la clé publique).

Toujours utiliser sha256 car sha1 est déprécié, avec une clé minimum de 2048 (RSA) :

openssl req -nodes -newkey rsa:2048 -sha256 -days 3650 -keyout srvweb01.key -out srvweb01.csr -config <(cat csr_details.txt)

Le nombre de jours (10 ans ici) a peu d'importance car c'est l'autorité qui va déterminer la durée de validité du certificat.

Vous pouvez aussi utiliser un fichier à plat au lieu de l'inclure à la volée avec "-config csr_details.txt".

Voici les fichiers obtenus :

  • srvweb01.key : clé privée
  • srvweb01.csr : CSR

Le fichier csr est un fichier texte, vérifiez que son contenu contient quelque chose comme :

Récupération du certificat

Cette procédure ne sera pas détaillée car spécifique à chaque type de PKI.

Toutefois si vous êtes sur une PKI AD, allez sur https://srvautorite.bm.local/certsrv/ puis :

  1. Demander un certificat
  2. Demande de certificat avancée
  3. Soumettez une demande de certificat en utilisant un fichier CMC ou PKCS #10 codé en base 64...
  4. Coller le contenu de la CSR dans "demande enregistrée"
  5. Modèle de certificat : serveur web SAN
  6. Envoyer
  7. Télécharger le certificat au format souhaité (prenez les 2 on ne sait jamais...)

Si vous n'avez pas ce template alors vérifiez que vous êtes bien sur Windows Server Entreprise et non pas sur Standard qui ne permettait pas ce type de template avec Windows Server 2008 (pour les autres versions j'ignore si c'est aussi le cas). Voici un tutoriel pour monter une autorité sous 2012 R2 si besoin.

Notez qu'avec Windows 2008 R2 Server il n'est pas possible de créer et soumettre la demande de requête directement car seul SHA1 est proposé dans l'interface web. C'est pour cette raison qu'on passe via openssl pour générer la clé privée et la CSR.

Auteur : Mr Xhark

Fondateur du blog et passionné par les nouvelles techno, suivez-moi sur twitter