Ce que fait TLS

Commencez par `openssl s_client -connect pixzo.nl:443` et vous verrez ce que chaque navigateur fait silencieusement : vérifier un certificat avant qu’un seul octet ne traverse la ligne. TLS gère cette vérification, et cet article explique comment les certificats, les autorités de certification et la PKIoverheid néerlandaise s’y intègrent — pour ceux qui gèrent un serveur ou délivrent des certificats.

Prérequis

• Un serveur Linux avec OpenSSL 3.x (`openssl version`)
• L’accès à un nom de domaine sur lequel vous souhaitez tester un certificat
• Des connaissances de base de la ligne de commande

Ce que fait TLS

Transport Layer Security (TLS) chiffre les données entre deux systèmes — un navigateur et un serveur web, un client mail et un serveur mail, un client API et un serveur API. Sans TLS, tout le monde sur le réseau peut lire les données. Avec TLS, non, car le protocole combine deux types de cryptographie.

Pendant la poignée de main, le client et le serveur échangent des clés avec de la cryptographie asymétrique. C’est sûr mais lent. Une fois l’échange de clés établi, la connexion passe à la cryptographie symétrique pour les données proprement dites. Plus rapide, et la clé n’est connue que des deux parties.

TLS est le successeur de SSL, considéré comme obsolète et non sécurisé. La première version de TLS, TLS 1.0, est apparue en janvier 1999 sous la forme de la RFC 2246. Depuis, il existe TLS 1.1, 1.2 et 1.3 — chacune avec un chiffrement plus fort et des poignées de main plus rapides. TLS 1.3 de 2018 est la seule version que vous devriez encore autoriser aujourd’hui.

Où les certificats entrent en jeu

La cryptographie asymétrique ne résout pas un problème : comment savoir que la clé publique que vous recevez vient vraiment du serveur et non de quelqu’un qui intercepte le trafic ? C’est à cela que servent les certificats.

Un certificat contient une clé publique, des informations d’identité sur le propriétaire, et une signature numérique d’une autorité de certification (CA). Cette CA est un tiers de confiance qui déclare : « cette clé appartient à ce domaine ».

Lorsque votre navigateur se connecte à un serveur, il vérifie trois choses :

1. Le certificat est-il signé par une CA que le navigateur approuve ? 2. Le certificat est-il toujours valide, c’est-à-dire ni expiré ni révoqué ? 3. Le nom de domaine dans le certificat correspond-il au serveur auquel vous vous connectez ?

Si l’une de ces trois conditions n’est pas remplie, le navigateur affiche un avertissement — ou refuse complètement la connexion.

L’infrastructure derrière : la PKI

Les certificats n’existent pas isolément. Ils s’inscrivent dans une infrastructure à clés publiques (PKI) : un ensemble de règles et de systèmes pour délivrer, gérer, renouveler et révoquer les certificats. Au sommet de cette hiérarchie se trouvent les certificats racines. Ils sont auto-signés et constituent le point d’ancrage de la confiance. Sous la racine se trouvent des CA intermédiaires qui délivrent les certificats quotidiens.

Les certificats racines ont une longue durée de validité — souvent de quinze à vingt ans. Ce n’est pas de la bureaucratie mais une nécessité : les racines sont intégrées dans les systèmes d’exploitation et les navigateurs. Les remplacer est une opération qui prend des années, car chaque appareil dans le monde doit apprendre à approuver la nouvelle racine.

OpenSSL peut inspecter un certificat. Pour un domaine :

openssl s_client -connect pixzo.nl:443 -showcerts

Cela affiche la chaîne de certificats complète : le certificat du serveur, les éventuelles CA intermédiaires, et la racine. Avec `-servername pixzo.nl`, vous forcez SNI si le serveur héberge plusieurs domaines.

PKIoverheid : les certificats gouvernementaux néerlandais

Le gouvernement néerlandais dispose de son propre environnement PKI : PKIoverheid, géré par Logius, une agence du ministère de l’Intérieur et des Relations au sein du Royaume. Cette infrastructure fournit des certificats pour les services numériques — des sites web gouvernementaux aux e-mails sécurisés et aux signatures électroniques.

PKIoverheid connaît trois certificats racines, selon une fiche d’information du NCSC :

• Staat der Nederlanden EV Root CA
• Staat der Nederlanden Root CA G3
• Staat der Nederlanden Private Root CA G1

Les racines G3 et G1 sont valables du 14 novembre 2013 au 13 novembre 2028. Il existe également une TRIAL PKIoverheid Root CA G3, valable du 12 juillet 2019 au 14 novembre 2028.

Cette longue durée de vie est courante pour les racines, mais cela signifie aussi qu’une racine compromise peut causer des dommages pendant des années. C’est pourquoi Logius contrôle strictement la délivrance sous les CA intermédiaires.

Ce qui a mal tourné et pourquoi cela a changé

PKIoverheid a connu des incidents. Logius a signalé le 2 août 2021 que des problèmes avaient eu lieu en 2019 et 2020 avec des certificats de serveur web publiquement approuvés pour les sites web gouvernementaux. Les certificats avaient été délivrés sous une ancienne structure PKI qui ne répondait pas aux exigences des navigateurs modernes.

La réponse a été un nouveau domaine PKI : Server CA 2020, introduit à l’été 2020. Tous les certificats de serveur web publiquement approuvés pour les sites web gouvernementaux en relevaient, jusqu’à l’expiration du domaine le 6 décembre 2022.

La conséquence plus large est venue ensuite. Depuis 2022, le gouvernement n’utilise plus les certificats PKIoverheid pour les sites web accessibles au public. Ceux-ci utilisent désormais des certificats obtenus commercialement auprès de CA internationalement approuvées — pensez à Let’s Encrypt, DigiCert ou Sectigo. La raison est la compatibilité : les CA commerciales figurent dans les racines de confiance de presque tous les appareils, et leurs processus de délivrance suivent des normes internationales exigées par les navigateurs.

Cela ne signifie pas que PKIoverheid disparaît. Pour les applications internes et spécialisées — comme le courrier électronique sécurisé au sein des autorités publiques ou les signatures électroniques — l’infrastructure reste active. Et elle se renouvelle : en juillet 2026, Logius a lancé la nouvelle génération de certificats G4, à côté des G3+.

Les organisations qui utilisent PKIoverheid doivent, avant novembre 2028, passer des certificats G3(+) et G1 Private aux certificats G4. La date officielle de fin de vie pour G1 et G3 est le 12 novembre 2028, selon la FAQ de PKI Partners.

Durée de vie plus courte, plus de travail

Un autre changement touche toute personne qui gère des certificats : la durée de validité des certificats publics diminue. Du 15 mars 2026 au 15 mars 2029, la durée de vie maximale sera progressivement réduite de 398 jours à 47 jours.

La raison est la sécurité. Un certificat compromis a moins de valeur s’il expire en quelques semaines. Et un certificat qui doit être renouvelé toutes les six semaines oblige les organisations à automatiser la gestion des certificats — le renouvellement manuel n’est plus une option à 47 jours.

Cela affecte aussi le choix d’une AC. Un certificat commercial de 398 jours coûte plus cher qu’un certificat de 90 jours via Let’s Encrypt, mais à 47 jours, cette différence importe moins : il faut de toute façon automatiser. Let’s Encrypt utilise le protocole ACME pour le renouvellement automatique ; les AC commerciales le proposent désormais aussi. Ceux qui renouvellent encore manuellement leurs certificats auront un problème dans deux ans.

Créer et vérifier ses propres certificats

Les certificats suivent la norme X.509 ; la version 3 (X.509v3) est la plus utilisée. Avec OpenSSL, on crée son propre certificat :

openssl req -new -newkey rsa:2048 -nodes \
  -keyout server.key -out server.csr \
  -subj "/CN=pixzo.nl"

Cette commande génère une clé privée et une demande de signature de certificat (CSR). On envoie la CSR à une AC qui en fait un certificat. Pour un certificat auto-signé — adapté aux tests, pas à la production — on utilise :

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout server.key -out server.crt -days 90 \
  -subj "/CN=pixzo.nl" \
  -addext "subjectAltName=DNS:pixzo.nl,DNS:www.pixzo.nl"

La ligne `-addext` n’est pas un détail : les navigateurs modernes ignorent le champ CN et ne regardent que le Subject Alternative Name (SAN). Sans SAN, Chrome refuse la connexion.

Pour les certificats de production, on définit les extensions via un fichier de configuration, comme décrit dans le manuel `x509v3_config`. On y définit SAN, Key Usage et Extended Key Usage — des champs qui déterminent à quoi un certificat peut servir. Un certificat pour l’authentification de serveur a une Extended Key Usage différente d’un certificat pour la signature de code ; les confondre provoque des erreurs lors de la validation.

Vérifier si un certificat est encore valide

Un certificat peut être révoqué avant sa date d’expiration — si la clé privée fuit, l’AC doit le révoquer. Les clients vérifient cela via le protocole Online Certificate Status Protocol (OCSP). Plutôt que de télécharger une liste complète de révocation (CRL), le client demande au serveur OCSP de l’AC : « ce certificat est-il encore valide ? »

OpenSSL peut effectuer cette vérification :

openssl ocsp -issuer issuer.crt -cert server.crt \
  -url http://ocsp.example.com -resp_text

La réponse contient le statut : `good`, `revoked` ou `unknown`. En pratique, les navigateurs le font automatiquement, mais lors du débogage de problèmes de connexion, il est utile de pouvoir vérifier manuellement si un certificat a été révoqué.

Problèmes fréquents

Chrome signale NET::ERR_CERT_COMMON_NAME_INVALID, alors que le CN est correct. Chrome ignore le champ CN depuis la version 58 et ne regarde que le SAN. Ajoutez `subjectAltName` au certificat ou à la CSR, comme dans l’exemple ci-dessus.

La chaîne est incomplète : les clients signalent un émetteur inconnu. Les serveurs doivent envoyer non seulement le certificat du serveur, mais aussi les AC intermédiaires. Seule la racine ne doit pas être envoyée — le client l’a déjà. Combinez les certificats dans le bon ordre :

cat server.crt intermediate.crt > fullchain.pem

Le renouvellement de certificat ne fonctionne plus parce que la durée de vie a été réduite. Automatisez le renouvellement avec ACME (Let’s Encrypt) ou l’outil équivalent de votre AC commerciale. Avec une durée maximale de 47 jours, le renouvellement manuel n’est plus de la gestion, mais un emploi à temps plein.

La tendance vers des durées de certificat plus courtes et la transition vers G4 chez PKIoverheid pointent toutes deux dans la même direction : la gestion des certificats devient un processus automatisé, et non une tâche annuelle. Ceux qui l’organisent maintenant auront moins de travail plus tard — et ceux qui attendent recevront la facture d’elle-même en novembre 2028.