Google et le CA/Browser Forum viennent d’annoncer la mise à mort de 11 méthodes de validation de domaine pour les certificats HTTPS. Bye bye les emails, les coups de fil, les fax (oui, y’en avait encore qui utilisaient ça) et le courrier postal pour valider les certificats car d’ici mars 2028, tout ça sera du passé.

Car quand vous demandez un certificat SSL/TLS pour votre site, l’autorité de certification doit vérifier que vous êtes bien le proprio du domaine. Historiquement, ça pouvait se faire via un email envoyé à l’adresse WHOIS, un coup de téléphone, ou même un courrier papier mais le problème, c’est que ces méthodes sont faciles à falsifier.

Des chercheurs en sécurité ont montré qu’il était possible de manipuler les données WHOIS ou d’intercepter les communications pour obtenir des certificats frauduleux et quand, malheureusement, un attaquant peut se faire passer pour le propriétaire légitime d’un domaine et obtenir un vrai certificat, ça ouvre la porte à des attaques man-in-the-middle bien méchantes.

Donc le CA/Browser Forum a voté le ballot SC-090 pour éliminer progressivement ces vieilles méthodes. Juin 2025 a vu la fin de la validation WHOIS par email, mars 2026 découragera l’utilisation des méthodes email en général, et mars 2028 ce sera le grand ménage final.

À la place, il faudra donc passer par des méthodes plus directes tels qu’un enregistrement DNS TXT avec une valeur aléatoire que l’autorité vérifiera, ou un fichier HTTP placé à un endroit précis de votre serveur. Ces méthodes permettent de prouver cryptographiquement que vous contrôlez bien le domaine, sans intermédiaire chelou.

Pour les utilisateurs lambda, ça ne change rien évidemment, vous continuerez à voir le petit cadenas dans votre navigateur. Mais pour les admins système et les responsables de sites, ça veut dire qu’il va falloir automatiser tout ça. Si vous utilisez encore des certificats validés par email, c’est donc le moment de migrer vers des outils comme ACME (le protocole derrière Let’s Encrypt).

Ce mouvement s’inscrit également dans une tendance plus large puisque le ballot SC-070 prévoit aussi de réduire la durée de validité des certificats pour les passer à 10 jours de réutilisation de la validation dès mars 2028, puis des certificats de 47 jours seulement en mars 2029. Donc autant dire que sans automatisation, ça va devenir ingérable.

Google pousse donc clairement l’écosystème vers plus de sécurité, quitte à forcer la main aux retardataires. Moins de maillons dans la chaîne, c’est moins d’opportunités pour les attaquants et je trouve que c’est plutôt une bonne nouvelle.

Source

Bonjour à tous, En ce lundi de vacances de la Toussaint – parce que oui, même en vacances, on pense aux certifs –, je vous propose un petit billet d’humeur sur un sujet qui va nous occuper dans les années à venir : la durée de vie des certificats SSL/TLS. Spoiler : ça va piquer, mais c’est (globalement) une bonne nouvelle. Enfin, presque. Disons que c’est un demi-rognotudju.

— Permalien

— Permalink

— Permalink

Les courbes elliptiques, c’est la promesse de la robustesse des communications chiffrées de TLS sans la lourdeur des tailles de clés utilisées avec l’algorithme RSA. Il ne sera pas question de mathématiques aujourd’hui (je suis trop mauvais pour ça, vous avez qu’à voir Wikipedia pour ça), juste de quelques notes sur leur utilisation, pour du certificat autosigné, de la vérification, et un micro rappel de Let’s Encrypt.

Faites une petite recherche rapide, et 99,9% des tutos pour générer un certificat, que ça soit pour de l’auto-signé, ou dans le cadre de la commande chez une autorité « classique », et vous aurez du RSA avec un panel de 2048 à 4096 bits de taille de clé. Sans faire de benchmark, je peux vous assurer que si 2048bits est assez classique, 4096 ça commence à être assez lourd à gérer. Les courbes elliptiques sont des objets mathématiques qui promettent de garder la complexité mathématique, clé de la robustesse en matière de cryptographie, mais avec une taille de clé beaucoup plus réduite, ce qui permet d’améliorer la consommation de ressources et la performance du chiffrement des communications, parce que c’est le contexte dans lequel elles ont été envisagées et déployées.

Le certificat auto-signé

Typiquement, pour déployer un virtualhost « par défaut » sur mon serveur web Nginx, j’ai voulu générer un certificat auto-signé certes, mais avec les courbes elliptiques comme base cryptographique. C’est plutôt simple au final, ça se joue en à peine plus de temps, ça repose sur l’incontournable OpenSSL, malgré les problèmes qu’il pose ces dernières années, surtout en tant que bibliothèque applicative. On commence par lister les courbes disponibles :

openssl ecparam -list_curves

Vous choisissez ce que vous voulez, pour des raisons de compatibilité, j’ai sélectionné secp384r1 qui est la plus utilisée derrière sa petite sœur en 256bits et qui est nommée prime256v1 (parce que nique la cohérence, hein). C’est au passage celle que j’utilise sur le blog

Ensuite, on fait les étapes classiques pour un autosigné :

openssl ecparam -genkey -name secp384r1 -out key.pem
openssl req -new -sha256 -key key.pem -out csr.csr
openssl req -x509 -sha256 -days 365 -in csr.csr -out certificate.pem

Pendant la phase de création du CSR, vous répondez comme vous le souhaitez aux questions, comme on est sur de l’autosigné vous pouvez être créatif si ça vous chante

Et voilà, vous n’avez plus qu’à renseigner la clé et le certificat dans votre Virtualhost par défaut, comme ça, si vous interrogez l’IP de votre serveur web, c’est ce certificat « placeholder » qui apparaitra (autosigné certes, mais certificat quand même) et ça masquera le reste de vos virtualhosts, parce que sinon le serveur web présente le premier chargé dans les configurations incluses (je me demande si j’en ferai pas une démo en live tiens…).

Vérifier la correspondance clé/certificat

Oui je sais ça parait con, mais ça m’est déjà arrivé une quantité beaucoup trop importante de fois de ne pas être certain qu’un nouveau certificat à installer correspond encore à la clé qui est déjà déployée, ou si une nouvelle clé à été générée pour l’occasion. La joie de l’infogérance et des tickets traités par plusieurs admins successivement.

Idem, quand on cherche les manipulations à effectuer, on trouve quasi systématiquement la méthode basée sur le modulus. Sauf que cette méthode est propre à l’algorithme RSA, et n’est donc pas applicable pour des courbes elliptiques. Malgré tout, on peut s’en sortir. L’astuce consiste cette fois à comparer la clé publique entre la clé et le certificat. D’abord pour la clé :

openssl ec -in key.pem -pubout |openssl md5

openssl x509 -in certificate.pem -noout -pubkey |openssl md5

Si les deux résultats sont identiques, vous pouvez les charger dans le serveur web (ou dans l’interface de votre fournisseur d’infrastructure, si vous êtes dans le claude).

La génération pour Let’s Encrypt via acme.sh

Let’s Encrypt (et certainement d’autres fournisseurs) supporte les courbes elliptiques depuis un moment déjà. Personnellement, je préfère utiliser le léger acme.sh plutôt que l’officiel certbot, que je trouve particulièrement lourd. La génération est plutôt simple :

acme.sh --issue --ecc -k ec-384 -d www.domain.tld -w /var/www/ --debug

Évidemment c’est à adapter au domaine, et au dossier par lequel il va bosser le challenge. Perso je préfère ensuite faire une installation dans un dossier dédié pour inclure la commande de rechargement du serveur web derrière :

acme.sh --install-cert -d domain.tld --fullchain-file /etc/nginx/ssl/domain.tld.crt --key-file /etc/nginx/ssl/domain.tld.key --reloadcmd "systemctl reload nginx"

---

Voilà, comme on le voit, il ne faut pas grand chose pour passer à cette méthode cryptographique, et investiguer à son sujet est à peu près aussi simple qu’avant. Juste je trouve qu’il y a vraiment peu d’articles qui incluent les courbes dans les manipulations. Bon ben voilà