Comment installer un certificat SSL sur un domaine

Un certificat SSL (Secure Sockets Layer / TLS) est un identifiant cryptographique émis par une Autorité de Certification (CA) de confiance qui authentifie l’identité de votre serveur et établit un canal chiffré entre le serveur et le navigateur du client. Lorsqu’il est correctement installé, il fait passer votre site de http:// à https://, active le cadenas du navigateur et empêche l’interception des données transmises par des attaques de type man-in-the-middle.

Pour le SEO, Google considère HTTPS comme un signal de classement confirmé depuis 2014. Pour les utilisateurs, un certificat manquant ou mal configuré déclenche des avertissements de sécurité dans le navigateur qui nuisent aux taux de conversion. Que vous gériez une seule page de destination ou une infrastructure multi-domaines, bien configurer SSL — et le maintenir correctement — n’est pas négociable.

Prérequis avant de commencer

Avant de toucher un seul fichier de configuration, confirmez que vous disposez des éléments suivants :

• Un nom de domaine enregistré pointant vers l’adresse IP de votre serveur avec la propagation DNS complète. Vous pouvez enregistrer ou transférer un domaine via Enregistrement de domaine.
• Un bundle de certificat SSL provenant d’une CA. Celui-ci comprend généralement :

certificate.crt — votre certificat signé principal
private.key — la clé privée générée avec votre CSR
ca_bundle.crt — la chaîne CA intermédiaire (parfois appelée fichier de chaîne)
Accès au serveur ou au panneau de contrôle — soit les identifiants cPanel/Plesk, soit un accès SSH root/sudo au serveur.
Logiciel de serveur web — Apache ou Nginx, en cours d’exécution et configuré pour votre domaine.
Port 443 ouvert — vérifiez que votre pare-feu autorise le TCP entrant sur le port 443 avant d’installer quoi que ce soit.

Si vous utilisez un environnement VPS Hosting, vous disposerez d’un accès root complet et pourrez utiliser l’une des trois méthodes ci-dessous. Les utilisateurs d’hébergement mutualisé sont généralement limités à la méthode cPanel.
Choisir le bon type de certificat SSL
Tous les certificats ne sont pas équivalents. Choisir le mauvais type est une perte d’argent ou laisse des lacunes dans la couverture.



Type de certificat
Niveau de validation
Délai d’émission
Cadenas navigateur
Idéal pour








—
—
—
—
—








DV (Domain Validated)
Contrôle du domaine uniquement
Minutes
Oui
Blogs, environnements de développement, petits sites








OV (Organization Validated)
Domaine + identité de l’organisation
1–3 jours
Oui
Sites d’entreprise, plateformes SaaS








EV (Extended Validation)
Vérification complète de l’entité légale
3–7 jours
Oui (nom de l’organisation dans certains navigateurs)
E-commerce, banques, portails à haute confiance








Wildcard (`*.domain.com`)
DV ou OV
Minutes–jours
Oui
Déploiements multi-sous-domaines








Multi-domaine (SAN)
DV, OV ou EV
Variable
Oui
Plusieurs domaines distincts sur un seul certificat








Let’s Encrypt (DV gratuit)
Contrôle du domaine uniquement
Secondes
Oui
Tout domaine accessible publiquement





Pour le e-commerce en production ou tout site traitant des données de cartes de paiement, les certificats OV ou EV d’une CA commerciale sont fortement recommandés. Les certificats DV de Let’s Encrypt sont entièrement approuvés et excellents pour la plupart des cas d’usage, mais ils n’incluent pas la vérification de l’identité organisationnelle.
Vous pouvez acheter des certificats commerciaux directement via Certificats SSL si vous avez besoin d’une couverture OV, EV ou Wildcard avec un support dédié.
Méthode 1 : Installer un certificat SSL via cPanel
L’interface graphique de cPanel est le chemin le plus rapide pour les utilisateurs sur des plans d’hébergement géré ou d’hébergement web mutualisé. Si vous préférez un environnement VPS géré par cPanel, un VPS avec cPanel vous offre la même interface avec un contrôle complet du serveur.
Étape 1 : Se connecter à cPanel
Accédez à l’URL de connexion de votre cPanel :
https://yourdomain.com:2083
Authentifiez-vous avec vos identifiants d’hébergement.
Étape 2 : Accéder au gestionnaire SSL/TLS
Dans la section Sécurité du tableau de bord cPanel, cliquez sur SSL/TLS. Sélectionnez ensuite Gérer les sites SSL sous l’intitulé « Installer et gérer SSL pour votre site (HTTPS) ».
Étape 3 : Sélectionner le domaine cible
Utilisez le menu déroulant Domaine pour sélectionner le domaine que vous souhaitez sécuriser. Si le domaine n’apparaît pas, confirmez qu’il est ajouté en tant que domaine addon ou domaine principal dans cPanel.
Étape 4 : Coller les composants du certificat
Ouvrez chaque fichier de certificat dans un éditeur de texte brut (pas Word) et collez le contenu dans les champs correspondants :

Certificat (CRT) : Contenu de certificate.crt

Étape 5 : Installer et vérifier

Cliquez sur Installer le certificat. cPanel valide la paire clé-certificat avant de valider. S’il y a une incompatibilité entre la clé privée et la clé publique du certificat, cPanel rejettera l’installation avec une erreur explicite — ne l’ignorez pas.

Après l’installation, visitez https://yourdomain.com et confirmez que le cadenas apparaît. Testez également https://www.yourdomain.com si le sous-domaine www est utilisé.

Écueil courant avec cPanel : AutoSSL (l’intégration Let’s Encrypt intégrée à cPanel) peut écraser un certificat installé manuellement lors de son prochain cycle de renouvellement. Si vous avez installé un certificat commercial, désactivez AutoSSL pour ce domaine sous cPanel > Statut SSL/TLS pour éviter un remplacement non souhaité.

Méthode 2 : Installation automatisée avec Let’s Encrypt et Certbot

Certbot est le client ACME de référence pour Let’s Encrypt. Il gère la génération du CSR, la validation du domaine, la récupération du certificat, la configuration du serveur web et le renouvellement — tout automatiquement. C’est l’approche correcte pour tout serveur Linux que vous gérez directement.

Étape 1 : Se connecter à votre serveur via SSH

ssh username@your-server-ip

Étape 2 : Installer Certbot

Debian / Ubuntu (Apache) :

sudo apt update && sudo apt install -y certbot python3-certbot-apache

Debian / Ubuntu (Nginx) :

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

RHEL / AlmaLinux / Rocky Linux (Apache) :

sudo dnf install -y epel-release
sudo dnf install -y certbot python3-certbot-apache

RHEL / AlmaLinux / Rocky Linux (Nginx) :

sudo dnf install -y epel-release
sudo dnf install -y certbot python3-certbot-nginx

Étape 3 : Obtenir et installer le certificat

Pour Apache :

sudo certbot --apache -d yourdomain.com -d www.yourdomain.com

Pour Nginx :

sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

Certbot effectue par défaut un défi HTTP-01 : il place un fichier temporaire dans la racine de votre site web et demande aux serveurs de Let’s Encrypt de le récupérer via le port 80. Cela signifie que le port 80 doit être ouvert et que votre DNS doit être correctement résolu avant d’exécuter la commande.

Lorsque vous y êtes invité, sélectionnez l’option pour rediriger tout le trafic HTTP vers HTTPS. Cela inscrit une redirection permanente 301 dans la configuration de votre serveur, ce qui est le comportement correct pour le SEO et la sécurité.

Étape 4 : Vérifier le renouvellement automatique

Les certificats Let’s Encrypt expirent après 90 jours. Certbot installe un timer systemd (ou une tâche cron sur les systèmes plus anciens) qui tente le renouvellement deux fois par jour lorsque le certificat est à moins de 30 jours de son expiration. Testez la logique de renouvellement sans effectuer de renouvellement réel :

sudo certbot renew --dry-run

Un test à blanc réussi confirme que le pipeline de renouvellement est intact. Vérifiez l’état du timer avec :

systemctl status certbot.timer

Cas particulier — défi DNS-01 pour les certificats wildcard : Le défi HTTP-01 ne peut pas valider les domaines wildcard (*.yourdomain.com). Pour les wildcards, utilisez le défi DNS-01, qui nécessite la création d’un enregistrement TXT _acme-challenge dans votre zone DNS :

sudo certbot certonly --manual --preferred-challenges dns -d "*.yourdomain.com" -d yourdomain.com

Suivez les instructions pour ajouter l’enregistrement TXT, attendez la propagation DNS, puis appuyez sur Entrée pour terminer la validation.

Méthode 3 : Installation manuelle de SSL via SSH (Apache et Nginx)

L’installation manuelle vous donne un contrôle précis sur le placement des certificats, les suites de chiffrement et la configuration des hôtes virtuels. C’est l’approche privilégiée pour les serveurs de production où vous devez appliquer des politiques TLS spécifiques.

Étape 1 : Téléverser les fichiers de certificat sur le serveur

Utilisez scp pour transférer des fichiers depuis votre machine locale :

scp certificate.crt private.key ca_bundle.crt username@your-server-ip:/tmp/

Déplacez-les ensuite dans un répertoire sécurisé non accessible depuis le web :

sudo mkdir -p /etc/ssl/yourdomain
sudo mv /tmp/certificate.crt /etc/ssl/yourdomain/
sudo mv /tmp/private.key /etc/ssl/yourdomain/
sudo mv /tmp/ca_bundle.crt /etc/ssl/yourdomain/
sudo chmod 600 /etc/ssl/yourdomain/private.key
sudo chmod 644 /etc/ssl/yourdomain/certificate.crt /etc/ssl/yourdomain/ca_bundle.crt

Note de sécurité critique : La clé privée ne doit jamais être lisible par tous. La permission chmod 600 la restreint à l’utilisateur root uniquement. Sur les systèmes où Apache ou Nginx s’exécute en tant qu’utilisateur non-root (par exemple www-data), le service lit quand même la clé au démarrage en s’exécutant en tant que root avant d’abandonner les privilèges — donc 600 appartenant à root est correct.

Étape 2a : Configurer Apache

Modifiez la configuration de l’hôte virtuel pour votre domaine :

sudo nano /etc/apache2/sites-available/yourdomain.com.conf

Ajoutez ou modifiez le bloc d’hôte virtuel SSL :

<VirtualHost *:80>
    ServerName yourdomain.com
    ServerAlias www.yourdomain.com
    Redirect permanent / https://yourdomain.com/
</VirtualHost>

<VirtualHost *:443>
    ServerName yourdomain.com
    ServerAlias www.yourdomain.com

    SSLEngine on
    SSLCertificateFile      /etc/ssl/yourdomain/certificate.crt
    SSLCertificateKeyFile   /etc/ssl/yourdomain/private.key
    SSLCertificateChainFile /etc/ssl/yourdomain/ca_bundle.crt

    # Modern TLS hardening
    SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
    SSLHonorCipherOrder     off
    SSLSessionTickets       off

    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

    DocumentRoot /var/www/yourdomain
</VirtualHost>

Activez le module SSL et le site, puis redémarrez Apache :

sudo a2enmod ssl headers
sudo a2ensite yourdomain.com.conf
sudo apache2ctl configtest
sudo systemctl restart apache2

Exécutez toujours apache2ctl configtest avant de redémarrer. Une erreur de syntaxe dans le fichier de configuration mettra l’ensemble du serveur web hors service.

Étape 2b : Configurer Nginx

Modifiez le bloc serveur de votre domaine :

sudo nano /etc/nginx/sites-available/yourdomain.com

Ajoutez la configuration suivante :

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;
    return 301 https://yourdomain.com$request_uri;
}

server {
    listen 443 ssl http2;
    server_name yourdomain.com www.yourdomain.com;

    ssl_certificate      /etc/ssl/yourdomain/certificate.crt;
    ssl_certificate_key  /etc/ssl/yourdomain/private.key;
    ssl_trusted_certificate /etc/ssl/yourdomain/ca_bundle.crt;

    # Modern TLS hardening
    ssl_protocols        TLSv1.2 TLSv1.3;
    ssl_ciphers          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;
    ssl_session_cache    shared:SSL:10m;
    ssl_session_timeout  1d;
    ssl_session_tickets  off;

    # OCSP Stapling
    ssl_stapling         on;
    ssl_stapling_verify  on;
    resolver             8.8.8.8 8.8.4.4 valid=300s;

    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

    root /var/www/yourdomain;
    index index.html index.php;
}

Activez le site et testez :

sudo ln -s /etc/nginx/sites-available/yourdomain.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl restart nginx

Explication de l’OCSP Stapling : Sans stapling, le navigateur doit contacter le répondeur OCSP de la CA lors de chaque handshake TLS pour vérifier si le certificat a été révoqué. Cela ajoute de la latence et divulgue des données de navigation à la CA. Avec ssl_stapling on, Nginx met en cache la réponse OCSP et la sert directement au client, éliminant ainsi l’aller-retour.

Durcissement TLS : ce que la configuration d’origine omet

Un certificat installé avec les paramètres par défaut est sécurisé, mais pas durci. Le tableau suivant résume les directives supplémentaires qui distinguent une note SSL Labs passable d’un A+ :

Vérification et test de l’installation SSL

L’installation n’est pas terminée tant que vous n’avez pas vérifié le résultat depuis une perspective externe.

Vérification par le navigateur

Visitez https://yourdomain.com. L’icône de cadenas confirme un certificat valide et approuvé. Cliquez sur le cadenas et inspectez les détails du certificat : vérifiez que le Common Name ou le Subject Alternative Name correspond à votre domaine, et vérifiez la date d’expiration.

Test du serveur SSL Labs

Accédez à SSL Labs et entrez votre domaine. Le rapport note votre configuration TLS de F à A+ et signale des problèmes spécifiques : suites de chiffrement faibles, certificats de chaîne manquants, absence de HSTS et support des protocoles. Une note A+ nécessite HSTS avec un long max-age et l’absence de support pour TLS 1.0 ou 1.1.

Vérification en ligne de commande avec OpenSSL

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

Cela affiche la chaîne de certificats complète, la suite de chiffrement négociée et la version TLS. Recherchez Verify return code: 0 (ok) à la fin de la sortie. Tout code de retour non nul indique un problème de chaîne ou de confiance.

Pour vérifier directement la date d’expiration du certificat :

echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -dates

Vérification du contenu mixte

Après l’activation de HTTPS, le contenu mixte est le problème résiduel le plus courant. Il se produit lorsqu’une page HTTPS charge des ressources (images, scripts, feuilles de style, iframes) via HTTP. Le contenu mixte bloque entièrement les ressources actives (scripts, iframes) dans les navigateurs modernes et génère des avertissements dans la console pour les ressources passives (images).

Corrigez le contenu mixte en :

1. Mettant à jour toutes les URL http:// codées en dur dans votre CMS ou HTML vers https:// ou relatives au protocole //.
2. Ajoutant un en-tête Content Security Policy avec upgrade-insecure-requests comme solution temporaire globale :

add_header Content-Security-Policy "upgrade-insecure-requests" always;

1. Utilisant les DevTools du navigateur (F12 > Console) pour identifier les ressources spécifiques en cause.

Renouvellement des certificats et gestion du cycle de vie

Pour les certificats commerciaux gérés manuellement, définissez un rappel dans votre calendrier 30 jours avant l’expiration. Un certificat expiré est pire qu’aucun certificat — les navigateurs affichent une erreur bloquante en pleine page que les utilisateurs ne peuvent pas facilement contourner.

Si vous exploitez plusieurs domaines ou une application à fort trafic sur un Serveur Dédié, envisagez de mettre en œuvre une solution de gestion centralisée des certificats telle que cert-manager (Kubernetes), Vault PKI, ou un certificat wildcard pour réduire la charge de renouvellement sur les sous-domaines.

Matrice de décision : quelle méthode d’installation utiliser

Liste de contrôle des points techniques essentiels

• Confirmez que le port 443 est ouvert dans votre pare-feu avant d’installer tout certificat.
• Vérifiez toujours que la clé privée correspond au certificat avant l’installation : openssl x509 -noout -modulus -in certificate.crt | md5sum et openssl rsa -noout -modulus -in private.key | md5sum doivent produire des hachages identiques.
• Incluez la chaîne intermédiaire complète (ca_bundle.crt) — son omission provoque des échecs de confiance sur les navigateurs mobiles même lorsque Chrome sur ordinateur affiche un cadenas.
• Définissez chmod 600 sur le fichier de clé privée ; ne l’exposez jamais dans un répertoire accessible depuis le web.
• Désactivez TLS 1.0 et TLS 1.1 dans la configuration de votre serveur web — ces protocoles sont obsolètes et exploitables.
• Activez HSTS avec includeSubDomains uniquement après avoir confirmé que tous les sous-domaines servent également HTTPS.
• Exécutez certbot renew --dry-run après la configuration initiale de Certbot pour confirmer que le pipeline de renouvellement fonctionne.
• Testez avec SSL Labs après chaque installation ou modification de configuration.
• Vérifiez le contenu mixte immédiatement après le passage à HTTPS — il casse silencieusement les fonctionnalités.
• Pour les certificats wildcard Let’s Encrypt, utilisez le défi DNS-01, pas HTTP-01.

Foire aux questions

Quelle est la différence entre un certificat SSL et un certificat TLS ?

SSL (Secure Sockets Layer) est le protocole hérité qui a été abandonné en 1999. Son successeur, TLS (Transport Layer Security), est ce que toutes les connexions HTTPS modernes utilisent réellement. Le terme « certificat SSL » persiste comme raccourci dans l’industrie, mais chaque certificat émis aujourd’hui fonctionne sur TLS 1.2 ou TLS 1.3.

Pourquoi mon certificat SSL s’affiche-t-il comme approuvé sur Chrome mais pas sur les appareils Android ?

C’est presque toujours un certificat de chaîne intermédiaire manquant. Chrome sur ordinateur dispose d’un mécanisme agressif de récupération de certificats (AIA fetching) qui peut reconstruire la chaîne même lorsqu’elle est absente du serveur. Le magasin système d’Android ne le fait pas. Incluez toujours le fichier de chaîne ca_bundle.crt dans la configuration de votre serveur.

Puis-je installer un certificat SSL sur un domaine qui n’a pas encore de site web ?

Oui, mais uniquement si l’enregistrement DNS A du domaine pointe vers l’adresse IP du serveur. La CA doit pouvoir atteindre le serveur pour compléter la validation du domaine. Si le DNS n’est pas encore propagé, le défi échouera.

Comment renouveler un certificat SSL commercial sans interruption de service ?

Générez un nouveau CSR sur le serveur, soumettez-le à votre CA, recevez le nouveau bundle de certificat, remplacez les fichiers de certificat sur le serveur et rechargez le serveur web (systemctl reload apache2 ou systemctl reload nginx). Un rechargement applique le nouveau certificat sans interrompre les connexions existantes, contrairement à un redémarrage complet.

L’installation d’un certificat SSL redirige-t-elle automatiquement HTTP vers HTTPS ?

Non. L’installation d’un certificat active uniquement HTTPS. La redirection HTTP vers HTTPS doit être configurée séparément dans votre hôte virtuel ou bloc serveur. Les plugins --apache et --nginx de Certbot proposent de configurer cette redirection automatiquement lors de l’installation. Pour les installations manuelles, ajoutez une directive Redirect permanent (Apache) ou return 301 (Nginx) explicite dans le bloc serveur du port 80.