OpenSSL

De Wiki de Jordan LE NUFF
< Technique
Révision datée du 13 août 2019 à 12:44 par Jordan (discussion | contributions) (Page créée avec « == Présentation == Cette section a pour objet de lister les différents gestes concernant l'utilisation d'OpenSSL. == Configuration OpenSSL == === Personnaliser la confi... »)
(diff) ← Version précédente | Voir la version actuelle (diff) | Version suivante → (diff)
Sauter à la navigation Sauter à la recherche

Présentation

Cette section a pour objet de lister les différents gestes concernant l'utilisation d'OpenSSL.

Configuration OpenSSL

Personnaliser la configuration SSL

Dans le cas de demandes de certificat fréquentes, il est utile de modifier les valeurs par défaut que propose OpenSSL.

Pour ce faire, localiser le fichier openssl.cnf :

find /etc -type f -name openssl.cnf

Exemple de retour sous OpenSUSE :

/etc/ssl/openssl.cnf

Exemple de retour sous CentOS :

/etc/pki/tls/openssl.cnf

Par exemple, sur le serveur myserver, éditer le fichier /etc/ssl/openssl.cnf et, dans la section [ req_distinguished_name ], modifier/ajouter les variables *_default selon le besoin :

countryName_default		= FR
stateOrProvinceName_default	= Aquitaine
0.organizationName_default	= My Organization
organizationalUnitName_default	= My Department
emailAddress_default		= mymail@mydomain.com

Ces variables seront donc préremplies lors de la création d'une requête de certificat, ce qui facilitera la saisie.

Ajouter la variable SAN

Le nom alternatif de l'objet du certificat (SAN, pour Subject Alternative Name) est une extension de la spécification X.509 qui permet aux utilisateurs de spécifier des noms d'hôte supplémentaires pour un seul certificat SSL. L’utilisation de l’extension SAN est une pratique courante pour les certificats SSL et elle est en passe de remplacer l’utilisation du nom commun (CN, pour Common Name). L'extension SAN correspond au champ subjectAltName du certificat.

De ce fait, bien que le certificat soit correctement généré, certains navigateurs peuvent, en l'absence du champ subjectAltName dans le certificat, générer une erreur.

Ainsi, pour activer ce champ lors de la génération du certificat, éditer le fichier /etc/ssl/openssl.cnf et ajouter la variable suivante en début de fichier :

SAN = "email:mymail@mydomain.com"

Puis, dans la section [ req ], ajouter la ligne :

req_extensions = v3_req

Ensuite, dans les sections [ v3_req ] et [ v3_ca ], ajouter la ligne suivante :

subjectAltName=${ENV::SAN}

Comment fonctionne cette configuration ?

Déclarer la variable SAN au début du fichier permet de s'assurer qu'elle existe bien lors la déclaration de la variable subjectAltName. Ensuite, lors de la génération d'une requête de certificat, il faudra déclarer au préalable la variable SAN au moyen de la commande export en y indiquant les différents noms alternatifs de l'objet du certificat.

Exemple avec la commande :

export SAN="DNS:unnom.mondomain.com, DNS:unautrenom.mondomain.com";openssl req -new -key /etc/ssl/private/unnom.key -out /etc/ssl/certs/unnom.csr

Créer un certificat

Créer la clé privée

Créer la clé privée qui servira à décrypter les échanges :

openssl genrsa -out /etc/ssl/private/monFQDN.key 2048

Cela va créer un fichier /etc/ssl/private/monFQDN.key qui servira à générer la requête de certificat. Il est de bonne pratique de nommer la clé avec le FQDN de l'objet du certificat.

N.B. Dans cette commande, il est indiqué de créer une clé sur 2048 bits. A ce jour, c'est la sécurité minimale requise. Toutefois, de telles clés ont récemment été cassées. De ce fait, l'ANSSI recommande le 4096-bit à partir de 2020.

Exemple de retour :

Generating RSA private key, 2048 bit long modulus
........................................................+++
..................+++
e is 65537 (0x10001)

Créer la requête de certificat

Si le champ subjectAltName est désiré, lancer la commande suivante en pensant à indiquer la clé privée précédemment générée :

export SAN="DNS:monFQDN, DNS:unautreFQDN";openssl req -new -key /etc/ssl/private/monFQDN.key monFQDN.csr

Sinon, simplement lancer :

openssl req -new -key /etc/ssl/private/monFQDN.key -out /etc/ssl/certs/monFQDN.csr

Vu que le fichier de configuration d'OpenSSL a été personnalisé, seul le champ Common Name est à renseigner (et optionnellement un mot de passe).

Exemple de retour :

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [FR]:
State or Province Name (full name) [Aquitaine]:
Locality Name (eg, city) [Bordeaux]:
Organization Name (eg, company) [My Organization]:
Organizational Unit Name (eg, section) [My Department]:
Common Name (e.g. server FQDN or YOUR name) []:monFQDN
Email Address [mymail@mydomain.com]:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Cela va créer un fichier /etc/ssl/certs/monFQDN.csr qui servira à générer le certificat. Il est de bonne pratique de nommer la requête avec le FQDN de l'objet du certificat.

Option 1 : créer un certificat auto-signé

Créer un certificat auto-signé peut être utile dans des cas de tests. Toutefois, cela peut générer des blocages ou des erreurs selon les navigateurs et les applications utilisées.

Pour créer un certificat auto-signé avec la clé privée et la requête précédemment générées, lancer la commande suivante :

openssl req -x509 -sha256 -nodes -days 365 -in /etc/ssl/certs/monFQDN.csr -key /etc/ssl/private/monFQDN.key -out /etc/ssl/certs/monFQDN.crt

Cela va créer un fichier /etc/ssl/certs/monFQDN.crt contenant le certificat. Il est de bonne pratique de nommer ce fichier avec le FQDN de l'objet du certificat.

Option 2 : soumettre la requête de certificat

En dehors des cas de tests, et afin de garantir la sécurité des échanges, il ne faut pas créer de certificat auto-signé. Il faut donc soumettre la requête de certificat, accompagnée de la clé privée, à une autorité de certification.

Si l'utilisation du certificat ne se fait qu'en interne de l'entreprise, il est possible de soumettre la requête à l'autorité de certification de l'entreprise, si elle existe. Dans le cas contraire, en cas d'absence d'autorité de certification de l'entreprise, ou bien pour une utilisation du certificat sur internet, il faut choisir une autorité de certification publique. Se rapprocher de la DSI pour connaître la marche à suivre.

Dans les deux cas, la finalité est d'obtenir un certificat et, accessoirement, un certificat complémentaire qui contiendra les autorités de certification intermédiaires. Il est de bonne pratique de nommer ces fichier avec le FQDN de l'objet du certificat, par exemple /etc/ssl/certs/monFQDN.crt et /etc/ssl/certs/monFQDN.ca-bundle.crt.