Les certificats SSL/TLS, c’est un sujet qui m’a longtemps donné du fil à retordre. À chaque fois que je devais en installer un, c’était la même histoire : qu’est-ce qu’il y a dans ce fichier ? C’est le bon format ? Et comment je l’installe sur ce serveur ? Bref, j’étais perdu.

Cet article, c’est un peu celui que j’aurais aimé avoir sous la main à l’époque : comprendre ce qu’est un certificat, les différents types qui existent, comment fonctionne la chaîne de confiance, et surtout comment manipuler et installer ces fichiers sur Windows et Linux.

Les fondamentaux

C’est quoi SSL/TLS ?

SSL (Secure Sockets Layer) et TLS (Transport Layer Security), c’est la même chose… ou presque. SSL est le nom historique du protocole créé par Netscape dans les années 90 pour sécuriser les échanges sur Internet. TLS est son successeur, plus moderne et plus sécurisé.

Concrètement :

• SSL 1.0, 2.0, 3.0 → obsolètes et vulnérables, à ne plus utiliser
• TLS 1.0, 1.1 → dépréciés
• TLS 1.2, 1.3 → les versions actuelles et recommandées

Aujourd’hui, quand on parle de “certificat SSL”, on parle en réalité de TLS. Le terme SSL est resté dans le langage courant par habitude, mais techniquement c’est TLS qui tourne derrière.

Le port par défaut pour HTTPS est le 443 (contre 80 pour HTTP). C’est sur ce port que le serveur attend les connexions sécurisées.

C’est quoi un certificat SSL/TLS ?

Quand on se connecte à un site en HTTPS, il se passe plusieurs choses :

1. Le navigateur contacte le serveur
2. Le serveur lui envoie son certificat
3. Le navigateur vérifie que ce certificat est valide et digne de confiance
4. Si tout est OK, une connexion chiffrée s’établit

Le certificat, c’est donc la pièce centrale qui permet de prouver l’identité du serveur et d’établir une connexion sécurisée. Sans lui, pas de HTTPS.

Concrètement, un certificat contient :

• Le nom de domaine pour lequel il est valide (ex: syspirit.fr)
• Une clé publique qui sert à initier le chiffrement
• L’identité de l’émetteur (l’autorité de certification qui l’a signé)
• Une période de validité (date de début et d’expiration)
• Une signature numérique qui garantit que le certificat n’a pas été falsifié

C’est un peu comme une carte d’identité numérique : elle dit “je suis bien syspirit.fr” et une autorité reconnue (la CA) confirme que c’est vrai.

Clé privée vs Clé publique

Pour comprendre les certificats, il faut d’abord comprendre le principe de la cryptographie asymétrique. Contrairement au chiffrement classique où on utilise un seul mot de passe pour chiffrer et déchiffrer, ici on a deux clés qui fonctionnent ensemble :

• La clé publique : comme son nom l’indique, elle est publique. On peut la distribuer à tout le monde. Elle est incluse dans le certificat.
• La clé privée : elle reste secrète, uniquement sur le serveur. Elle ne doit jamais être partagée.

Le principe est simple :

• Ce qui est chiffré avec la clé publique ne peut être déchiffré qu’avec la clé privée
• Ce qui est signé avec la clé privée peut être vérifié avec la clé publique

C’est ce mécanisme qui permet d’établir une connexion sécurisée : le client utilise la clé publique du serveur (contenue dans le certificat) pour initier un échange chiffré, et seul le serveur qui possède la clé privée correspondante peut déchiffrer et répondre.

La chaîne de confiance (PKI)

OK, on a un certificat avec une clé publique. Mais comment le navigateur sait qu’il peut lui faire confiance ? N’importe qui peut générer un certificat…

C’est là qu’interviennent les autorités de certification (CA). Une CA, c’est un organisme reconnu (DigiCert, Let’s Encrypt, Sectigo…) qui vérifie l’identité du demandeur avant de signer son certificat. Cette signature, c’est la garantie que “oui, ce certificat est légitime”.

Mais les CA racines (Root CA) sont trop précieuses pour signer directement des milliers de certificats. Si une racine est compromise, c’est toute la confiance qui s’effondre. Elles délèguent donc à des CA intermédiaires.

Voici à quoi ressemble une chaîne typique :

Root CA (racine)
    └── Intermediate CA 1 (intermédiaire)
            └── Intermediate CA 2 (intermédiaire)
                    └── Certificat serveur (votre site)

Pourquoi plusieurs intermédiaires ?

• Sécurité : si un intermédiaire est compromis, on peut le révoquer sans toucher à la racine
• Organisation : les grandes CA ont souvent plusieurs intermédiaires pour différents usages (DV, OV, EV, régions…)

Le Trust Store

Comment le navigateur sait-il quelles CA sont fiables ? Il utilise un trust store : une liste pré-installée de certificats racines de confiance.

• Windows : géré par Microsoft, accessible via certlm.msc
• Linux : fichiers dans /etc/ssl/certs/ (Debian) ou /etc/pki/ca-trust/ (RHEL)
• Navigateurs : Firefox a son propre trust store, Chrome/Edge utilisent celui du système

Ces trust stores contiennent les certificats des grandes CA publiques (DigiCert, Let’s Encrypt, GlobalSign…). C’est pour ça que quand on visite un site avec un certificat Let’s Encrypt, ça marche direct : la CA est déjà reconnue.

Et les certificats d’entreprise ?

En entreprise, c’est différent. On a souvent une CA interne (via Active Directory Certificate Services par exemple) qui génère des certificats pour les applications internes, les serveurs, le WiFi…

Le problème : cette CA interne n’est pas dans le trust store par défaut. Le navigateur ne la connaît pas. Résultat → “Certificat non approuvé” ou “Connexion non sécurisée”.

La solution ? Ajouter le certificat de la CA interne au trust store des machines. En entreprise, ça se fait généralement via GPO (Group Policy) : l’admin déploie le certificat racine de la CA sur tous les postes du domaine. Une fois fait, tous les certificats signés par cette CA seront automatiquement reconnus comme valides.

C’est pour ça qu’un certificat qui marche très bien au bureau peut afficher une erreur sur un PC perso : la CA de l’entreprise n’est pas dans son trust store.

Types de certificats

Par niveau de validation

DV (Domain Validation) : La CA vérifie simplement que vous contrôlez le domaine (via DNS ou fichier HTTP). C’est ce que propose Let’s Encrypt gratuitement. Parfait pour 90% des usages.

OV (Organization Validation) : La CA vérifie aussi l’existence légale de l’organisation. Le nom de l’entreprise apparaît dans le certificat.

EV (Extended Validation) : Vérification approfondie (documents légaux, appel téléphonique…). Historiquement, ça affichait une barre verte dans le navigateur, mais ce n’est plus le cas depuis 2019. L’intérêt est aujourd’hui discutable.

Par couverture

Wildcard : Pratique pour couvrir tous vos sous-domaines avec un seul certificat. Attention, *.syspirit.fr couvre blog.syspirit.fr mais pas sub.blog.syspirit.fr (il faudrait *.blog.syspirit.fr).

SAN (Subject Alternative Name) : Permet de mettre plusieurs domaines complètement différents dans un seul certificat. Très utilisé en entreprise.

Les formats de fichiers

C’est là que ça devient souvent confus. Plusieurs formats existent, et les extensions de fichiers ne sont pas toujours cohérentes…

Les formats principaux

PEM (Privacy Enhanced Mail)

PEM, c’est un format d’encodage : le contenu binaire du certificat est converti en texte lisible (Base64). C’est ce qui permet d’ouvrir un certificat avec un simple éditeur texte et de voir quelque chose comme ça :

-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAJC1HiIAZAiUMA0Gcg...
(contenu en Base64)
...Uv3nX8d2xPDz==
-----END CERTIFICATE-----

Le truc qui prête à confusion : l’extension du fichier ne dit pas forcément que c’est du PEM. Un fichier .crt, .cer, .pem ou .key peut être au format PEM. Ce qui compte, c’est ce qu’il y a dedans.

Comment savoir si c’est du PEM ? Si le fichier commence par -----BEGIN, c’est du PEM. Sinon, c’est probablement du binaire (DER).

Ce qu’on peut trouver dans un fichier PEM :

Un même fichier .pem peut contenir plusieurs blocs concaténés. C’est utile dans deux cas :

1. La chaîne de certificats : quand on configure un serveur web, on doit souvent fournir le certificat du site + les certificats intermédiaires. Plutôt que 3 fichiers séparés, on met tout dans un seul :

-----BEGIN CERTIFICATE-----
(certificat du site)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(certificat intermédiaire 1)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(certificat intermédiaire 2)
-----END CERTIFICATE-----

C’est ce que Let’s Encrypt appelle fullchain.pem par exemple.

2. Certificat + clé privée : certains logiciels ou appliances (HAProxy, certains load balancers, des applications legacy…) demandent un seul fichier avec tout dedans :

-----BEGIN CERTIFICATE-----
(certificat)
-----END CERTIFICATE-----
-----BEGIN PRIVATE KEY-----
(clé privée)
-----END PRIVATE KEY-----

C’est pratique pour ces cas-là, mais c’est moins recommandé côté sécurité — on préfère généralement garder la clé privée dans un fichier séparé avec des permissions restrictives.

Extensions courantes pour les fichiers PEM :

• .pem → extension générique, peut contenir n’importe quoi
• .crt / .cer → généralement un certificat
• .key → généralement une clé privée

Mais encore une fois, l’extension n’est qu’une convention. Un .crt peut très bien être en format DER (binaire) sur certains systèmes.

DER (Distinguished Encoding Rules)

Format binaire, non lisible avec un éditeur texte. Si on ouvre un fichier DER avec un éditeur, on voit des caractères incompréhensibles.

C’est exactement le même contenu qu’un fichier PEM, mais sans l’encodage Base64. DER est le format “brut”, PEM est le format “lisible”.

Quand on utilise DER plutôt que PEM ?

• Certaines applications Java préfèrent le DER
• Historiquement plus courant sur Windows (mais PFX a pris le dessus)
• Parfois requis par des équipements réseau ou des appliances

Dans la pratique, on manipule surtout du PEM sous Linux et du PFX sous Windows. Le DER est plus rare.

Extensions : .der, .cer

PFX / PKCS#12

C’est le format qu’on utilise sur Windows. Un fichier PFX est un conteneur qui regroupe tout ce dont on a besoin :

• Le certificat
• La clé privée
• Les certificats intermédiaires (optionnel)

Le tout est protégé par un mot de passe. C’est ce qui permet de transporter un certificat complet en un seul fichier sécurisé.

Cas d’usage typiques :

• Importer un certificat dans IIS
• Installer un certificat sur un serveur Windows
• Transférer un certificat d’une machine à une autre
• Sauvegarder un certificat avec sa clé privée

Quand on achète un certificat chez une CA ou qu’on en exporte un depuis Linux, on doit souvent le convertir en PFX avant de l’installer sur Windows. C’est une des conversions les plus courantes (on verra ça dans la section OpenSSL).

Extensions : .pfx, .p12 (c’est la même chose)

PKCS#7

Conteneur pour les certificats sans clé privée. Utilisé pour distribuer une chaîne de certificats uniquement.

On le croise parfois quand une CA envoie le certificat + les intermédiaires dans un seul fichier, mais sans la clé privée (qui a été générée de notre côté).

Extensions : .p7b, .p7c

Récapitulatif des fichiers

Comment reconnaître un format ?

Pas toujours évident vu que les extensions mentent parfois. Voici comment vérifier :

# Si ça commence par "-----BEGIN", c'est du PEM
head -1 certificat.crt
 
# Vérifier un fichier PEM
openssl x509 -in certificat.crt -text -noout
 
# Si erreur "unable to load certificate", essayer en DER
openssl x509 -in certificat.cer -inform DER -text -noout
 
# Vérifier un PFX (demande le mot de passe)
openssl pkcs12 -in certificat.pfx -info -noout

Conversions avec OpenSSL

OpenSSL est l’outil incontournable pour manipuler les certificats. Voici les conversions les plus courantes.

PEM ↔ DER

# PEM vers DER
openssl x509 -in certificat.pem -outform DER -out certificat.der
 
# DER vers PEM
openssl x509 -in certificat.der -inform DER -out certificat.pem

Créer un PFX (pour Windows)

C’est LA conversion qu’on fait le plus souvent : assembler le certificat, la clé privée et la chaîne dans un fichier PFX pour l’importer sur Windows.

# Certificat + clé privée
openssl pkcs12 -export -out certificat.pfx \
    -inkey cle-privee.key \
    -in certificat.crt
 
# Avec la chaîne d'intermédiaires
openssl pkcs12 -export -out certificat.pfx \
    -inkey cle-privee.key \
    -in certificat.crt \
    -certfile chaine-intermediaire.crt

On vous demandera un mot de passe pour protéger le PFX. Ne le perdez pas !

Extraire depuis un PFX

Opération inverse : récupérer les éléments d’un PFX (utile quand on migre de Windows vers Linux).

# Extraire le certificat
openssl pkcs12 -in certificat.pfx -clcerts -nokeys -out certificat.crt
 
# Extraire la clé privée
openssl pkcs12 -in certificat.pfx -nocerts -nodes -out cle-privee.key
 
# Extraire la chaîne d'intermédiaires
openssl pkcs12 -in certificat.pfx -cacerts -nokeys -out chaine.crt

L’option -nodes (no DES) évite de rechiffrer la clé privée avec un mot de passe.

Générer une CSR (demande de certificat)

Si vous devez commander un certificat auprès d’une CA :

# Générer une clé privée + CSR
openssl req -new -newkey rsa:2048 -nodes \
    -keyout cle-privee.key \
    -out demande.csr
 
# Générer une CSR depuis une clé existante
openssl req -new -key cle-privee.key -out demande.csr

Let’s Encrypt et ACME

Let’s Encrypt a révolutionné le monde des certificats en proposant des certificats DV gratuits et automatisés. Aujourd’hui, c’est la CA la plus utilisée au monde.

Le protocole ACME

ACME (Automatic Certificate Management Environment) est le protocole qui permet d’automatiser tout le processus :

1. Prouver qu’on contrôle le domaine
2. Obtenir le certificat
3. Le renouveler automatiquement

Certbot : l’outil de référence

Certbot est le client ACME officiel de Let’s Encrypt.

Installation

Debian/Ubuntu :

sudo apt update
sudo apt install certbot
 
# Pour Nginx
sudo apt install python3-certbot-nginx
 
# Pour Apache
sudo apt install python3-certbot-apache

RHEL/CentOS/Rocky :

sudo dnf install epel-release
sudo dnf install certbot
 
# Pour Nginx
sudo dnf install python3-certbot-nginx
 
# Pour Apache
sudo dnf install python3-certbot-apache

Les challenges

Pour prouver que vous contrôlez le domaine, Let’s Encrypt propose deux méthodes :

HTTP-01 : Certbot place un fichier sur votre serveur web. Let’s Encrypt le vérifie via http://votredomaine/.well-known/acme-challenge/xxx.

# Avec Nginx (configure automatiquement)
sudo certbot --nginx -d example.com
 
# Avec Apache
sudo certbot --apache -d example.com
 
# Mode standalone (arrête le serveur web temporairement)
sudo certbot certonly --standalone -d example.com

DNS-01 : Vous créez un enregistrement TXT dans votre zone DNS. Obligatoire pour les wildcards.

# Challenge DNS manuel
sudo certbot certonly --manual --preferred-challenges dns -d "*.example.com"
 
# Avec un plugin DNS (exemple Cloudflare)
sudo certbot certonly --dns-cloudflare \
    --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
    -d "*.example.com"

Renouvellement automatique

Les certificats Let’s Encrypt expirent après 90 jours. Certbot configure automatiquement un timer systemd ou une tâche cron pour le renouvellement.

# Vérifier le timer
sudo systemctl status certbot.timer
 
# Tester le renouvellement (dry-run)
sudo certbot renew --dry-run
 
# Forcer le renouvellement
sudo certbot renew --force-renewal

Où sont les fichiers ?

Après génération, les certificats se trouvent dans /etc/letsencrypt/live/votredomaine/ :

Installation sur Linux

Debian/Ubuntu

Chemins standards

Ajouter une CA au trust store

Si vous avez une CA interne ou auto-signée :

# Copier le certificat CA (doit être en .crt, format PEM)
sudo cp ma-ca.crt /usr/local/share/ca-certificates/
 
# Mettre à jour le trust store
sudo update-ca-certificates

Configuration Nginx

server {
    listen 443 ssl;
    server_name example.com;
 
    ssl_certificate /etc/ssl/certs/example.com.crt;      # ou fullchain.pem
    ssl_certificate_key /etc/ssl/private/example.com.key;
 
    # Certificats intermédiaires (si pas dans fullchain)
    # ssl_trusted_certificate /etc/ssl/certs/chain.crt;
 
    # Configurations SSL recommandées
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
 
    # ...
}

# Tester la config
sudo nginx -t
 
# Recharger
sudo systemctl reload nginx

Configuration Apache

<VirtualHost *:443>
    ServerName example.com
 
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/example.com.crt
    SSLCertificateKeyFile /etc/ssl/private/example.com.key
    SSLCertificateChainFile /etc/ssl/certs/chain.crt
 
    # ...
</VirtualHost>

# Activer le module SSL
sudo a2enmod ssl
 
# Tester et recharger
sudo apachectl configtest
sudo systemctl reload apache2

RHEL/CentOS/Rocky

Chemins standards

Ajouter une CA au trust store

# Copier le certificat CA
sudo cp ma-ca.crt /etc/pki/ca-trust/source/anchors/
 
# Mettre à jour le trust store
sudo update-ca-trust

Configuration Nginx/Apache

Identique à Debian, seuls les chemins changent (/etc/pki/tls/ au lieu de /etc/ssl/).

Permissions et sécurité

# Clé privée : lecture seule pour root
sudo chmod 600 /etc/ssl/private/example.com.key
sudo chown root:root /etc/ssl/private/example.com.key
 
# Certificat : lisible par tous
sudo chmod 644 /etc/ssl/certs/example.com.crt

Installation sur Windows

Via MMC (interface graphique)

Windows utilise le Certificate Store pour gérer les certificats. Deux consoles existent :

• certlm.msc : certificats de la machine (services, IIS…)
• certmgr.msc : certificats de l’utilisateur courant

Importer un PFX

1. Ouvrir certlm.msc (Win + R, puis certlm.msc)
2. Naviguer vers Personnel → Certificats
3. Clic droit → Toutes les tâches → Importer
4. Sélectionner le fichier .pfx
5. Entrer le mot de passe
6. Choisir “Placer tous les certificats dans le magasin suivant” → Personnel
7. Terminer

Ajouter une CA au trust store

Pour faire confiance à une CA interne :

1. Ouvrir certlm.msc
2. Naviguer vers Autorités de certification racines de confiance → Certificats
3. Clic droit → Toutes les tâches → Importer
4. Sélectionner le certificat de la CA

Via PowerShell

# Importer un PFX dans le store machine
$password = ConvertTo-SecureString -String "VotreMotDePasse" -Force -AsPlainText
Import-PfxCertificate -FilePath "C:\certs\certificat.pfx" `
    -CertStoreLocation Cert:\LocalMachine\My `
    -Password $password
 
# Lister les certificats
Get-ChildItem Cert:\LocalMachine\My
 
# Exporter un certificat (sans clé privée)
Export-Certificate -Cert Cert:\LocalMachine\My\THUMBPRINT `
    -FilePath "C:\certs\export.cer"

IIS (Internet Information Services)

Importer le certificat

1. Ouvrir IIS Manager
2. Sélectionner le serveur dans l’arborescence
3. Double-cliquer sur Certificats de serveur
4. À droite, cliquer sur Importer
5. Sélectionner le fichier .pfx et entrer le mot de passe

Configurer le binding HTTPS

1. Sélectionner votre site
2. À droite, cliquer sur Liaisons (Bindings)
3. Ajouter → Type : https, Port : 443
4. Sélectionner le certificat dans la liste déroulante
5. OK

AD CS (Active Directory Certificate Services)

Pour les environnements entreprise, Windows Server propose AD CS : une PKI interne complète pour émettre vos propres certificats.

C’est un sujet à part entière, mais en résumé :

• Vous créez votre propre CA racine
• Vous déployez les certificats via GPO
• Tous les postes du domaine font automatiquement confiance à votre CA

Utile pour les certificats internes, VPN, WiFi 802.1X, etc.

Conclusion

Les certificats SSL/TLS peuvent sembler complexes au premier abord, mais une fois qu’on comprend les concepts de base — chaîne de confiance, formats de fichiers, et outils de conversion — ça devient beaucoup plus gérable 😁.

Points clés à retenir :

• La chaîne de confiance : Root CA → Intermédiaire(s) → Certificat serveur. N’oubliez pas les intermédiaires !
• Les formats : PEM (texte, Linux) vs PFX (binaire avec clé, Windows). OpenSSL convertit tout.
• Let’s Encrypt : gratuit, automatisé, parfait pour 90% des usages
• La clé privée est sacrée : ne la partagez jamais, permissions restrictives

Avec ces bases, vous devriez pouvoir gérer la plupart des situations. Et si vous galérez encore, openssl s_client et SSL Labs sont vos meilleurs amis pour débugger !

Liens utiles :

• Let’s Encrypt
• Certbot
• OpenSSL s_client
• SSL Labs
• testssl.sh