(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 :

cat > csr_details.txt <<-EOF
[req]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn

[ dn ]
C=FR
ST=Grenoble
L=Grenoble
O=BLOGMOTION
OU=BLOGMOTION
emailAddress=cert@nospam-blogmotion.fr
CN = srvweb01.bm.local

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = srvweb01
DNS.2 = srvwebalias
IP.1 = 192.168.1.20
EOF

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 :

-----BEGIN CERTIFICATE REQUEST-----
MIIC5jCCAc4CAQAwgaAxCzAJBgNVBAYTAkZSMQ4wDAYDVQQIDAVJU0VSRTERMA8G
A1UEBwwIR1JFTk9CTEUxEzARBgNVBAoMCkJMT0dNT1RJT04xEzARBgNVBAsMCkJM
T0dNT1RJT04xGjAYBgNVBAMMEXNydndlYjAxLmJtLmxvY2FsMSgwJgYJKoZIhvcN
AQkBFhljZXJ0QG5vc3BhbS1ibG9nbW90aW9uLmZyMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAyG4lPz/7q4rhYMojZa7vUzpEQw/FXPoDibaqo+wjAlEh
cNXXnJk0liz5oLPCoMua/20cPp3pdPBbDWslYIlL+bTliQljpEJjTBF0X980gd/6
U90fsMT8wisXM0ZXiUMP0FaGu36KRVPfI8xC2m0sjK/YULQmyPYr/k55Jt3syTCI
b/Mp0FxGbtr1onJ/YlCbp6srk+6+L7/19rgyxghid0y+gxyFVYyRaGYLVSwKb5CE
U3wGndW58968HDvidD4dts7p8gqC44djSn3fPXaICh7K1H6PoCdO3l5uWxrxR+Cq
ukistK2KDT5AP5bivFgYlmibWi0VDKRxfh3IURjtKwIDAQABoAAwDQYJKoZIhvcN
AQELBQADggEBALnoSKTgiLfVv5cPewc0c0iZFWVGIIthYGxNt8ervE/ZJt77jhwk
m9/kOMlQsSRqxuroCkknnU84XOpFApb9PaSXATdOYAXVjMyBMJeznb3+SfqEF/Xg
BxU8A4C4WzcSduFfRsX3ounRnbRyuwG614cnH9IbwQzLsb6/ZU6S/LPwTU0BTBRe
9qlB8ouRF332Ybh4/1QPfs7aDQ/HCiDLjZrBHT8pnGDZFX52CRK/4jujBK8Aj/Ns
CT/q3VEWO4glfjehYlEbdWWi+6EOI0kggb2wUovijjpGdn6crLanS1Jh9w4SZLs5
sLEeJmLwu5b7nbTtdwoOCMBZHiOt0cpgAeM=
-----END CERTIFICATE REQUEST-----

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