La première fois que j’ai vu apparaître le message « Votre connexion n’est pas privée » sur un site que je venais de mettre en ligne, j’ai compris que quelque chose clochait sérieusement. Les avertissements de sécurité poussent une grande partie des visiteurs à quitter la page immédiatement, avant même d’avoir lu une ligne de contenu, les navigateurs modernes ne font aucun cadeau aux sites sans certificat valide. Pour une boutique e-commerce comme Croq & Câlin, qui traite des paiements en ligne chaque jour, un certificat SSL valide n’est pas une option : c’est la condition minimale pour encaisser le moindre euro.
Ce guide couvre l’installation d’un certificat SSL sur un serveur web de bout en bout, étape par étape. Ce que beaucoup ignorent, c’est que le processus paraît compliqué au premier regard, mais se décompose en actions très précises et reproductibles. La première fois prend du temps parce qu’on s’arrête sur chaque détail pour le comprendre. Par la suite, c’est un enchaînement fluide. Dans cet article, nous allons parcourir tout le parcours : choisir le bon type de certificat, générer la CSR et la clé privée, configurer Apache, Nginx ou IIS, automatiser le renouvellement avec Let’s Encrypt, convertir les formats selon l’environnement, et vérifier que tout fonctionne correctement.
Choisir le bon type de certificat avant de commencer
Beaucoup de gens sautent cette étape et se retrouvent avec un certificat inadapté à leur infrastructure, ce qui oblige à recommencer depuis le début. Prenez cinq minutes pour faire ce choix correctement.
DV, OV ou EV : quelle validation correspond à votre projet ?
Il existe trois niveaux de validation, chacun adapté à un contexte précis.
La validation de domaine (DV) est automatique, rapide, et suffisante pour la grande majorité des sites web. Elle confirme uniquement que vous contrôlez le domaine. La validation d’organisation (OV) implique une vérification manuelle de votre entreprise par l’autorité de certification : c’est pertinent pour les sites institutionnels qui veulent afficher des informations vérifiées dans les détails du certificat. La validation étendue (EV) est généralement réservée aux environnements bancaires et institutionnels où la confiance affichée doit être maximale, à titre indicatif, les principales autorités de certification (DigiCert, GlobalSign) documentent ces distinctions dans leurs politiques de validation. Pour un site vitrine, un blog ou une boutique comme Croq & Câlin, un certificat DV suffit largement dans la pratique.
Let’s Encrypt ou autorité de certification payante ?
Posons la question honnêtement : Let’s Encrypt est gratuit, reconnu par tous les navigateurs modernes, et couvre la grande majorité des besoins courants. Les certificats payants de DigiCert, Sectigo ou GlobalSign ajoutent une garantie financière en cas de fraude liée au certificat, un support dédié, et dans certains cas une validation OV ou EV intégrée, consultez les pages produits de chaque autorité de certification pour les détails précis de ces garanties. Si vous gérez un site simple ou une boutique en ligne standard, Let’s Encrypt est la réponse. Si vous opérez une plateforme financière réglementée ou que votre contrat d’assurance exige une garantie spécifique, les certificats payants valent le coût.
Certificat simple domaine, multi-domaine ou wildcard
Un certificat simple domaine couvre un seul nom de domaine (par exemple www.monsite.fr). Un certificat wildcard, noté *.monsite.fr, couvre automatiquement tous les sous-domaines du même niveau avec un seul certificat : pratique si vous hébergez shop.monsite.fr, blog.monsite.fr et api.monsite.fr. Un certificat SAN (Subject Alternative Name) couvre plusieurs domaines entièrement distincts dans un seul fichier. Choisissez selon votre architecture réelle, pas selon ce que vous imaginez avoir besoin plus tard.
Générer la CSR et la clé privée : installer un certificat SSL commence ici
La CSR, ou Certificate Signing Request, est le document que vous envoyez à l’autorité de certification pour obtenir votre certificat. Cette étape bloque souvent les débutants parce qu’elle se passe en ligne de commande et produit deux fichiers dont les rôles sont différents. Une fois qu’on comprend quoi fait quoi, tout devient clair.
La commande OpenSSL pour Apache et Nginx
Placez-vous dans le répertoire où vous souhaitez stocker vos fichiers, par exemple /etc/ssl/, puis lancez cette commande :
openssl req -sha256 -nodes -newkey rsa:2048 -keyout www.votredomaine.fr.key -out www.votredomaine.fr.csrLe paramètre -nodes génère une clé privée sans passphrase (nécessaire pour que le serveur démarre sans intervention manuelle). Le rsa:2048 définit la taille de la clé ; 4096 bits est plus sécurisé si les performances de votre serveur le permettent. La commande vous demandera ensuite plusieurs champs : Country (FR), State, Locality, Organization et surtout le Common Name, qui doit correspondre exactement au domaine à sécuriser. Pour un wildcard, saisissez *.votredomaine.fr. À la fin, vous obtenez deux fichiers : .key (la clé privée, à ne jamais partager ni envoyer à personne) et .csr (à envoyer à l’autorité de certification). Pour un pas à pas détaillé sur la génération d’une CSR avec OpenSSL, consultez le guide GlobalSign sur la génération de CSR avec OpenSSL.
Créer une CSR depuis l’interface IIS
Sur Windows, le Gestionnaire IIS propose une interface graphique pour cette étape. Ouvrez le Gestionnaire IIS, cliquez sur le serveur dans le panneau de connexions, puis sur « Certificats de serveur » et enfin « Créer une demande de certificat ». Le résultat est strictement identique à la commande OpenSSL : une CSR à envoyer à l’autorité de certification. C’est simplement une approche cliquable, sans ligne de commande, adaptée aux environnements Windows en production.
Installation d’un certificat SSL sur un serveur web : Apache, Nginx et IIS
Une fois que l’autorité de certification vous renvoie les fichiers certificat, l’étape suivante est de les placer au bon endroit et d’indiquer au serveur où les trouver. C’est souvent là que les erreurs de configuration se glissent, notamment quand le fichier de chaîne intermédiaire est oublié.
Configuration SSL dans Apache
Ajoutez ou modifiez un bloc VirtualHost pour le port 443 dans votre fichier de configuration Apache :
ServerName www.votredomaine.fr
SSLEngine on
SSLCertificateFile /etc/ssl/certs/votredomaine.fr.crt
SSLCertificateKeyFile /etc/ssl/private/votredomaine.fr.key
SSLCertificateChainFile /etc/ssl/certs/ca-bundle.crtLa directive SSLCertificateChainFile est souvent omise par les débutants, et c’est précisément ce qui provoque des avertissements sur certains navigateurs mobiles qui ne disposent pas des certificats intermédiaires en cache. Avant de recharger Apache, validez la syntaxe avec apachectl configtest : si la réponse est « Syntax OK », vous êtes prêt à recharger le service.
Configuration SSL dans Nginx
Nginx fonctionne différemment d’Apache sur un point précis : il attend un fichier « fullchain » unique qui contient à la fois votre certificat et les certificats intermédiaires concaténés dans le bon ordre. Le bloc server pour le port 443 ressemble à ceci :
server {
listen 443 ssl;
server_name www.votredomaine.fr;
ssl_certificate /etc/ssl/certs/fullchain.pem;
ssl_certificate_key /etc/ssl/private/votredomaine.fr.key;
ssl_protocols TLSv1.2 TLSv1.3;
}Testez la configuration avec nginx -t avant tout rechargement. Si vous utilisez Let’s Encrypt, le fichier fullchain.pem est généré automatiquement par Certbot et contient déjà la chaîne complète. Pour comprendre précisément pourquoi Nginx exige un fichier « fullchain » et comment concaténer correctement les certificats intermédiaires, voyez ce tutoriel sur la configuration de la chaîne SSL pour Nginx.
Liaison HTTPS dans le gestionnaire IIS
Sur IIS, commencez par importer le certificat au format PFX via « Certificats de serveur ». Ensuite, sélectionnez votre site, cliquez sur « Liaisons » dans le panneau Actions, puis sur « Ajouter ». Choisissez le type HTTPS, le port 443, et sélectionnez le certificat importé dans la liste déroulante. Si vous hébergez plusieurs sites HTTPS sur la même adresse IP, cochez l’option « Require Server Name Indication » (SNI) pour que chaque site serve son propre certificat.
Let’s Encrypt et Certbot : obtenir et renouveler automatiquement
Let’s Encrypt a changé la donne : des certificats gratuits, valides 90 jours, renouvelables sans intervention manuelle. Certbot est l’outil officiel qui gère tout ça depuis le terminal, y compris la modification automatique de la configuration du serveur web.
Installer Certbot sur Debian/Ubuntu et CentOS
Sur Debian et Ubuntu, installez Certbot avec le plugin adapté à votre serveur :
sudo apt update
sudo apt install certbot python3-certbot-nginx
# ou pour Apache :
sudo apt install certbot python3-certbot-apacheSur CentOS et ses dérivés, remplacez apt par dnf. Le plugin correspondant à votre serveur web modifie automatiquement la configuration SSL lors de l’obtention du certificat.
Obtenir un certificat en quelques commandes
Pour Nginx, lancez simplement :
sudo certbot, nginx -d votredomaine.fr -d www.votredomaine.frPour Apache, remplacez , nginx par , apache :
sudo certbot, apache -d votredomaine.fr -d www.votredomaine.frSi vous souhaitez obtenir le certificat sans modifier la configuration du serveur, utilisez le mode certonly, webroot en précisant le répertoire racine du site : cette approche n’interrompt pas le service en production.
sudo certbot certonly, webroot -w /var/www/html -d votredomaine.frLe mode , standalone est utile quand aucun serveur web n’est actif sur le port 80 au moment de la validation :
sudo certbot certonly, standalone -d votredomaine.frCe mode standalone est décrit pas à pas dans le tutoriel DigitalOcean sur Certbot en mode standalone si vous avez besoin d’un exemple concret sur CentOS 7.
Configurer le renouvellement automatique
Les certificats Let’s Encrypt expirent tous les 90 jours. La commande certbot renew ne renouvelle que les certificats proches de l’expiration (par défaut, moins de 30 jours avant la date d’expiration), donc l’exécuter fréquemment est sans risque. Sur les distributions modernes, un timer systemd est souvent déjà configuré pour lancer le renouvellement deux fois par jour, c’est la méthode recommandée. Vérifiez son état avec systemctl status certbot.timer.
Si vous préférez un cron classique, optez pour une fréquence quotidienne ou biquotidienne afin de ne pas manquer une fenêtre de renouvellement. Ajoutez par exemple cette ligne dans la crontab (renouvellement chaque jour à 3h du matin) :
0 3 * * * /usr/bin/certbot renew, quietNotez l’utilisation du chemin complet vers l’exécutable et de l’option , quiet pour éviter les sorties parasites dans les logs cron. Si vous avez le choix, privilégiez le timer systemd, mieux intégré aux distributions Linux modernes.
Convertir les formats de certificat selon votre environnement
Juste après une installation réussie, un problème surgit parfois : le serveur cible ne reconnaît pas le format du fichier fourni. Toutes les plateformes ne lisent pas les mêmes formats de certificat. IIS attend du PFX, Java utilise un keystore JKS, et la plupart des serveurs Linux travaillent en PEM. Connaître ces conversions évite de se retrouver bloqué au dernier moment avec un fichier que le serveur ne sait pas lire.
Passer de PEM/CRT en PFX pour IIS
La commande OpenSSL pour cette conversion est la suivante :
openssl pkcs12 -export -out certificat.pfx -inkey cle_privee.key -in certificat.crt -certfile ca-bundle.crtLe paramètre -certfile ca-bundle.crt est essentiel : sans lui, IIS ne dispose pas de la chaîne complète et certains navigateurs afficheront un avertissement. OpenSSL vous demande un mot de passe lors de l’export : mémorisez-le, car vous en aurez besoin au moment de l’import dans le Gestionnaire IIS. Pour un guide pas à pas sur la création d’un fichier PFX à partir de certificats PEM avec OpenSSL, vous pouvez consulter un tutoriel détaillé sur la création d’un PFX.
Importer un PFX dans un keystore Java
Les applications Tomcat et les environnements Java d’entreprise utilisent un keystore JKS. La conversion se fait avec l’outil keytool fourni avec le JDK :
keytool -importkeystore -srckeystore certificat.pfx -srcstoretype PKCS12 -destkeystore certificat.jks -deststoretype JKSCette étape est spécifique aux architectures Java. Si vous déployez sur Apache, Nginx ou IIS, vous n’avez pas besoin de keystore JKS.
Vérifier l’installation et corriger les erreurs fréquentes
Installer le certificat ne suffit pas. Il faut confirmer que les navigateurs et les outils de vérification le voient correctement, et savoir lire les messages d’erreur quand quelque chose cloche. J’ai vu des serveurs où le certificat était en place depuis des mois mais la chaîne intermédiaire manquait ; personne ne s’en était rendu compte jusqu’à ce qu’un utilisateur sur un vieux smartphone Android signale une erreur.
Tester avec SSL Labs et la commande openssl
Rendez-vous sur ssllabs.com/ssltest et saisissez votre domaine. L’outil analyse l’ensemble de la configuration et attribue une note de A à F. Une note A indique une configuration solide. Une note B ou F signale des problèmes précis : protocoles obsolètes activés, chaîne de certificats incomplète, suites cryptographiques faibles. Pour comprendre la signification des notes et des critères d’évaluation, reportez-vous au guide d’évaluation des serveurs SSL de SSL Labs. Pour un test rapide en ligne de commande sans navigateur, utilisez :
openssl s_client -connect votredomaine.fr:443 -showcertsLa sortie vous montre la chaîne présentée par le serveur et les éventuelles erreurs de validation. C’est l’outil de diagnostic le plus direct quand on veut comprendre ce que voit réellement un client qui se connecte.
Les erreurs les plus courantes et leurs solutions
Trois erreurs reviennent systématiquement lors de l’installation d’un certificat SSL sur un serveur web. Voici comment les identifier et les corriger.
La première est la chaîne de certificats incomplète : le navigateur affiche NET::ERR_CERT_AUTHORITY_INVALID parce que le fichier CA bundle manque dans la configuration. Sur Apache, ajoutez la directive SSLCertificateChainFile . Sur Nginx, concaténez le fullchain dans le fichier pointé par ssl_certificate.
La deuxième est le mismatch CN/SAN : l’erreur NET::ERR_CERT_COMMON_NAME_INVALID apparaît quand le Common Name du certificat est monsite.fr mais que l’utilisateur accède à www.monsite.fr, ou l’inverse. La correction passe par l’émission d’un nouveau certificat qui couvre les deux variantes avec un SAN, ou par une redirection systématique vers l’URL exacte couverte par le certificat.
La troisième est le certificat expiré, quasi toujours causé par l’absence de renouvellement automatique. Configurez le timer systemd ou le cron Certbot dès l’installation initiale : ne laissez pas cette étape pour plus tard.
Ce que vous savez faire maintenant
Vous venez de parcourir l’ensemble du processus d’installation d’un certificat SSL sur un serveur web. Vous savez maintenant choisir entre DV, OV et EV, décider entre Let’s Encrypt et un certificat payant, et générer la CSR avec OpenSSL ou via IIS. Vous avez configuré Apache, Nginx et IIS, automatisé le renouvellement avec Certbot, et maîtrisé les conversions entre les formats PEM, PFX et JKS. Enfin, vous savez vérifier une installation avec SSL Labs et openssl, et corriger les erreurs les plus courantes avant qu’elles n’affectent vos visiteurs. Pour consulter nos choix en matière de confidentialité relatifs aux données clients et aux paiements, la page dédiée explique nos engagements.
Passer son site en HTTPS est une compétence qui s’acquiert une fois et s’applique partout. Chaque boutique, blog ou application que vous déploierez ensuite bénéficiera du même processus. La première fois prend du temps parce qu’on comprend chaque détail en avançant. Ensuite, c’est une série de commandes et de vérifications que vous enchaînez sans hésitation. Si vous voulez mieux connaître notre histoire et notre activité, consultez notre page À Propos et, si vous souhaitez lire des retours de clients ayant utilisé notre boutique, les avis clients sont disponibles en ligne.
Ouvrez dès maintenant ssllabs.com/ssltest avec votre domaine. La note que vous obtenez est un bilan honnête de l’état réel de votre configuration, pas une estimation. Si vous voyez un A, vous avez bien fait le travail. Si vous voyez un B ou moins, la section sur les erreurs courantes vous indique exactement par où commencer.
