C'est la ligne de texte qui casse tout : "Votre connexion n'est pas privée". Vous l'avez forcément déjà vue, sur un site de mairie, une boutique en ligne, un blog oublié depuis deux ans. Et vous savez ce que fait l'internaute dans ce cas ? Il ferme l'onglet. Pas par prudence extrême : par réflexe.
Passer en HTTPS, c'est donc beaucoup plus qu'une case à cocher dans un panneau d'hébergement. C'est un chiffrement effectif, une autorité de certification qui valide votre identité, une redirection propre, et un renouvellement qui ne vous lâche pas au bout de 90 jours. J'ai installé mon premier certificat Let's Encrypt sur un VPS Ubuntu en 2021, avec une redirection HTTP→HTTPS bricolée dans un .htaccess — et j'ai découvert deux semaines plus tard que mon backoffice, appelé en HTTP en dur dans le code, refusait de charger. Je suis passé par là pour vous éviter les mêmes soirées gâchées.
Points clés à retenir
- HTTPS repose sur un certificat signé par une autorité de certification, pas sur un simple fichier posé au hasard.
- Let's Encrypt est gratuit et automatisable, avec des certificats valables 90 jours qu'il faut renouveler sans y penser.
- La redirection 301 HTTP→HTTPS est une étape distincte de l'installation du certificat : ne l'oubliez pas.
- Un site en HTTPS peut encore afficher un avertissement si des ressources sont chargées en HTTP (contenu mixte).
- L'en-tête HSTS verrouille le passage au HTTPS côté navigateur, mais se prépare avant d'être activé.
Comprendre HTTPS avant de toucher au certificat
Beaucoup d'articles sautent directement à la procédure et laissent un flou gênant. Or il faut distinguer deux choses : le chiffrement et l'authentification. HTTPS fait les deux, et c'est ce qui le rend différent d'un simple tunnel.
Quel est le rôle réel de HTTPS ?
HTTPS chiffre les échanges entre le navigateur et le serveur via TLS. Concrètement, quelqu'un qui intercepte le trafic sur un Wi-Fi public voit passer des octets illisibles, pas votre mot de passe en clair. Mais HTTPS fait aussi autre chose : il prouve que le serveur auquel vous vous connectez est bien celui qu'il prétend être, grâce au certificat signé par une autorité de certification (AC).
C'est cette seconde brique que les certificats auto-signés cassent. Le chiffrement fonctionne, mais aucune AC ne garantit l'identité : le navigateur affiche donc un avertissement. Bon à savoir si vous cherchez à « générer un certificat SSL auto-signé » : c'est parfait pour un environnement de test local, inadapté à un site public.
Ce qui se joue à chaque connexion HTTPS
Quand un visiteur arrive sur votre site, une poignée de main TLS s'exécute en quelques millisecondes : le serveur présente son certificat, le navigateur vérifie sa validité et sa chaîne de confiance, puis les deux parties négocient une clé de session. Si la chaîne est incomplète (il manque le certificat intermédiaire), vous obtenez une erreur. J'ai eu le cas une fois sur un serveur Nginx où j'avais collé uniquement le certificat final sans l'intermédiaire : Firefox passait, un vieux Safari sur mobile refusait. Un vrai casse-tête à diagnostiquer.
Comment configurer un certificat SSL, étape par étape
La méthode dépend de votre hébergement. Sur un hébergement mutualisé type cPanel ou panneau LWS, c'est trois clics et un bouton « activer SSL ». Sur un VPS, vous reprenez la main et c'est plus formateur.
Générer un certificat SSL gratuit avec Let's Encrypt
Let's Encrypt reste la référence : gratuit, automatisable, reconnu par tous les navigateurs. Sur un serveur Debian ou Ubuntu avec Nginx, l'outil Certbot fait l'essentiel du travail. La commande vérifie la propriété du domaine via un challenge HTTP, obtient le certificat, puis peut même modifier votre configuration Nginx automatiquement.
sudo certbot --nginx -d monsite.fr -d www.monsite.frDeux points d'attention, tirés de mon expérience :
- Déclarez le domaine avec et sans www si les deux doivent répondre.
- Le renouvellement se fait tous les 90 jours ; le système de tâches planifiées (cron ou timer systemd) installé par Certbot s'en occupe. Vérifiez-le avec
sudo certbot renew --dry-run, sinon la surprise arrive trois mois plus tard.
Installer un certificat fourni par l'hébergeur
Si votre hébergeur vous fournit un certificat (souvent inclus dans une offre), l'activation passe par son panneau. Vous y collez généralement deux fichiers : la clé privée et le certificat (parfois accompagné de la chaîne intermédiaire). Une fois validé, le site bascule en HTTPS sous quelques minutes. Rien de compliqué, mais lisez bien quel champ attend quoi : inverser clé et certificat est une erreur classique qui renvoie une erreur de poignée de main.
| Type de certificat | Coût | Renouvellement | Cas d'usage |
|---|---|---|---|
| Let's Encrypt | Gratuit | Automatique (90 jours) | Site public, blog, e-commerce |
| Fourni par l'hébergeur | Inclus ou payant | Selon l'offre | Mutualisé, solution clé en main |
| Auto-signé | Gratuit | Manuel | Environnement local, tests |
| Certificat payant (AC commerciale) | Payant | Annuel | Besoin de garanties ou d'un nom d'organisation vérifié |
Comment rediriger les données HTTP vers HTTPS
Installer le certificat ne suffit pas : si un visiteur tape http://monsite.fr, il accède encore à la version non sécurisée. Il faut une redirection 301, qui indique aux navigateurs et aux moteurs de recherche que l'adresse définitive est la version HTTPS. Sans elle, vous entretenez deux versions de votre site, ce qui nuit au référencement.
Redirection côté Nginx
Dans le bloc serveur écoutant sur le port 80, une seule ligne suffit :
server {
listen 80;
server_name monsite.fr www.monsite.fr;
return 301 https://$host$request_uri;
}Cette règle conserve l'URL demandée et redirige proprement. Je l'ai posée en deux minutes sur mon propre serveur, après avoir testé chaque redirection une par une pour ne pas casser d'anciennes URL.
Redirection côté Apache (.htaccess)
Sur Apache, un bloc dans le .htaccess à la racine fait l'affaire :
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]Après activation, vérifiez avec curl -I http://monsite.fr : vous devez voir un code 301 et un en-tête Location pointant vers la version HTTPS. Si vous obtenez un 200, la redirection n'est pas prise.
Contenu mixte et HSTS : les deux pièges après la bascule
Le cadenas s'affiche, vous respirez… et puis un matin, la page contact affiche un avertissement. C'est du contenu mixte : la page est chargée en HTTPS, mais certaines ressources (images, scripts, iframes) pointent encore vers du HTTP. Le navigateur bloque alors partiellement le rendu et signale une connexion partielle ou non sécurisée.
Le diagnostic se fait dans la console du navigateur : chaque ressource bloquée y apparaît en rouge. Les coupables habituels : une image avec une URL absolue en dur dans un article, un script tiers d'un vieux widget. Soit vous corrigez la source, soit vous ajoutez l'en-tête de politique de sécurité upgrade-insecure-requests, qui force le navigateur à convertir ces requêtes en HTTPS.
Faut-il activer HSTS tout de suite ?
L'en-tête Strict-Transport-Security indique au navigateur de n'accéder au site qu'en HTTPS pendant une durée donnée. Très efficace, mais à manier avec précaution : si vous l'activez avec une durée longue et que votre certificat casse, les visiteurs déjà revenus ne peuvent plus accéder au site même en HTTP. Le préchargement (preload), qui inscrit le domaine dans une liste navigateur, est encore plus engagé. Ma règle personnelle : d'abord stabiliser le HTTPS, vérifier pendant quelques semaines, puis activer HSTS avec une durée courte avant d'allonger. C'est plus prudent, et je l'assume.
Comment vérifier que le HTTPS est bien opérationnel
Une fois tout en place, vous pouvez être tenté de passer à autre chose. Faites plutôt un passage systématique, en trois contrôles :
- Ouvrez
http://votresite.frdans un onglet privé : vous devez être redirigé vershttps://sans avertissement. - Vérifiez le cadenas sur plusieurs pages, y compris la page contact et les pages de formulaire.
- Lancez un test de renouvellement :
sudo certbot renew --dry-run. Si cette commande échoue, votre certificat expirera dans trois mois.
J'ajoute un quatrième contrôle que j'ai appris à la dure : parcourez les journaux du serveur après la bascule. Une ressource interne appelée en HTTP dans votre propre code (un appel API au backoffice, par exemple) ne générera pas toujours un avertissement visible pour le visiteur, mais elle renverra une erreur dans les logs. C'est en lisant ces logs que j'ai repéré mes appels mal configurés.
Au bout du compte, HTTPS n'est qu'une formalité technique, mais c'est celle qui décide si votre visiteur vous fait confiance ou repart aussitôt. Une fois votre certificat en place, une question plus intéressante se pose : combien d'autres petites frictions invisibles font perdre des visiteurs sur votre site avant même qu'ils ne lisent une ligne ?
