Certificats numériques : comprendre X.509, TLS, autorités de certification et Let’s Encrypt

Les certificats numériques sont au cœur d’une grande partie de la sécurité moderne. HTTPS, VPN, authentification de machines, signature de code, S/MIME ou infrastructures internes reposent tous, sous différentes formes, sur la cryptographie à clé publique et sur la nécessité de répondre à une question simple :

« Comment savoir que la clé publique que je viens de recevoir appartient réellement au serveur, à la personne ou à l’organisation avec laquelle je veux communiquer ? »

Un certificat numérique apporte une réponse structurée à cette question. Il ne garantit pas que son propriétaire est sympathique, compétent ou dépourvu d’intentions criminelles. Il garantit surtout qu’une certaine identité a été associée à une certaine clé publique selon les règles de l’autorité qui a signé le certificat.

Qu’est-ce qu’un certificat numérique ?

Dans le Web et de nombreux systèmes d’entreprise, on rencontre principalement les certificats X.509.

Un certificat contient notamment :

• une clé publique ;
• une identité ou plusieurs identifiants ;
• un numéro de série ;
• une période de validité ;
• l’identité de l’émetteur ;
• des extensions précisant son usage ;
• une signature numérique de l’autorité émettrice.

Pour un serveur Web, les noms DNS couverts apparaissent principalement dans l’extension :

Subject Alternative Name
SAN

Par exemple :

DNS:chapal.be
DNS:www.chapal.be

Le certificat affirme alors que sa clé publique peut être utilisée pour l’identité correspondant à ces noms, sous réserve que le client valide correctement la chaîne de certification.

La clé privée n’est jamais dans le certificat

Le certificat est public. On peut le transmettre à tous les clients qui se connectent au serveur.

La clé privée, elle, doit rester secrète :

clé privée
→ secrète

clé publique
→ diffusée

certificat
→ public
→ contient la clé publique

Si quelqu’un vole la clé privée d’un serveur, le problème est sérieux même si le certificat lui-même n’a jamais été compromis.

Le certificat ne chiffre pas directement HTTPS

Une formulation courante consiste à dire :

« Le certificat chiffre la connexion. »

C’est pratique pour simplifier, mais techniquement incomplet.

Le certificat sert principalement à l’authentification et à établir la confiance dans une clé publique. TLS réalise ensuite le handshake cryptographique et dérive des clés de session utilisées pour protéger les échanges.

Schématiquement :

Client
  │
  │ connexion TLS
  ▼
Serveur
  │
  │ présente son certificat
  ▼
Validation du certificat
  │
  ▼
Handshake cryptographique
  │
  ▼
Création de clés de session
  │
  ▼
Trafic chiffré et authentifié

Les données applicatives sont ensuite protégées avec des algorithmes symétriques adaptés aux volumes importants.

C’est aussi pourquoi dire qu’un certificat utilise « RSA comme algorithme de chiffrement » peut être trompeur. Il faut distinguer :

• l’algorithme de la clé publique du certificat ;
• l’algorithme utilisé pour signer le certificat ;
• les mécanismes du handshake TLS ;
• les algorithmes protégeant ensuite les données de la session.

La chaîne de confiance : racine, intermédiaire et certificat serveur

Une autorité de certification ou CA ne fonctionne généralement pas en signant directement tous les certificats Web avec sa clé racine.

Une chaîne ressemble plutôt à :

CA racine
   │
   ▼
CA intermédiaire
   │
   ▼
Certificat du serveur
   │
   ▼
chapal.be

Autorité racine

Le certificat racine constitue un trust anchor. Sa présence dans le magasin de confiance du système, du navigateur ou de l’application permet de considérer cette racine comme digne de confiance pour certains usages.

Les racines publiques sont soumises aux politiques des programmes de confiance des navigateurs et systèmes d’exploitation. Elles ne deviennent donc pas toutes-puissantes simplement parce que quelqu’un a écrit « Certificate Authority » sur leur carte de visite.

Autorité intermédiaire

Les CA utilisent généralement des certificats intermédiaires pour émettre les certificats utilisateurs ou serveurs. Cela évite d’exposer quotidiennement la clé privée extrêmement sensible de la racine.

Certificat final

Le certificat du serveur est souvent appelé :

leaf certificate
end-entity certificate
subscriber certificate

Lors d’une connexion HTTPS, le serveur transmet son certificat et normalement les certificats intermédiaires nécessaires à la construction de la chaîne. La racine de confiance est généralement déjà connue du client.

Que vérifie le navigateur ?

Pour accepter un certificat TLS Web, le client examine plusieurs éléments. Il doit notamment vérifier que :

• les signatures cryptographiques de la chaîne sont valides ;
• la chaîne mène vers une racine reconnue ;
• le certificat est dans sa période de validité ;
• le nom DNS demandé correspond à une identité autorisée ;
• les contraintes et usages du certificat permettent cet usage ;
• les politiques applicables de validation sont respectées.

Si vous visitez :

https://www.chapal.be/

mais que le certificat n’autorise que :

DNS:chapal.be

le certificat ne couvre pas automatiquement :

www.chapal.be

Les deux noms doivent être couverts lorsque les deux sont utilisés.

Un certificat valide ne signifie pas « site digne de confiance »

C’est une distinction fondamentale.

HTTPS peut permettre de confirmer :

« Je communique avec le domaine affiché et cette communication est protégée contre certaines interceptions et modifications réseau. »

HTTPS ne garantit pas :

« Les personnes qui exploitent ce domaine sont honnêtes et ne voleront jamais mes informations. »

Un site de phishing peut obtenir un certificat parfaitement valide pour :

connexion-banque-exemple.invalid

s’il contrôle réellement ce domaine.

Le certificat authentifie le domaine indiqué. Il ne prétend pas que ce domaine appartient à votre banque.

C’est notamment pourquoi le cadenas ne doit jamais être interprété comme un label :

CE SITE EST GENTIL

Les navigateurs modernes ont progressivement réduit l’importance de cette représentation visuelle. La sécurité du canal doit être la norme, pas une médaille de bonne conduite.

Certificats DV, identité et contrôle du domaine

Les certificats Web automatisés comme ceux de Let’s Encrypt reposent principalement sur la validation du contrôle du domaine.

La CA vérifie que le demandeur contrôle une ressource permettant de prouver son contrôle sur :

chapal.be

Elle ne réalise pas nécessairement une enquête humaine destinée à déterminer :

qui est la personne derrière le clavier
quelle est sa moralité
si son site vend réellement ce qu'il promet

C’est une différence importante entre :

authentifier le contrôle d'un domaine

et :

certifier la fiabilité commerciale d'une organisation

Certificats auto-signés : pas forcément mauvais

Un certificat auto-signé est signé avec sa propre clé privée plutôt que par une CA tierce reconnue.

Il peut parfaitement utiliser une cryptographie solide.

Le problème est la confiance :

Qui garantit que cette clé
est vraiment celle du serveur attendu ?

Un navigateur public ne possède normalement aucune raison de lui faire confiance automatiquement.

Les certificats auto-signés ou les PKI privées peuvent néanmoins être tout à fait appropriés pour :

• laboratoires ;
• réseaux d’entreprise ;
• équipements internes ;
• environnements de développement ;
• infrastructures où une CA privée est déployée dans les trust stores des clients.

« Auto-signé » ne signifie donc pas nécessairement « cryptographiquement faible ». Cela signifie essentiellement que la confiance doit être établie autrement.

Les certificats en dehors du Web

X.509 ne sert pas uniquement à HTTPS.

Usage	Rôle possible du certificat
VPN	Authentifier passerelles, serveurs ou clients
mTLS	Authentifier simultanément serveur et client
S/MIME	Signer et chiffrer des e-mails
Signature de code	Identifier le signataire d’un logiciel et vérifier son intégrité
Wi-Fi entreprise	Authentification EAP-TLS et validation des serveurs
Machines et IoT	Identité cryptographique de périphériques
Active Directory	LDAPS, authentification, cartes à puce et autres fonctions PKI

Et PGP ?

OpenPGP utilise également de la cryptographie à clé publique et parle de certificats dans sa propre terminologie, mais son modèle de confiance est différent de la PKI X.509 classique.

Il ne faut donc pas résumer :

S/MIME
PGP
HTTPS

comme trois applications strictement identiques du même système de CA.

Expiration et révocation

Un certificat possède une période de validité délimitée notamment par :

notBefore
notAfter

Après notAfter, le certificat est expiré.

Mais un certificat peut devoir cesser d’être utilisé avant cette date, par exemple si :

• la clé privée a été compromise ;
• le certificat a été émis incorrectement ;
• le service change d’identité ;
• la CA doit invalider le certificat.

C’est le rôle des mécanismes de révocation, notamment les listes CRL et, dans certains environnements, OCSP.

Les certificats à durée de vie courte réduisent également la durée maximale pendant laquelle un certificat compromis peut rester utilisable.

Let’s Encrypt et ACME

Let’s Encrypt est une autorité de certification publique gratuite et automatisée exploitée par l’Internet Security Research Group.

Son fonctionnement repose notamment sur :

ACME
Automated Certificate Management Environment

L’objectif n’est pas seulement de délivrer gratuitement des certificats, mais surtout de rendre leur cycle de vie automatisable :

demande
↓
validation
↓
émission
↓
installation
↓
renouvellement
↓
remplacement

En 2026, le profil Let’s Encrypt classique utilise encore des certificats valables 90 jours par défaut. Cette durée doit diminuer dans les prochaines années, ce qui rend l’automatisation encore plus importante.

Un certificat à courte durée de vie n’est pas pénible lorsqu’il se renouvelle automatiquement. Un certificat d’un an renouvelé manuellement devient pénible exactement une fois par an, généralement pendant vos vacances.

Comment Let’s Encrypt vérifie le domaine ?

ACME propose plusieurs challenges.

HTTP-01

Let’s Encrypt demande au serveur de rendre accessible un jeton sous une URL ressemblant à :

http://chapal.be/.well-known/acme-challenge/...

La validation HTTP-01 nécessite que le service soit joignable sur :

TCP/80

Un serveur peut parfaitement rediriger ensuite les visiteurs vers HTTPS.

DNS-01

Le challenge DNS demande de publier temporairement un enregistrement TXT sous :

_acme-challenge.chapal.be

Cette méthode est particulièrement intéressante lorsque :

• le serveur Web n’est pas directement accessible ;
• plusieurs serveurs utilisent le même certificat ;
• on veut automatiser la validation via l’API DNS ;
• on souhaite obtenir un certificat wildcard.

Certificats wildcard

Un certificat peut notamment couvrir :

*.chapal.be

Ce motif peut correspondre par exemple à :

www.chapal.be
mail.chapal.be
vpn.chapal.be

Mais il ne couvre pas automatiquement :

chapal.be

ni :

serveur.paris.chapal.be

Pour couvrir le domaine racine et ses sous-domaines directs, on demande donc souvent :

chapal.be
*.chapal.be

Let’s Encrypt exige une validation DNS-01 pour l’émission d’un wildcard.

Tutoriel : Let’s Encrypt avec Certbot et Nginx

Supposons un serveur Debian ou Ubuntu avec :

• Nginx fonctionnel ;
• chapal.be et www.chapal.be pointant vers le serveur ;
• TCP/80 et TCP/443 correctement accessibles ;
• un accès administrateur avec sudo.

Installer Certbot

Avec les paquets de la distribution lorsque ceux-ci sont adaptés à votre version :

sudo apt update
sudo apt install certbot python3-certbot-nginx

Pour Apache :

sudo apt install certbot python3-certbot-apache

Vérifier Nginx avant modification

sudo nginx -t

Il est toujours préférable de commencer une modification automatisée avec une configuration déjà valide.

Demander et installer le certificat

sudo certbot --nginx -d chapal.be -d www.chapal.be

Certbot peut alors :

• effectuer la validation ACME ;
• obtenir le certificat ;
• installer la chaîne ;
• modifier la configuration Nginx ;
• recharger le serveur Web.

Afficher les certificats gérés par Certbot

sudo certbot certificates

Cette commande permet notamment de vérifier :

• les noms couverts ;
• la date d’expiration ;
• les chemins des certificats ;
• le nom de la configuration Certbot correspondante.

Tester le renouvellement

sudo certbot renew --dry-run

Le renouvellement réel doit être automatisé. Selon le mode d’installation de Certbot, cela peut passer notamment par :

systemd timer
ou
cron

On peut examiner les timers systemd avec :

systemctl list-timers

Le point important n’est pas de connaître par cœur l’heure à laquelle Certbot s’exécute. Le point important est de vérifier que le mécanisme de renouvellement fonctionne réellement.

Examiner un certificat avec OpenSSL

Pour inspecter le certificat présenté par un serveur :

openssl s_client -connect chapal.be:443 -servername chapal.be

Cette commande permet notamment d’observer :

• la chaîne présentée ;
• le certificat ;
• la négociation TLS ;
• le résultat de validation OpenSSL.

Pour examiner un fichier de certificat :

openssl x509 -in certificat.pem -noout -subject -issuer -dates

Pour afficher ses SAN :

openssl x509 -in certificat.pem -noout -ext subjectAltName

Les erreurs de certificat les plus courantes

Erreur	Cause probable
Certificat expiré	Renouvellement absent ou défaillant
Nom incorrect	Le SAN ne couvre pas le nom demandé
Autorité inconnue	Racine absente du trust store ou PKI privée
Chaîne incomplète	Certificat intermédiaire non fourni correctement
Certificat pas encore valide	Date incorrecte ou horloge système erronée
Clé privée incorrecte	Le certificat et la clé privée ne correspondent pas
Renouvellement ACME impossible	DNS, firewall, challenge ou configuration Web incorrects

Une horloge incorrecte peut casser TLS

La validation dépend de dates précises.

Si un ordinateur pense être en :

2034

alors qu’il est réellement en 2026, de nombreux certificats parfaitement valides peuvent soudainement sembler :

expirés

ou :

pas encore valides

NTP et la synchronisation horaire sont donc des composants indirectement importants de la PKI.

Bonnes pratiques

• Automatiser l’émission et le renouvellement. Les durées de validité diminuent progressivement dans l’écosystème Web.
• Surveiller les dates d’expiration malgré l’automatisation. Une automatisation non surveillée est simplement une panne qui prend son temps.
• Protéger les clés privées. Permissions minimales et accès strictement nécessaires.
• Ne jamais publier une clé privée. Le certificat peut être public ; la clé privée, non.
• Vérifier les SAN. Le certificat doit couvrir précisément les noms réellement utilisés.
• Servir correctement les intermédiaires. Une chaîne mal construite peut échouer sur certains clients.
• Révoquer et remplacer un certificat dont la clé privée est compromise.
• Tester périodiquement certbot renew --dry-run ou le mécanisme ACME équivalent.
• Ne pas interpréter HTTPS comme une garantie d’honnêteté du site.

Ce qu’il faut retenir

La logique générale d’un certificat X.509 peut être résumée ainsi :

identité
+
clé publique
+
période de validité
+
usages autorisés
+
signature de l'émetteur
=
certificat

Puis, côté client :

certificat serveur
↓
CA intermédiaire
↓
racine de confiance
↓
validation du nom et des contraintes
↓
authentification TLS
↓
connexion protégée

Le certificat ne garantit donc pas que :

le site est honnête
le serveur n'est pas vulnérable
l'application n'a aucun bug
vos données seront bien utilisées

Il participe à garantir que vous communiquez avec l’identité annoncée selon la chaîne de confiance utilisée et fournit la clé publique nécessaire aux mécanismes cryptographiques concernés.

Conclusion : la confiance, mais avec des signatures

Les certificats numériques transforment un problème fondamental :

« Voici une clé publique. Pourquoi devrais-je croire qu’elle appartient vraiment à chapal.be ? »

en une chaîne vérifiable :

chapal.be
↓
certificat
↓
signature intermédiaire
↓
autorité racine reconnue
↓
validation par le client

Cette architecture n’est pas magique et elle ne supprime ni le phishing, ni les vulnérabilités, ni les administrateurs qui découvrent un certificat expiré un vendredi soir.

Mais elle rend possible une infrastructure où des milliards de connexions peuvent être authentifiées et protégées automatiquement sans avoir à échanger manuellement une clé secrète avec chaque serveur Internet.

Et la règle opérationnelle reste particulièrement simple :

Automatisez le renouvellement, surveillez l’automatisation et protégez la clé privée.

Parce qu’un certificat qui expire à 03 h 00 reste techniquement parfaitement ponctuel.