Qu’est-ce qu’un certificat SSL ?

Un cadenas dans la barre d’adresse, une URL qui commence par https, une alerte rouge qui bloque l’accès à un site : derrière ces signaux familiers se cache un mécanisme précis, le certificat SSL. Ce fichier de données installé sur un serveur web fait simultanément office de carte d’identité pour le site et de dispositif de chiffrement pour les échanges. Il garantit que vous parlez bien au bon serveur, et que personne ne peut lire ni altérer les données en transit. Ce qu’il ne garantit pas, en revanche, c’est la fiabilité morale du site : un site frauduleux peut tout à fait posséder un certificat SSL valide. Comprendre cette nuance change la façon dont on lit le cadenas. Cet article explique comment fonctionne ce mécanisme, comment en obtenir un, comment en générer un correctement, et comment corriger les erreurs les plus fréquentes.

Certificat SSL : définition et rôle

Un certificat SSL est un fichier de données électronique installé sur le serveur d’origine d’un site web. Son nom complet est Secure Sockets Layer certificate, bien que le protocole sous-jacent soit aujourd’hui TLS (Transport Layer Security), version modernisée et plus robuste de SSL. L’appellation « SSL » reste néanmoins la plus répandue dans le langage courant, et les deux termes sont souvent utilisés de façon interchangeable.

Ce certificat remplit trois fonctions distinctes et complémentaires :

• Authentification : il prouve que le serveur contacté est bien celui qu’il prétend être. C’est l’équivalent d’une pièce d’identité présentée à l’entrée d’un bâtiment.
• Chiffrement : il permet d’établir une connexion chiffrée entre le navigateur et le serveur, rendant les données illisibles pour tout tiers qui les intercepterait en chemin.
• Intégrité : il garantit que les données transmises n’ont pas été modifiées ou corrompues durant le transit.

Sans certificat SSL valide, un site fonctionne en HTTP simple, protocole dans lequel toutes les données circulent en clair. Identifiants, mots de passe, numéros de carte bancaire : tout est lisible par quiconque intercepte le trafic réseau. Le passage à HTTPS (HyperText Transfer Protocol Secure) règle ce problème en ajoutant la couche TLS.

Le certificat SSL active des indicateurs visibles dans le navigateur : le cadenas dans la barre d’adresse et le préfixe https:// dans l’URL. Ces signaux rassurent l’utilisateur, mais il convient de ne pas leur faire dire plus qu’ils ne signifient. Un certificat SSL confirme que la connexion est chiffrée et que le domaine a été vérifié à un certain niveau. Il ne certifie pas que le propriétaire du site est honnête ou que le contenu est fiable. Des campagnes de phishing utilisent régulièrement des certificats SSL valides pour paraître légitimes.

Côté serveur, le certificat contient la clé publique du site. Cette clé est librement distribuée et sert à initier le chiffrement. La clé privée, elle, reste secrète sur le serveur et permet de déchiffrer ce que la clé publique a chiffré. Ce mécanisme de cryptographie asymétrique est au cœur du fonctionnement TLS, qu’il convient maintenant d’examiner en détail.

Comment fonctionne un certificat SSL lors d’une connexion HTTPS

Chaque fois qu’un navigateur se connecte à un site en HTTPS, une séquence de négociation s’enclenche automatiquement : le handshake TLS. Ce processus, qui se déroule en quelques millisecondes, établit la confiance mutuelle et négocie les paramètres de chiffrement avant même qu’un octet de contenu ne soit échangé.

Le déroulé simplifié d’un handshake TLS se présente ainsi :

• Le navigateur tente de se connecter au serveur et lui demande de s’identifier.
• Le serveur envoie une copie de son certificat SSL, qui contient sa clé publique.
• Le navigateur vérifie la validité du certificat : date d’expiration, correspondance du nom de domaine, et surtout la chaîne de confiance remontant jusqu’à une autorité de certification racine reconnue.
• Si le certificat est jugé fiable, le navigateur génère une clé de session symétrique, la chiffre avec la clé publique du serveur et l’envoie.
• Le serveur déchiffre cette clé de session avec sa clé privée.
• Les deux parties partagent désormais la même clé de session et peuvent échanger des données chiffrées symétriquement, ce qui est bien plus rapide que la cryptographie asymétrique.

La version TLS 1.3, aujourd’hui recommandée, réduit ce processus à un seul aller-retour (1-RTT) contre deux pour TLS 1.2, ce qui améliore sensiblement les performances.

Deux mécanismes avancés méritent d’être mentionnés. Le SNI (Server Name Indication) permet à un même serveur physique d’héberger plusieurs certificats pour plusieurs domaines distincts : le navigateur indique dès le début du handshake quel nom de domaine il cherche à atteindre, et le serveur présente le bon certificat. Sans SNI, un serveur mutualisé ne pourrait servir qu’un seul certificat SSL par adresse IP.

L’OCSP stapling (Online Certificate Status Protocol) est une optimisation de la vérification de révocation. Normalement, le navigateur doit interroger l’autorité de certification pour savoir si un certificat n’a pas été révoqué, ce qui ajoute une requête réseau. Avec l’OCSP stapling, c’est le serveur lui-même qui joint la réponse OCSP signée lors du handshake, éliminant ce délai supplémentaire.

Une fois la connexion établie, le protocole HSTS (HTTP Strict Transport Security) peut entrer en jeu : il indique au navigateur que le site doit toujours être accédé en HTTPS, même si l’utilisateur tape l’URL en HTTP. Ce mécanisme prévient les attaques de type SSL stripping qui tentent de dégrader la connexion vers HTTP.

Comprendre ce handshake aide à diagnostiquer les erreurs : si la chaîne de certificats est incomplète, si le domaine ne correspond pas, ou si le certificat est expiré, la vérification échoue et le navigateur bloque la connexion. Mais avant d’aborder les erreurs, il faut comprendre qui délivre ces certificats et ce qu’ils contiennent précisément.

Qui délivre les certificats et que contient un certificat SSL

Un certificat SSL ne s’auto-signe pas avec autorité. Pour être reconnu par les navigateurs, il doit être émis par une autorité de certification (AC, ou CA en anglais) dont le certificat racine est présent dans le magasin de confiance du système d’exploitation ou du navigateur. Ces listes de certificats racine de confiance sont maintenues par les éditeurs de systèmes (Microsoft, Apple, Google, Mozilla) et constituent la base du modèle de confiance du web.

La structure de confiance est hiérarchique et se décompose en trois niveaux :

• Le certificat racine (root certificate) : auto-signé par l’autorité de certification, il est stocké directement dans le magasin de confiance du système. Il est rarement utilisé directement pour signer des certificats de sites web, car sa compromission serait catastrophique.
• Le certificat intermédiaire : signé par le certificat racine, il sert de relais pour émettre les certificats des sites. La plupart des autorités de certification utilisent plusieurs niveaux intermédiaires.
• Le certificat du site web, signé par un certificat intermédiaire.

Cette chaîne de certificats doit être complète et correctement configurée sur le serveur. Si le certificat intermédiaire est absent de la configuration serveur, certains navigateurs ou clients TLS ne pourront pas reconstituer la chaîne jusqu’à la racine et afficheront une erreur, même si le certificat du site est techniquement valide.

Un certificat SSL contient un ensemble de champs standardisés définis par le format X.509 :

• Le nom de domaine pour lequel il a été délivré (champ Common Name ou CN).
• Les SAN (Subject Alternative Names) : liste des domaines et sous-domaines couverts par le certificat.
• L’identité du titulaire : pour les certificats OV et EV, le nom de l’organisation, sa localisation.
• L’autorité de certification émettrice.
• La signature numérique de l’AC, qui permet de vérifier l’authenticité du certificat.
• La date d’émission et la date d’expiration.
• La clé publique et l’algorithme utilisé (RSA 2048 bits, RSA 4096 bits, ECDSA 256 bits…).
• L’empreinte numérique (fingerprint), qui identifie le certificat de façon unique.

La clé privée associée, elle, ne figure jamais dans le certificat et ne doit jamais quitter le serveur. C’est une règle absolue de sécurité.

Ces informations déterminent directement le type de certificat délivré et le niveau de vérification effectué par l’autorité de certification — ce qui conduit naturellement à la question du choix du bon type de certificat selon les besoins.

Types de certificats SSL : dV, oV, eV, wildcard et multi-domaines

Tous les certificats SSL ne sont pas équivalents en termes de vérification. L’autorité de certification peut se contenter de vérifier le contrôle d’un domaine, ou aller jusqu’à vérifier l’existence légale de l’organisation demandeuse. Ce niveau de validation définit trois grandes catégories.

Le certificat DV est le plus simple à obtenir. L’autorité de certification vérifie uniquement que le demandeur contrôle le domaine, soit par un enregistrement DNS, soit par un fichier déposé sur le serveur, soit par un email envoyé à une adresse administrative du domaine. Aucune information sur l’organisation n’est vérifiée ni affichée. C’est le type délivré par Let’s Encrypt.

Le certificat OV ajoute une couche de vérification : l’AC contrôle que l’organisation demandeuse existe légalement (registre du commerce, numéro SIRET ou équivalent selon les pays). Ces informations sont visibles dans les détails du certificat, ce qui renforce la crédibilité pour les visiteurs avertis.

Le certificat EV implique une vérification encore plus poussée de l’identité juridique, physique et opérationnelle de l’entité. Depuis août 2020, les navigateurs n’affichent plus la barre d’adresse verte et le nom de l’organisation en évidence comme ils le faisaient auparavant pour les certificats EV. L’indicateur visuel distinctif a disparu, mais les informations restent consultables dans les détails du certificat.

Au-delà du niveau de validation, deux dimensions structurelles s’ajoutent :

• Le certificat wildcard (ou certificat générique) couvre un domaine et tous ses sous-domaines de premier niveau. Un certificat wildcard pour *.exemple.fr couvrira www.exemple.fr, blog.exemple.fr, shop.exemple.fr, mais pas sub.blog.exemple.fr. Il est particulièrement utile pour les architectures multi-sous-domaines.
• Le certificat multi-domaines (ou SAN certificate) couvre plusieurs domaines distincts listés dans le champ SAN : exemple.fr, exemple.com, autredomaine.fr peuvent être regroupés dans un seul certificat, simplifiant la gestion.

Le choix se résume ainsi : un blog ou un site vitrine se contentera d’un certificat DV gratuit via Let’s Encrypt. Une entreprise souhaitant afficher ses informations légales dans le certificat optera pour un OV. Un établissement financier ou une plateforme de paiement privilégiera un EV pour le niveau de vérification qu’il implique, même si l’indicateur visuel distinctif a évolué. Pour couvrir plusieurs sous-domaines, le wildcard est économique ; pour plusieurs domaines racines distincts, le multi-domaines SAN est plus adapté.

Une fois le type de certificat choisi, la question pratique se pose : comment l’obtenir concrètement ?

Obtenir ou récupérer un certificat SSL : options gratuites et payantes

Il existe plusieurs voies pour obtenir un certificat SSL, et le choix dépend du niveau de validation souhaité, du budget et du niveau de contrôle technique disponible.

Let’s Encrypt est une autorité de certification à but non lucratif qui délivre gratuitement des certificats DV. Elle est soutenue par les principaux acteurs du web et ses certificats sont reconnus par l’ensemble des navigateurs modernes. Le processus d’émission et de renouvellement est entièrement automatisé via le protocole ACME (Automatic Certificate Management Environment). Let’s Encrypt émet des certificats d’une durée de 90 jours, ce qui oblige à mettre en place un renouvellement automatisé, généralement via l’outil Certbot. C’est la solution de référence pour tout projet qui n’a pas besoin de validation OV ou EV.

Les hébergeurs web proposent souvent l’intégration SSL directement dans leur panneau de contrôle. Certains incluent un certificat Let’s Encrypt automatiquement, d’autres proposent des certificats payants en option. Cette voie est la plus simple pour les utilisateurs sans accès direct au serveur.

Les autorités de certification commerciales (DigiCert, Sectigo, GlobalSign, etc.) proposent des certificats DV, OV et EV payants. Les tarifs varient de quelques dizaines d’euros par an pour un DV à plusieurs centaines pour un EV multi-domaines. Ces certificats ont souvent une durée de validité d’un an (depuis 2020, la durée maximale autorisée est de 398 jours pour les certificats publics).

Pour récupérer un certificat SSL existant — par exemple lors d’une migration de serveur — les éléments nécessaires sont :

• Le fichier du certificat lui-même (extension .crt ou .pem).
• Le fichier de la chaîne de certificats intermédiaires (parfois appelé bundle ou CA bundle).
• La clé privée correspondante, qui doit avoir été conservée sur le serveur d’origine au moment de la génération du CSR.

Si la clé privée a été perdue, le certificat ne peut pas être réutilisé : il faut en générer un nouveau. C’est une contrainte de sécurité fondamentale — la clé privée ne transite jamais par l’autorité de certification et n’est donc pas récupérable auprès d’elle.

Pour obtenir un certificat auprès d’une AC, les étapes préalables sont :

• Générer une clé privée sur le serveur.
• Créer un CSR (Certificate Signing Request) à partir de cette clé privée.
• Soumettre le CSR à l’autorité de certification choisie.
• Prouver le contrôle du domaine (et de l’organisation pour OV/EV).
• Recevoir le certificat signé et l’installer sur le serveur.

Ces étapes techniques méritent d’être détaillées, car c’est là que les erreurs de configuration les plus fréquentes prennent racine.

Générer un certificat SSL : cSR, clé privée et bonnes pratiques

La génération d’un certificat SSL commence sur le serveur, avant même d’interagir avec une autorité de certification. La première étape est la création de la clé privée. Cette clé est une longue chaîne de caractères générée aléatoirement, qui ne doit jamais quitter le serveur et ne doit jamais être transmise à qui que ce soit, y compris à l’AC.

Avec OpenSSL, la commande de génération d’une clé RSA 2048 bits est :

openssl genrsa -out cle_privee.key 2048

Pour une clé RSA 4096 bits (plus robuste, légèrement plus lente) ou une clé ECDSA 256 bits (plus rapide, niveau de sécurité équivalent à RSA 3072 bits), les paramètres changent en conséquence. En 2024-2025, ECDSA P-256 est recommandé pour les nouveaux déploiements car il offre un excellent compromis entre sécurité et performance.

La deuxième étape est la génération du CSR (Certificate Signing Request). Ce fichier contient la clé publique dérivée de la clé privée, ainsi que les informations sur le domaine et l’organisation. C’est ce fichier que l’on soumet à l’autorité de certification :

openssl req -new -key cle_privee.key -out demande.csr

OpenSSL demande alors de renseigner plusieurs champs :

• Common Name (CN) : le nom de domaine principal (exemple.fr ou *.exemple.fr pour un wildcard).
• Organization (O) : nom de l’organisation (obligatoire pour OV/EV, facultatif pour DV).
• Country (C) : code pays à deux lettres (FR pour la France).
• Ville, état/région, email de contact.

Pour un certificat multi-domaines, les SAN doivent être ajoutés dans le CSR via un fichier de configuration OpenSSL, ou directement gérés par l’interface de l’AC lors de la soumission.

Une fois le CSR soumis et le certificat émis par l’AC, l’installation sur le serveur consiste à :

• Placer le fichier certificat (.crt) et la chaîne intermédiaire sur le serveur.
• Configurer le serveur web (Apache, Nginx, etc.) pour pointer vers ces fichiers et vers la clé privée.
• Vérifier que la chaîne complète est bien servie (certificat + intermédiaire(s)).
• Redémarrer le serveur web et tester la connexion.

Les bonnes pratiques de sécurité à respecter impérativement :

• Ne jamais réutiliser une clé privée d’un ancien certificat. Générer une nouvelle clé à chaque renouvellement ou remplacement.
• Restreindre les permissions sur le fichier de clé privée (lecture réservée au seul utilisateur du serveur web).
• Automatiser le renouvellement avec Certbot ou un équivalent pour éviter les expirations accidentelles.
• Tester la configuration avec un outil en ligne après installation pour vérifier le niveau de sécurité TLS, la présence de la chaîne complète et l’absence de protocoles obsolètes (SSL 3.0, TLS 1.0, TLS 1.1).
• Activer HSTS une fois la configuration SSL stabilisée pour forcer le HTTPS de façon permanente.

Une configuration correcte est la meilleure prévention contre les erreurs SSL. Mais même avec une bonne configuration initiale, des problèmes surviennent. Voici comment les diagnostiquer et les résoudre.

Résoudre les erreurs de certificat SSL : causes fréquentes et correctifs

Les erreurs de certificat SSL se manifestent par des messages bloquants dans le navigateur : « Votre connexion n’est pas privée », « NET::ERR_CERT_DATE_INVALID », « SEC_ERROR_UNKNOWN_ISSUER ». Ces messages font fuir les visiteurs et signalent un problème réel qu’il faut corriger rapidement. Voici les causes les plus fréquentes et leurs solutions.

1. Certificat expiré

C’est l’erreur la plus courante. Un certificat a une date d’expiration stricte ; passé ce délai, le navigateur refuse la connexion. La solution est le renouvellement immédiat du certificat. La prévention passe par la mise en place d’alertes d’expiration (email automatique 30, 14 et 7 jours avant) et par l’automatisation du renouvellement avec Certbot pour les certificats Let’s Encrypt.

2. Nom de domaine non conforme

Le certificat a été émis pour exemple.fr mais le site est accédé via www.exemple.fr, ou inversement. La solution est soit d’émettre un certificat couvrant les deux variantes dans le champ SAN, soit de mettre en place une redirection permanente vers le domaine couvert. Un certificat wildcard résout ce problème pour tous les sous-domaines.

3. Chaîne de certificats incomplète

Le certificat intermédiaire n’est pas servi par le serveur. Certains navigateurs (notamment sur mobile) ne peuvent pas reconstituer la chaîne seuls et affichent une erreur. La solution est de configurer le serveur pour qu’il envoie le certificat du site et le ou les certificats intermédiaires dans la même réponse TLS. Le fichier de chaîne est généralement fourni par l’AC lors de l’émission.

4. Horloge système incorrecte côté client

Si l’horloge de l’ordinateur ou du smartphone est décalée de plusieurs heures ou jours, le navigateur peut considérer un certificat valide comme expiré ou pas encore valide. C’est une erreur côté client. La solution est de resynchroniser l’horloge système (NTP).

5. Certificat auto-signé

Un certificat généré sans passer par une AC reconnue n’est pas présent dans les magasins de confiance des navigateurs. Il déclenche systématiquement une alerte. En production, il faut le remplacer par un certificat émis par une AC de confiance. En environnement de développement local, il est possible d’ajouter manuellement le certificat au magasin de confiance du poste.

6. Protocole ou algorithme obsolète

Si le serveur propose uniquement TLS 1.0 ou TLS 1.1 (désactivés par défaut dans les navigateurs modernes depuis 2020-2021), ou des algorithmes de chiffrement faibles, la connexion est refusée ou dégradée. La solution est de configurer le serveur pour n’accepter que TLS 1.2 et TLS 1.3.

7. Contenu mixte (mixed content)

La page est servie en HTTPS mais charge des ressources (images, scripts, feuilles de style) via HTTP. Le cadenas peut apparaître barré ou avec un avertissement. La solution est de s’assurer que toutes les ressources de la page sont chargées en HTTPS, en utilisant des URLs relatives ou en forçant le protocole.

Une fois les erreurs corrigées, il est utile de savoir comment vérifier l’état d’un certificat SSL, que ce soit pour contrôler sa propre configuration ou pour inspecter celle d’un site tiers.

Vérifier un certificat SSL : navigateur, détails d’émission et contrôles en ligne

La vérification d’un certificat SSL commence dans le navigateur, sans aucun outil externe. La plupart des navigateurs modernes permettent d’accéder aux détails complets du certificat en quelques clics.

Dans Chrome ou Edge : cliquer sur l’icône de cadenas (ou l’icône d’information) dans la barre d’adresse, puis sur « La connexion est sécurisée », puis sur « Certificat valide ». Une fenêtre affiche alors le certificat avec ses champs complets.

Dans Firefox : cliquer sur le cadenas, puis sur « Plus d’informations », puis sur « Afficher le certificat ».

Les informations à vérifier en priorité :

• Émis pour : le nom de domaine principal et les SAN couverts. Vérifier que le domaine visité y figure bien.
• Émis par : l’autorité de certification. Identifier si c’est une AC reconnue (Let’s Encrypt, DigiCert, Sectigo, etc.).
• Validité : dates de début et de fin. S’assurer que la date courante est bien dans la plage de validité.
• Type de certificat : DV, OV ou EV, visible dans les détails du champ Subject ou dans les politiques de certificat.
• Algorithme de signature : SHA-256 est aujourd’hui la norme ; SHA-1 est obsolète et rejeté par les navigateurs modernes.

Pour un contrôle plus approfondi — notamment pour vérifier la chaîne complète, la configuration TLS du serveur, la présence de l’OCSP stapling ou le score de sécurité global — des outils en ligne spécialisés permettent d’analyser la configuration SSL/TLS d’un serveur depuis l’extérieur. Ces outils signalent les protocoles obsolètes activés, les algorithmes faibles, les certificats intermédiaires manquants et donnent une note synthétique.

Pour vérifier un certificat stocké localement (fichier .crt ou .pem), OpenSSL permet d’afficher son contenu en clair :

openssl x509 -in certificat.crt -text -noout

Cette commande affiche tous les champs du certificat : domaine, SAN, AC émettrice, dates, clé publique, empreinte. C’est l’outil de référence pour les administrateurs système.

La vérification régulière des certificats en production est une bonne pratique de maintenance. Elle permet de détecter avant les utilisateurs un certificat sur le point d’expirer — ce qui conduit directement à la question du renouvellement et de ses enjeux.

Expiration, renouvellement et impact sur la confiance et le référencement

Un certificat SSL a une durée de vie limitée. Depuis septembre 2020, la durée maximale de validité d’un certificat SSL public est fixée à 398 jours (environ 13 mois). Cette limitation, imposée par les navigateurs et les autorités de certification, vise à réduire la fenêtre d’exposition en cas de compromission d’une clé. Let’s Encrypt émet des certificats de 90 jours, ce qui impose un renouvellement trimestriel mais réduit encore davantage les risques.

Quand un certificat expire, les conséquences sont immédiates et sévères :

• Les navigateurs affichent un écran d’avertissement bloquant, avec un message du type « Votre connexion n’est pas privée ». La plupart des utilisateurs ne franchissent pas cet écran.
• Les APIs et applications qui se connectent au serveur en HTTPS échouent si elles vérifient la validité du certificat (ce qui est le comportement par défaut sécurisé).
• Le trafic organique chute brutalement : les visiteurs qui arrivent sur la page d’avertissement repartent immédiatement, ce qui dégrade les signaux comportementaux.

Sur le plan du référencement, Google a confirmé utiliser HTTPS comme signal de classement depuis 2014. Un site qui passe de HTTPS à HTTP (ou qui devient inaccessible à cause d’un certificat expiré) peut voir son positionnement se dégrader. Le retour à la normale après correction n’est pas instantané : Googlebot doit recrawler et réindexer les pages.

L’organisation du renouvellement repose sur deux piliers :

• L’automatisation : Certbot avec une tâche cron ou un timer systemd renouvelle automatiquement les certificats Let’s Encrypt avant leur expiration. Les hébergeurs proposent souvent un renouvellement automatique intégré. Pour les certificats payants OV/EV, certaines AC proposent des API ou des outils de renouvellement automatisé.
• Les alertes : configurer des notifications par email à 30, 14 et 7 jours avant l’expiration. Des outils de monitoring peuvent surveiller les certificats en production et envoyer des alertes automatiques.

Le renouvellement est aussi l’occasion de mettre à jour la configuration : adopter un algorithme de clé plus moderne, activer TLS 1.3, désactiver les protocoles obsolètes, vérifier la configuration HSTS. Traiter le renouvellement comme une opération de maintenance proactive plutôt que comme une urgence à gérer en catastrophe est la marque d’une gestion SSL mature.

Un certificat à jour, correctement configuré, avec une chaîne complète et des protocoles modernes, est invisible pour les utilisateurs — et c’est exactement l’objectif.

FAQ

Quel est le rôle d’un certificat SSL ?

Un certificat SSL authentifie l’identité d’un serveur web auprès du navigateur, chiffre les données échangées entre les deux parties via le protocole TLS, et garantit l’intégrité des données en transit. Il active le protocole HTTPS et le cadenas visible dans la barre d’adresse. Il ne garantit pas la fiabilité ou la légitimité du contenu publié sur le site.

Comment résoudre le problème de certificat de sécurité SSL ?

Il faut d’abord identifier la cause de l’erreur : certificat expiré (renouveler immédiatement), nom de domaine non couvert (émettre un certificat avec le bon SAN), chaîne de certificats incomplète (ajouter le bundle CA dans la configuration serveur), horloge système incorrecte côté client (resynchroniser via NTP), ou protocole TLS obsolète (désactiver TLS 1.0/1.1 sur le serveur). Un outil d’analyse SSL en ligne permet de diagnostiquer rapidement la configuration.

Comment puis-je récupérer un certificat SSL ?

Un certificat SSL existant se récupère en rassemblant trois éléments : le fichier certificat (.crt ou .pem), le fichier de chaîne intermédiaire (CA bundle), et la clé privée qui a été générée lors de la création du CSR. Si la clé privée a été perdue, le certificat ne peut pas être réutilisé et il faut en générer un nouveau. L’autorité de certification ne conserve pas la clé privée et ne peut pas la fournir.

Comment puis-je générer un certificat SSL ?

La génération passe par trois étapes : créer une clé privée sur le serveur avec OpenSSL (openssl genrsa), générer un CSR contenant la clé publique et les informations du domaine (openssl req -new), puis soumettre ce CSR à une autorité de certification (Let’s Encrypt pour un certificat DV gratuit, ou une AC commerciale pour OV/EV). Après émission, installer le certificat reçu et la chaîne intermédiaire sur le serveur web, puis tester la configuration.

La sécurité d’un site web repose sur une chaîne de confiance fragile : un seul maillon défaillant — certificat expiré, chaîne incomplète, clé privée compromise — suffit à déclencher des alertes qui font fuir les visiteurs et nuisent au référencement. Maîtriser le cycle de vie d’un certificat SSL, de sa génération à son renouvellement automatisé, est aujourd’hui une compétence fondamentale pour tout responsable de site web.