Générer un certificat auto-signé robuste : RSA 4096 bits et SHA-2 512 bits
Si vous hébergez sur votre serveur web des services personnels type ownCloud, lecteur RSS, webmail, panel d’administration, etc, il peut être une bonne idée d’y accéder de manière chiffrée, c’est à dire en HTTPS. Je dirais même que cela est indispensable lorsque des données personnelles transitent.
Malheureusement, les certificats SSL/TLS sont payants (d’une dizaine d’euros à plusieurs centaines), enfin pour le moment, puisque Let’s Encrypt arrive bientôt. 😉
Heureusement, on peut générer un certificat et le signer nous-même au lieu de le faire signer par une autorité de certification reconnue. Cela entraînera une alerte de sécurité dans les navigateurs, cette méthode n’est donc à utiliser que sur un site ou service accessible que de vous (ou petit groupe de personne).
Nous allons donc générer un certificat depuis une machine GNU/Linux, ce couple certificat/clé visant à être utilisé avec Nginx, Apache ou autre serveur web.
Génération de la clé
openssl genrsa -out key.pem 4096
La clé s’appellera key.pem, et sera généré sur 4096 bits avec RSA, un algorithme de chiffrement asymétrique.
Génération du certificat
openssl req -new -x509 -sha512 -days 3650 -key key.pem -out cert.pem
On crée le certificat cert.pem, auto-signé (-x509), hashé sur 512 bits avec SHA-2, et valable 10 ans.
Si vous souhaitez utiliser ce certificat pour des sous-domaine il faut rentrer quelque chose du type *.angrisan.fr dans le champ Common Name.
Génération du paramètre Diffie-Hellman
Pour améliorer la sécurité de l’échange chiffré, vous pouvez dire au serveur web d’utiliser un autre dhparam, comme par exemple celui que nous allons générer. Ce paramètre n’a pas de rapport direct avec le certificat, mais il est important dans le paramétrage de votre serveur web.
openssl dhparam 4096 -out dh4096.pem
Cette commande génère un paramètre DH de 4096 bits, contre 1024 de base.
N’oubliez pas de réduire au maximum les permissions de ces fichiers, avec un chmod 600 par exemple.
Voilà, nous avons généré les 3 fichiers pour notre implémentation de HTTPS.
Dans un prochain article, je parlerais des bons paramètres à avoir sur Nginx afin d’assurer une sécurité maximale.
Dernière modification le 4 septembre 2017.
Dans le livre de Snowden il affirme avoir utilisé des clés de chiffrement de 4096 et 8192 bits
j’aimerais un exemple svp
j’suis littéralement fou amoureux de la cryptographies
Il y a une toute petite coquille dans la commande : il manque une espace entre « -sha512 » et « -days 3650 » 🙂
Oh la coquille ! Merci 😉
Une procédure clairement documentée. J’attends avec impatience l’article sur la sécurisation de NginX je crois que je peux améliorer mon paramétrage sur ce plan là.
Merci ! Ça arrive ! 🙂
Sinon il y a http://www.startssl.com qui est déjà gratos et reconnu
Oui je connais, et c’est très bien pour un site web. Là le tuto concerne un Wildcard auto-signé pour des services perso 😉
Le Wildcard « c’est le mal » … C’est pas moi qui le dit, c’est un expert en sécu. Les wildcards représentent un gros risque en cas de compromission.
Je cite:
« Le certificat omni-domaine ou wildcard est défini dans la RFC 2818. C’est un certificat pour serveur TLS
dont le nom du sujet a la forme *.insa-toulouse.fr et qui peut donc fonctionner pour tout service dont le
nom du sujet a la même forme. Un service ayant un tel certificat peut donc se substituer à tout service
ayant un certificat spécifique, et si la clé privée associée à un certificat wildcard est compromise,
l’ensemble de la sécurité de l’organisme l’est également. Il est donc évident que la clé privée associée doit
être particulièrement protégée, idéalement par l’utilisation d’une enceinte cryptographique dans laquelle la
clé secrète est générée en interne. »
Source => https://conf-ng.jres.org/2015/document_revision_2099.html?download
Je suis tout à fait d’accord, mais qui va utiliser un wildcard auto-signé pour un site public ou une institution ? Comme je l’ai précisé, cette méthode est valable pour des services personnels. Pour ma part j’utilise maintenant Let’s Encrypt ou StartSSL.
Ouaip, mais Let’s Encrypt supporte le SNI: le cn contient le nom du service, mais on peut aussi ajouter des alias. Pratique quand on héberge plusieurs sites derrière un reverse-proxy !
J’ai quelques recettes de cuisine sur le sujet sur mon blog, dont un script pour le renouvellement automatique de certificats let’s Encrypt (pour un reverse-proxy Nginx).