Textuell

En 2025 et 2026, il sera encore possible de faire signer par son autorité de certification commerciale habituelle, avec une validité d'un an, les certificats SSL/TLS "leaf" (ceux qu'on installe sur les serveurs HTTPS). Puis à partir d'avril 2026, cette période de validité des certificats SSL sera progressivement raccourcie, pour ne plus pouvoir excéder un mois, pour tous ceux signés après mars 2029. C'est la volonté de Google qui s'est imposée au sein de l'organisme de réglementation de ce type d'affaires, le Forum CA/Browser (en), dont les autorités de certifications comme les éditeurs de navigateurs web, respectent les décisions.

Autant dire que la génération manuelle des certificats SSL/TLS va peu à peu appartenir au passé, les administrateurs système étant contraints à automatiser leur renouvellement, plutôt que d'intervenir en personne tous les mois sur leurs serveurs. Cette situation est déjà connue à tous ceux qui font automatiquement signer leurs certificats par Let's Encrypt.

Générer manuellement une paire de clés à chiffrement asymétrique, puis soumettre la demande de signature de certificat correspondante à l'autorité de certification, restera une pratique en vigueur pendant quelques courtes années, jusqu'à ce que la fréquence de répétition de l'opération nous décourage tous.

Dans l'attente, ceux qui cherchent encore comment le faire trouveront de nombreux tutoriaux sur le web, expliquant l'usage de l'utilitaire en ligne de commande openssl. Une particularité de ces tutoriaux est qu'ils sont presque tous écrits pour générer des certificats utilisant des clés RSA de 2048 bits. Une valeur que le NIST déconseille de continuer à utiliser au-delà de 2030, compte tenu de l'increvable loi de Moore. Or, augmenter encore la taille des clés RSA alourdit proportionnellement celle des certificats leaf, qui sont portant transmis de manière frénétique par les serveurs, à chaque demande de négociation HTTPS provenant d'un navigateur web.

En comparaison, on ne sacrifie en rien la sécurité en choisissant les courbes elliptiques et une taille de clé de quelques centaines d'octets seulement, pour générer ce même couple de clés asymétriques et la demande de signature de certificat correspondante. Openssl supporte les courbes elliptiques depuis 15 ans tout aussi bien qu'il a supporté les clés RSA depuis aussi loin que la mémoire remonte. Passer aux algorithmes à courbes elliptiques présente l'avantage d'équiper ses serveurs de certificats SSL/TLS très légers en taille, tout en conservant au moins la même sécurité.

Il ne faut que connaitre les bonnes options à passer à openssl, et c'est ce que ce billet se propose d'explorer ici.

Les BIOS/UEFI des machines datant d'avant 2013 n'incluaient pas les SSD NVMe, ces mémoires de masse PCIe à très faible latence, parmi les périphériques de démarrage. Sur de telles machines dépourvues de slots M.2, on avait beau installer un système d'exploitation sur le SSD NVMe, le système d'exploitation ne pouvait être amorcé par l'UEFI. Pour toutes ces machines, une astucieuse solution corrige désormais cette limitation et permet de les faire profiter elles-aussi des excellents temps de latence et de transfert des mémoires de masse NVMe, comme "disque" principal de démarrage.

Clover est une suite d'utilitaires et de pilotes, disponibles sous licence libre, téléchargeables depuis GitHub, et issus des travaux sur le Hackintosh. Copié sur une clé USB, Clover devient un programme d'amorçage intermédiaire, appelé au démarrage par l'UEFI, et capable à son tour d'identifier la présence d'un système d'exploitation sur NVMe, puis de le faire ainsi démarrer. La mise en œuvre de Clover est ce que nous allons détailler ici.