Ces 2 dernières semaines (c’était du 7 au 19 juillet), la communauté Debian avait posé ses valises (et toute sa geekerie) à Brest pour le DebCamp et la DebConf 2025. Et grâce à un déplacement organisé par Evolix (mon employeur) j’ai pu y participer pleinement.

Une DebConf est une conférence dédiée à la distribution Debian, organisée par la communauté. Elle a lieu tous les ans dans une ville différente du monde. C’est l’occasion pour quelques centaines de personnes de se rencontrer physiquement pour des discussions, travaux, présentations, et moments sociaux. Elle est reconnue comme étant un élément clé dans la cohésion de cette communauté globale. Généralement la DebConf se déroule du lundi au samedi avec un planning dense de présentations et quelques moments plus détendus pour favoriser la socialisation. Elle est souvent précédée par une semaine de DebCamp, beaucoup plus informel qui permet à des équipes spécialisées de se retrouver pour des sessions de travail en face-à-face, organisées ou impromptues

Ma première participation à une DebConf était en 2017 à Montréal. Depuis j’ai participé à l’organisation de plusieurs Mini DebConf ([Toulouse 2017(https://wiki.debian.org/DebianEvents/fr/2017/Toulouse)], Marseille 2019, Toulouse 2024). Ce sont des versions plus modestes et plus courtes, mais l’esprit reste identique.

Sans grande poésie je vais passer en revue les différents aspects qui m’ont marqué pendant ces 12 jours.

Travaux internes

Les quelques personnes d’Evolix qui étaient là ont pu se réserver quelques heures de travail, plus ou moins focalisées sur Debian et des projets internes en cours. On n’a rien révolutionné, mais on a pu faire avancer les choses sur plusieurs points. C’était cool d’avoir une occasion supplémentaire de le faire car dans le feu du quotidien, ça n’arrive pas si souvent que ça. Personnellement j’ai très peu gardé le contact avec le reste de l’activité de la boîte. J’avoue avoir beaucoup de mal à être dans deux dynamiques à la fois.

Video-team

J’avais très envie de mettre un peu les pieds dans l’équipe vidéo de Debian. C’est un pilier des événements car c’est ça qui fait que les présentations sont filmées pour être diffusées en direct puis disponibles au visionnage. Ils ont mis sur pieds il y a bien longtemps et raffinent année après année un dispositif professionnel de captation, de mixage, de diffusion… Ça résonne particulièrement avec mes hobbies donc je voulais m’impliquer plus. J’ai suivi leur formation pour la manipulation en direct : technicien son, opérateur caméra et réalisateur. J’ai pu assurer un de ces rôles pendant une quinzaine de sessions. Au delà de l’utilité pour la conférence, j’ai appris plein de choses en posant mille questions aux vétérans. La prochaine étape pourrait être de rentrer plus dans les coulisses. Ça sera peut-être pour une prochaine fois.

Contenu

Les contenus et les sujets présentés pendant une DebConf sont très variés mais tournent exclusivement autour de la distribution. Certaines pésentations sont très techniques et pointues, d’autres sont orientées sur la communication, la gouvernance, la diversité, la communication… Il y a en pour tous les goûts. Il arrive que je sois dans une salle et qu’une présentation me parle plus que la moyenne, mais généralement je me sens moyennement connecté car je n’ai pas un rôle central dans cette communauté. Je ne suis pas mainteneur de paquets, ni aucune autre équipe. Voici quelques présentations qui m’ont intéressé ou marqué :

• Semi-serious stand up comedy, 10 years later
• wcurl - one year later
• reproduce.debian.net - rebuilding what is distributed from ftp.debian.org
• Bits from APT
• Meet the Technical Committee
• debian.social BoF

DayTrip

Généralement en milieu de conférence, une journée spéciale — le Day Trip — permet à tout le monde de s’écarter des salles de travail et de présentation, pour aller passer une journée plus touristique. Il y a souvent plusieurs choix possibles. J’ai choisi l’option de la journée de balade à vélo sur l’Île d’Ouessant. Après 1h30 d’une traversée en bateau qui a tracassé l’estomac de quelques personnes, on a été accueilli par un grand soleil et des vélos rouges. Une belle crêperie a pris soin de nos papilles et nous a donné des forces pour arpenter l’île. On y a rencontré quelques chèvres, moutons et vaches, une végétation visiblement influencée par un climat marin rigoureux et plusieurs phares ou vigies. Les coups de soleil ont surpris les maladroits qui n’avaient pas anticipé.

Soirée « Cheese & Wine »

Autre tradition depuis 2004, une soirée est dédiée au partage de denrées alimentaires variées, par toutes les personnes intéressées. Ça va bien-sûr au-delà du vin et du fromage, même s’ils restent les composants phares de la soirée. Au total ce sont des dizaines de kilos de fromages et de litres de vin (ou autres alcools plus ou moins forts) qui ont été engloutis en 3 heures, après un après-midi entier nécessaire à la découpe, étiquetage, présentation… Anecdote marseillaise ; à Montréal nous avions apporté du pastis et des non connaisseurs s’étaient lancés dans une dégustation sans eau ajoutée. Ça nous avait fait bien rire à l’époque (plus qu’eux), donc cette année j’avais mis une étiquette explicite sur la bouteille : « add water : 5×1 ». Il faut croire que les gens ne lisent pas, car très peu d’eau a été ajoutée au super « Pastis de la Plaine » apporté par Grégory. Pour ma part, j’ai abusé d’un Parmesan de 150 mois, de la caïpirinha préparée par les brésiliens, de Gins de Martinique et de Suisse (et oui !). Je suis rentré repu et saoul, mais dignement !

Les langues

Il y avait des personnes de plus de 50 pays différents. Évidemment l’anglais est la langue de référence dans ces cas-là, mais occasionnellement des groupes se replient temporairement sur leur langue commune. On a beaucoup entendu d’allemand, de français, de portuguais/brésilien… On peut noter l’effort important que cela demande aux personnes dont l’anglais n’est pas la langue maternelle ou une langue massivement enseignée.

Notre présentation

Grégory et moi travaillons depuis plusieurs mois à une présentation de la manière dont nous maintenons à jour nos serveurs sous Debian. Après plusieurs itérations, nous avons préparé une version en anglais qui couvrait en 40 minutes les mises à jour mineures (de sécurité) et les majeures (changement de version). Un mauvais virus a malheureusement empêché Grégory de faire la présentation avec moi. J’ai l’impression que ça s’est bien déroulé. Il y a eu plusieurs questions pertinentes sur place et plus tard. La captation vidéo est de mauvaise qualité. Les diapos ont été coupées et le cadrage n’est pas super. Et comme pour quelques autres présentations, le son a été dégradé par l’enregistrement. Nous présenterons d’ailleurs (en français) ce même sujet au Capitole du Libre à Toulouse le samedi 14 novembre 2015.

Rencontres

La DebConf est surtout un événement social. C’est l’occasion de rencontrer ou retrouver des gens qui sont directement responsables de parties de la distribution ou de la communauté. Nous avons notamment pu discuter avec Lee Garrett qui maintient Ansible dans Debian. Nous avons mis en évidence que la version de Debian 13 est incompatible avec des serveurs en Debian 10 ou inférieur. Ça permis de discuter de solutions ou contournements possibles. J’ai aussi longuement discuté avec des personnes qui font un métier d’hébergeur/infogérant comme Evolix. Nous avons partagé des approches, techniques, difficultés… En dehors des paquets et du code on retrouve la très grande diversité de Debian au travers des humains qui la font vivre ; religions, langues, cultures, identités de genre… Dans un monde polarisé, chargé d’antagonismes, ça fait du bien de trouver de l’ouverture (d’esprit, de bras, de code).

L’utilisation de VirtualHosts séparés en fonction des noms de domaine est très répandue sur les serveurs Apache multi-sites. Il est intéressant de se pencher sur les mécanismes de restriction entre VirtualHosts, notamment dans le cas d’une connexion HTTPS où il y a eu récemment un renforcement de ce mécanisme (à partir de la version 2.4.64 sortie en juillet 2025) qui peut causer des changements de comportement.

Cas d’une connexion HTTP non chiffrée

Même si ce cas est de moins en moins courant, il est intéressant de rappeler le mécanisme de base pour une connexion HTTP non chiffrée : le seul moyen pour Apache de sélectionner le bon VirtualHost lors d’une requête client est de se baser sur l’entête HTTP Host (obligatoire à partir de HTTP/1.1). Voici un exemple avec netcat :

$ echo -e "GET / HTTP/1.1\r\nHost: www.debian.org\r\n\r\n" | nc www.debian.org 80
HTTP/1.1 302 Found
…

En conséquence, dans le cas d’une connexion HTTP, on peut accéder à n’importe quel VirtualHost si l’on connaît les options ServerName et ServerAlias, il n’y a pas spécialement de « restriction ». Évidemment on peut préciser des options dans le VirtualHost comme Require all denied mais c’est un autre sujet.

Rappel du fonctionnement de SNI

Avec HTTPS, il existe l’extension SNI qui consiste à ce qu’une requête client indique un nom de domaine AVANT la partie chiffrement. Cela permet notamment à Apache de sélectionner le bon certificat SSL avant de passer à la phase de chiffrement.

Pour faire une requête avec SNI, on peut utiliser l’option -servername de la commande openssl s_client :

$ openssl s_client -connect 130.89.148.77:443 -servername www.debian.org

Ainsi si l’on fait un tcpdump, on verra passer en clair « www.debian.org » au début de l’échange :

# tcpdump -s0 -XX -ni any port 443
…
    0x00c0:  002f 00ff 0100 00b0 0000 0013 0011 0000  ./..............
    0x00d0:  0e77 7777 2e64 6562 6961 6e2e 6f72 6700  .www.debian.org.
    0x00e0:  0b00 0403 0001 0200 0a00 1600 1400 1d00  ................
…

Évidemment les navigateurs web modernes utilisent SNI depuis des années, sinon une bonne partie des sites Internet souvent hébergés derrière une même adresse IP ne fonctionnerait pas.

Cas d’une connexion HTTPS

Apache a un mécanisme de restriction pour empêcher d’accéder à un VirtuaHost qui ne correspond pas au SNI présenté. Cela va renvoyer une erreur 421 Misdirected Request :

$ echo -e "GET / HTTP/1.1\r\nHost: www.example.com\r\n\r\n" | openssl s_client -connect 130.89.148.77:443 -quiet -servername www.debian.org

HTTP/1.1 421 Misdirected Request
<title>421 Misdirected Request</title>
<h1>Misdirected Request</h1>
<p>The client needs a new connection for this
request as the requested host name does not match
the Server Name Indication (SNI) in use for this
connection.</p>

Pour être précis, cela n’impose pas forcément une correspondance avec le certificat SSL, mais si l’on envoie un entête HTTP Host correspondant à un autre VirtualHost, on sera bloqué.

On peut donc distinguer deux mécanismes distincts :

1. Apache va sélectionner le « meilleur » VirtualHost qui correspond au SNI présenté (et lui envoyer le certificat SSL correspondant à l’option SSLCertificateKeyFile du VirtualHost)
2. Une fois qu’Apache a sélectionné le VirtualHost, il n’autorise d’utiliser l’entête HTTP Host que pour un nom de domaine valide pour ce VirtualHost (donc dans ServerName ou ServerAlias)

Une particularité c’est le « VirtualHost par défaut » : si l’on indique un SNI qui ne correspond à rien, on va être renvoyé vers le VirtualHost par défaut, que l’on pourra solliciter avec n’importe quel nom de domaine… sauf ceux présents dans les autres VirtualHosts !

Restriction renforcée à partir d’Apache 2.4.64

Si l’on n’utilise pas SNI, jusqu’ici Apache ne faisait pas de restriction particulière : on est renvoyé vers le « VirtualHost par défaut », et l’on peut solliciter n’importe quel nom de domaine et accéder à n’importe quel VirtualHost.

$ echo -e "GET / HTTP/1.1\r\nHost: www.debian.org.fr\r\n\r\n" | openssl s_client -connect 130.89.148.77:443 -quiet
HTTP/1.1 200 OK

Mais dans le cadre de la correction de la faille CVE-2025-23048, Apache 2.4.64 a patché (ahah) son code pour étendre la restriction exposée un peu plus haut, voici le patch : https://github.com/apache/httpd/commit/c4cfa50c9068e8b8134c530ab21674e77d1278a2

Le patch est assez simple : le code qui renvoie le 421 Misdirected Request a simplement été déplacé pour s’appliquer aussi au cas sans SNI.

Ainsi, à partir d’Apache 2.4.64, la requête précédente devrait donner :

$ echo -e "GET / HTTP/1.1\r\nHost: www.debian.org.fr\r\n\r\n" | openssl s_client -connect 130.89.148.77:443 -quiet
HTTP/1.1 421 Misdirected Request

Cela n’est pas encore le cas car a priori le serveur hébergeant « www.debian.org » tourne sous Debian 12 (bookworm) avec Apache 2.4.62.

Apache 2.4.65 est la version actuellement présente en Debian 13 (trixie) et dans Debian 11 (bullseye) depuis mi-août (via une mise à jour de sécurité LTS). Apache 2.4.65 devrait arriver dans Debian 12 (bookworm) le 6 septembre 2025 (sortie de Debian 12.12). On peut voir cela sur https://packages.debian.org/apache2

En pratique, chez nous ce changement a nécessité quelques adaptations de configuration :

• Sur certains serveurs HAProxy où l’on se connecte en HTTPS à backend sous Apache, il faut bien activer explicitement le SNI (ce qu’étonnament HAProxy ne fait jamais)
• Sur nos check_http de monitoring où l’on doit parfois ajouter l’option SNI

L’autorité de certification Sectigo a commencé à vendre depuis quelques semaines des certificats SSL/TLS signés par un certificat racine non reconnus sur certains systèmes. On vous explique pourquoi et comment résoudre ce problème.

Lorsqu’un logiciel tente d’établir une connexion SSL/TLS avec un tiers (souvent un serveur distant) il reçoit un certificat de ce serveur et vérifie s’il a été signé par un certificat racine de confiance.
La liste des certificats racine de confiance peut être gérée de plusieurs manières. En général, les navigateurs embarquent leur propre liste qui est mise à jour en même temps que le navigateur. Mais la plupart des logiciels ou bibliothèques utilisent le dépôt de confiance de leur système d’exploitation.
Il est assez rare que des nouveaux certificats racine soient ajoutés (ou retirés) et les mises à jour sont peu fréquentes et habituellement anticipables. De plus, les nouveaux certificats racine sont généralement signés de manière croisée par des certificats existants et déjà reconnus, pour faciliter leur mise en œuvre. À titre d’exemple, Let’s Encrypt a mis plusieurs années pour enfin pouvoir utiliser son propre certificat racine et se passer des signatures croisées d’autres autorités de certification.

Dans le cas présent, Sectigo (une autorité de certification majeure) a commencé il y a quelques semaines à signer des certificats avec 2 nouveaux certificats racine (appelés « E46 » et « R46 »).
Ces certificats racine ont été créés en 2021. Ils ont été diffusés en 2023 et par exemple Mozilla a commencé à les incorporer dans son dépôt de confiance en 2023.

Lors de connexions SSL/TLS à des services utilisant des certificats signés par E46 ou R46, les logiciels qui utilisent un dépôt de confiance contenant les certificats racine E46 et R46 peuvent valider la chaîne de confiance sans problème. Mais si les logiciels ne peuvent pas valider la chaîne de confiance, la connexion échoue. En cas d’erreur SSL/TLS on incrimine prioritairement (souvent à raison) une erreur de configuration du serveur qui présente le certificat, mais ici c’est plutôt le dépôt de confiance qui doit être mis à jour.

Debian – que nous utilisons sur nos serveurs – gère sa liste de certificats racine via le paquet ca-certificates. La première mention concrète de cette question remonte à février 2025 (l’intégration des certificats a été ralentie par des questions à propos de signatures croisées et de clarté sur l’utilisation effective de ces certificats). Depuis vendredi 13 juin 2025, un nouveau paquet ca-certificates contenant les certificats racine de Sectigo est disponible pour Debian 12 (la version stable actuelle).
Depuis jeudi 19 juin 2025, des paquets faits par Evolix sont disponibles pour Debian 9, 10 et 11 et ont été déployés sur nos serveurs (et conteneurs) infogérés. Et en parallèle les équipes Debian LTS et eLTS préparent des paquets plus officiels pour Debian 8/9/10/11. Les Debian en versions inférieures à 8 ne receveront pas de mise à jour par paquet. Pour rappel, Evolix supporte uniquement Debian 10, 11 et 12.

À noter qu’il est également possible d’intégrer des certificats racine manuellement si besoin.

Tout cela montre d’une part à quel point la notion de « chaîne de confiance » sur laquelle repose SSL/TLS est à la fois critique et fragile, et qu’une bonne communication entre les parties prenantes est nécessaire.

J’ai un serveur dédié infogéré par Evolix, suis-je concerné ?

Vous pouvez être concerné uniquement si vous faites des connexions SSL/TLS vers un service réseau externe qui a changé récemment son certificat. Depuis vendredi 20 juin 2025, si votre serveur (ou conteneur) est en Debian 9, 10, 11 et 12 vous ne devriez plus avoir de problème avec le dépôt de confiance du système. Si vous constatez un souci, ouvrez nous un ticket.

J’ai un serveur avec un Apache/Nginx en HTTPS, suis-je concerné ?

Vous êtes potentiellement concerné si vous avez mis en place un nouveau certificat Sectigo depuis environ 3 semaines. Dans ce cas, l’impact est que certains de vos utilisateurs ou clients risquent d’avoir des problèmes pour vous joindre tant qu’ils n’ont pas mis à jour le dépôt de confiance du système.

J’utilise Java sur mon serveur infogéré par Evolix, suis-je concerné ?

Java utilise sa propre liste de certificats racine, mais si vous utilisez Java installé par défaut sur le système, la liste devrait être identique et tout devrait être résolu à partir du vendredi 20 juin 2025 en Debian 9, 10, 11 et 12. Par contre, si vous utilisez une version spécifique de Java, vous devez gérer vous-même la liste des certificats avec la commande keytool.

J’utilise Docker sur mon serveur infogéré par Evolix, suis-je concerné ?

Pour rappel, Docker est un « mini-système indépendant », donc chaque conteneur intègre sa propre liste de certificats racine. Si vous avez besoin de mettre à jour cette liste, vous devrez reconstruire vos images.