Certificat SSL et HTTPS : le guide complet pour securiser votre site

En 2026, un site web sans HTTPS est un site qui perd des visiteurs, des positions Google et de la credibilite. Les navigateurs affichent un avertissement "Non securise" sur chaque page servie en HTTP. Les utilisateurs ferment ces pages avant meme de lire le premier paragraphe. Google penalise les sites non chiffres dans ses resultats de recherche depuis 2014. Et le probleme ne se limite pas au referencement : un formulaire de contact envoye sans chiffrement expose les donnees de vos clients a quiconque intercepte le trafic reseau.

Pourtant, beaucoup de proprietaires de sites WordPress repoussent la migration vers HTTPS par crainte de casser leur site. D'autres pensent que leur certificat SSL est en place alors que leur configuration presente des failles de contenu mixte qui annulent la protection. Ce guide couvre tout ce qu'il faut savoir sur le certificat SSL et le protocole HTTPS : comment ils fonctionnent, lequel choisir, comment l'installer correctement sur WordPress, et comment verifier que la configuration est solide. Pour une vision plus large de la securite WordPress, consultez notre guide complet de la securite WordPress.

Que signifie HTTPS et quel est son role

La difference entre HTTP et HTTPS

HTTP (HyperText Transfer Protocol) est le protocole qui permet a votre navigateur de communiquer avec un serveur web. Le probleme : les donnees circulent en clair. Quiconque se trouve sur le meme reseau Wi-Fi peut lire le contenu des echanges. Les mots de passe, les numeros de carte bancaire, les donnees de formulaire -- tout transite sans protection.

HTTPS ajoute une couche de chiffrement a ce protocole. Le "S" signifie "Secure". Concretement, HTTPS utilise le protocole TLS (Transport Layer Security) pour chiffrer les donnees entre le navigateur et le serveur. Un attaquant qui intercepte le trafic ne voit que des donnees illisibles. Le protocole HTTPS utilise le port 443, tandis que HTTP utilise le port 80.

Le chiffrement : comment HTTPS protege les donnees

Le chiffrement HTTPS repose sur un systeme de cles asymetriques. Le serveur possede une cle privee (secrete) et une cle publique (partagee avec tous les navigateurs via le certificat SSL). Quand un visiteur accede a votre site, le processus suivant se deroule :

1. Le navigateur demande au serveur de s'identifier
2. Le serveur envoie son certificat SSL contenant sa cle publique
3. Le navigateur verifie que le certificat est valide et emis par une autorite de certification reconnue
4. Le navigateur et le serveur negocient une cle de session temporaire (chiffrement symetrique)
5. Toutes les donnees echangees sont chiffrees avec cette cle de session

Ce processus s'appelle le "handshake TLS". Il se deroule en quelques millisecondes et est totalement invisible pour l'utilisateur. Le resultat : une connexion securisee, authentifiee et integre.

L'integrite des donnees et l'authentification

HTTPS ne se limite pas au chiffrement. Il garantit deux proprietes supplementaires. L'integrite des donnees signifie que les informations ne peuvent pas etre modifiees pendant le transfert sans que la modification soit detectee. Un fournisseur d'acces Internet ne peut pas injecter de publicites dans vos pages. Un attaquant ne peut pas modifier le contenu d'une page bancaire pour rediriger un virement.

L'authentification confirme que le visiteur communique bien avec le serveur qu'il croit contacter. Le certificat SSL sert de piece d'identite numerique. Sans cette authentification, un attaquant pourrait creer un faux site bancaire identique a l'original et intercepter les identifiants des victimes (attaque de type man-in-the-middle).

SSL, TLS et certificats : les bases techniques

SSL vs TLS : quelle difference en 2026

Les termes SSL et TLS sont souvent utilises de maniere interchangeable, mais ils designent des protocoles differents. SSL (Secure Sockets Layer) a ete developpe par Netscape dans les annees 1990. Les versions SSL 2.0 et SSL 3.0 presentaient des vulnerabilites serieuses (POODLE, DROWN) et sont aujourd'hui obsoletes. Plus aucun navigateur ne les prend en charge.

TLS (Transport Layer Security) est le successeur direct de SSL. TLS 1.0 et 1.1 sont egalement deprecies depuis 2021. En 2026, la norme est TLS 1.2 au minimum, et TLS 1.3 pour les configurations modernes. TLS 1.3, publie en 2018, reduit le nombre d'aller-retours du handshake de deux a un, ameliorant la latence de 20 a 30 % par rapport a TLS 1.2.

L'industrie continue d'utiliser le terme "certificat SSL" par habitude, meme si le protocole reel est TLS. Quand votre hebergeur parle de "SSL", il parle en realite de TLS 1.2 ou 1.3.

Les types de certificats SSL : DV, OV et EV

Tous les certificats SSL ne se valent pas. Ils se distinguent par le niveau de verification effectue par l'autorite de certification (AC) avant leur emission.

Domain Validation (DV) : Le certificat le plus simple et le plus rapide a obtenir. L'autorite de certification verifie uniquement que vous controlez le nom de domaine (via un enregistrement DNS ou un fichier sur le serveur). Emission en quelques minutes. C'est le type delivre par Let's Encrypt. Adapte aux blogs, sites vitrines et petits sites e-commerce.

Organization Validation (OV) : L'autorite de certification verifie l'existence legale de l'organisation. Elle controle les informations d'enregistrement de l'entreprise, l'adresse physique et le numero de telephone. Emission en 1 a 3 jours. Le certificat affiche le nom de l'organisation dans ses details. Recommande pour les sites d'entreprise qui traitent des donnees sensibles.

Extended Validation (EV) : Le niveau de verification le plus strict. L'autorite de certification effectue un audit approfondi : existence legale, adresse physique, verification telephonique, validation du demandeur autorise. Emission en 1 a 2 semaines. Les navigateurs modernes n'affichent plus la barre verte distinctive d'autrefois, mais le nom de l'entreprise reste visible dans les details du certificat. Utilise principalement par les banques, les institutions financieres et les grands sites e-commerce.

Certificats multi-domaines et Wildcard

Au-dela du niveau de validation, les certificats se distinguent par leur couverture. Un certificat standard couvre un seul domaine (exemple.com). Un certificat Wildcard couvre un domaine et tous ses sous-domaines (*.exemple.com). Un certificat multi-domaines (SAN) couvre plusieurs domaines distincts sous un seul certificat.

Pour un site WordPress standard, un certificat DV couvrant le domaine principal suffit. Si vous gerez plusieurs sous-domaines (blog.exemple.com, shop.exemple.com, app.exemple.com), un certificat Wildcard evite de gerer des certificats separement.

Obtenir un certificat SSL gratuit avec Let's Encrypt

Pourquoi Let's Encrypt a change la donne

Avant 2016, un certificat SSL coutait entre 50 et 300 euros par an. Ce cout representait une barriere pour les petits sites et les blogueurs. Let's Encrypt, lance en 2016 par l'ISRG (Internet Security Research Group) avec le soutien de Mozilla, Google, Cisco et l'EFF, a democratise le HTTPS en proposant des certificats DV gratuits, automatises et ouverts.

En 2026, Let's Encrypt protege plus de 400 millions de sites web. L'autorite de certification emet des certificats valides pendant 90 jours, avec renouvellement automatique. Cette duree courte est deliberee : en cas de compromission d'une cle privee, l'exposition est limitee dans le temps.

Les hebergeurs qui integrent Let's Encrypt

La plupart des hebergeurs WordPress francais et internationaux integrent Let's Encrypt dans leur panneau d'administration. L'activation prend moins de 5 minutes.

OVH : Activation via l'Espace Client dans la section Hebergement > SSL. OVH propose un certificat DV Let's Encrypt gratuit inclus avec chaque offre d'hebergement mutualise. Le renouvellement est automatique.

o2switch : Activation dans le cPanel, section Securite > Let's Encrypt SSL. Le certificat est automatiquement renouvele. o2switch inclut egalement un certificat Sectigo DV gratuit.

PlanetHoster : Activation dans le World Panel, section Certificat SSL. PlanetHoster propose Let's Encrypt et des certificats Sectigo payants pour les validations OV et EV.

Infomaniak : Activation dans le Manager, section Hebergement Web > SSL. Infomaniak inclut un certificat Let's Encrypt gratuit et propose des certificats payants Sectigo pour les entreprises.

Quand choisir un certificat SSL payant

Un certificat gratuit Let's Encrypt suffit pour la majorite des sites. Un certificat payant se justifie dans des cas precis.

Les sites e-commerce a fort volume qui traitent des milliers de transactions par jour beneficient d'un certificat OV ou EV qui affiche le nom de l'entreprise, renforçant la confiance des acheteurs. Les certificats payants incluent generalement une garantie financiere (de 10 000 a 1 750 000 euros selon le fournisseur) qui couvre les pertes en cas de defaillance du certificat.

Les institutions financieres et sites traitant des donnees medicales sont parfois soumis a des exigences reglementaires qui imposent un certificat OV ou EV. La norme PCI-DSS pour le traitement des cartes bancaires n'exige pas un type specifique de certificat, mais recommande des configurations TLS rigoureuses.

Les grandes entreprises multi-domaines qui gerent des dizaines de sous-domaines trouvent parfois plus pratique d'utiliser un certificat Wildcard payant avec support technique premium et duree de validite de 1 an.

Installer un certificat SSL sur WordPress : la methode complete

Prerequis avant la migration HTTPS

Avant de toucher a quoi que ce soit, preparez votre migration.

Sauvegardez votre site complet : base de donnees et fichiers. Utilisez un plugin comme UpdraftPlus ou le systeme de sauvegarde de votre hebergeur. Conservez cette sauvegarde hors du serveur (Google Drive, Dropbox, disque local).

Listez tous les elements qui contiennent des URLs en dur : pages, articles, widgets, fichiers de theme, plugins qui chargent des ressources externes, feuilles de style et scripts JavaScript. Cette liste vous servira lors de la correction du contenu mixte.

Verifiez la compatibilite de vos plugins : certains plugins anciens ou mal codes chargent des ressources en HTTP sans respecter le protocole du site. Mettez a jour tous vos plugins et themes avant la migration.

Activer le SSL chez votre hebergeur

La premiere etape est toujours l'activation du certificat cote serveur. Connectez-vous au panneau d'administration de votre hebergeur et activez le certificat SSL pour votre domaine.

Sur cPanel (utilise par la majorite des hebergeurs), la procedure est la suivante : allez dans Securite > Let's Encrypt SSL > Issue New Certificate. Selectionnez votre domaine et cliquez sur Issue. Le certificat est genere en quelques secondes.

Sur Plesk : allez dans Websites & Domains > SSL/TLS Certificates > Let's Encrypt. Cochez les options pour le domaine et le sous-domaine www, puis cliquez sur Install.

Attendez quelques minutes apres l'activation. Le certificat doit se propager sur le serveur. Verifiez en accedant a https://votredomaine.com dans votre navigateur. Si la page s'affiche avec le cadenas, le certificat est en place.

Configurer WordPress pour HTTPS

Une fois le certificat actif, configurez WordPress pour utiliser HTTPS par defaut. Dans votre tableau de bord WordPress, allez dans Reglages > General. Modifiez les deux champs d'URL en remplacant http:// par https://. Enregistrez. WordPress vous deconnectera. Reconnectez-vous via l'URL https://.

Pour forcer toutes les connexions en HTTPS, ajoutez cette ligne dans votre fichier wp-config.php :

define('FORCE_SSL_ADMIN', true);

Cette directive force l'utilisation de HTTPS pour le tableau d'administration, empechant les sessions d'administration d'etre interceptees.

Les redirections 301 : la piece maitresse

Les redirections 301 sont critiques. Sans elles, votre site est accessible en HTTP et en HTTPS simultanement. Google voit deux versions du meme contenu (contenu duplique), les backlinks existants pointent vers la version HTTP, et la "link equity" est diluee.

Ajoutez ces regles au debut de votre fichier .htaccess (avant les regles WordPress) :

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Si votre serveur utilise Nginx au lieu d'Apache, ajoutez dans votre bloc serveur :

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

Testez les redirections en accedant a http://votredomaine.com, http://www.votredomaine.com et http://votredomaine.com/une-page-quelconque. Chaque URL doit rediriger vers son equivalent HTTPS avec un code 301.

Corriger le contenu mixte (mixed content)

Le contenu mixte est le probleme le plus frequent apres une migration HTTPS. Il se produit quand une page HTTPS charge des ressources (images, scripts, feuilles de style) via HTTP. Le navigateur bloque ces ressources ou affiche un avertissement, ce qui casse la mise en page ou la fonctionnalite du site.

Comment detecter le contenu mixte : ouvrez votre site dans Chrome, appuyez sur F12 pour ouvrir les outils de developpement, et consultez l'onglet Console. Les erreurs de contenu mixte apparaissent avec le prefixe "Mixed Content:". L'onglet Security indique egalement si la page est totalement securisee ou non.

Correction automatique avec un plugin : le plugin Really Simple SSL detecte et corrige la majorite des problemes de contenu mixte automatiquement. Il redirige les requetes HTTP internes vers HTTPS et corrige les URLs dans la base de donnees. C'est la solution la plus rapide pour les debutants.

Correction manuelle avec Better Search Replace : pour une correction definitive sans plugin, utilisez Better Search Replace. Recherchez http://votredomaine.com et remplacez par https://votredomaine.com dans toutes les tables de la base de donnees. Effectuez d'abord un "dry run" (simulation) pour verifier le nombre de remplacements avant de les appliquer.

Ressources externes : certaines ressources chargees depuis des domaines tiers (polices Google Fonts, scripts d'analytics, widgets de reseaux sociaux) peuvent utiliser des URLs HTTP. Verifiez chaque ressource externe et mettez a jour les URLs vers leur version HTTPS. Si un service tiers ne supporte pas HTTPS, remplacez-le par une alternative securisee.

Pourquoi HTTPS est un facteur de classement SEO

Le signal de classement confirme par Google

Google a officiellement annonce en aout 2014 que le HTTPS est un signal de classement dans son algorithme. A l'epoque, Google parlait d'un "signal leger" (lightweight signal). Depuis, le poids de ce signal a augmente. En 2026, un site HTTP fait face a un double handicap : il perd le bonus HTTPS et Google le penalise indirectement via les signaux d'experience utilisateur (taux de rebond eleve cause par l'avertissement "Non securise").

Les donnees du Google Transparency Report montrent que plus de 95 % des pages chargees dans Chrome utilisent HTTPS. Le protocole HTTPS n'est plus un avantage concurrentiel -- c'est la norme. Ne pas l'avoir est un handicap. Pour une analyse complete des facteurs de classement, consultez notre guide du referencement Google.

HTTP/2, HTTP/3 et la performance

Le protocole HTTP/2, qui offre des gains de performance significatifs (multiplexage, compression des en-tetes, push serveur), requiert HTTPS dans la pratique. Tous les navigateurs modernes implementent HTTP/2 uniquement sur des connexions TLS. En restant en HTTP, vous vous privez de HTTP/2 et des ameliorations de vitesse de 5 a 15 % qu'il apporte.

HTTP/3, base sur le protocole QUIC, va encore plus loin avec un handshake 0-RTT qui reduit la latence au premier octet. HTTP/3 est egalement lie a HTTPS. Les sites qui exploitent ces protocoles modernes voient des ameliorations mesurables de leurs Core Web Vitals, en particulier le LCP (Largest Contentful Paint) et l'INP (Interaction to Next Paint).

La confiance des utilisateurs et le taux de conversion

Une etude de HubSpot rapporte que 82 % des utilisateurs quittent un site qui affiche l'avertissement "Non securise". Pour les sites e-commerce, l'impact est direct sur le taux de conversion. GlobalSign a montre que 84 % des acheteurs en ligne abandonnent leur achat si les donnees sont envoyees via une connexion non securisee.

Le cadenas affiche dans la barre d'adresse est devenu un signal de confiance universel. Les utilisateurs ne le remarquent plus quand il est present, mais ils remarquent immediatement son absence. Le HTTPS n'augmente pas forcement les conversions -- il empeche leur chute.

Verifier et auditer votre configuration SSL

Les outils de verification rapide

Apres l'installation, une verification methodique est necessaire. Plusieurs outils gratuits permettent de valider votre configuration.

SSL Checker (sslshopper.com) : entrez votre domaine et l'outil verifie la validite du certificat, la chaine de certification, la date d'expiration et la correspondance avec le nom de domaine. C'est le test de base a effectuer en premier.

Why No Padlock (whynopadlock.com) : cet outil scanne une page specifique et identifie chaque ressource chargee en HTTP qui empeche l'affichage du cadenas. Utile pour localiser les sources de contenu mixte.

SSL Labs (ssllabs.com) : l'audit le plus complet. Qualys SSL Labs analyse la configuration TLS de votre serveur en profondeur : version du protocole, suites de chiffrement supportees, vulnerabilites connues (Heartbleed, POODLE, BEAST), support du Forward Secrecy, configuration HSTS. Le resultat est une note de A+ (meilleur) a F (critique). Visez A ou A+.

Interpreter les resultats de SSL Labs

Un resultat A+ sur SSL Labs confirme une configuration solide. Voici les points cles a verifier dans le rapport.

Protocoles : TLS 1.2 et TLS 1.3 doivent etre actifs. SSL 2.0, SSL 3.0, TLS 1.0 et TLS 1.1 doivent etre desactives. Si votre serveur supporte encore TLS 1.0, il est expose a des attaques de downgrade.

Suites de chiffrement : privilegiez les suites utilisant AES-256-GCM ou CHACHA20-POLY1305 avec ECDHE pour le Forward Secrecy. Desactivez les suites utilisant RC4, 3DES ou des echanges de cles RSA sans Diffie-Hellman.

Forward Secrecy : cette propriete garantit que la compromission de la cle privee du serveur ne permet pas de dechiffrer les communications passees. Assurez-vous que toutes les suites de chiffrement supportent l'ECDHE (Elliptic Curve Diffie-Hellman Ephemeral).

HSTS (HTTP Strict Transport Security) : cette en-tete HTTP indique aux navigateurs de ne jamais acceder au site en HTTP, meme si l'utilisateur tape http:// dans la barre d'adresse. Activez HSTS avec une duree minimale de 6 mois (max-age=15768000). Pour la note A+, HSTS est obligatoire.

Surveillance continue et renouvellement

Un certificat Let's Encrypt expire tous les 90 jours. Le renouvellement est normalement automatique (via le daemon certbot ou l'interface de votre hebergeur), mais des problemes peuvent survenir : erreur de configuration DNS, serveur injoignable pendant la validation, quota de renouvellement depasse.

Mettez en place une surveillance proactive. Les outils suivants envoient une alerte avant l'expiration :

• Uptime Robot (gratuit) : surveille le certificat et envoie un email 14 jours avant expiration
• SSL Labs : effectuez un audit mensuel pour detecter les regressions de configuration
• Google Search Console : le rapport de securite signale les problemes de certificat

Les erreurs frequentes a eviter lors de la migration HTTPS

Ne pas rediriger toutes les URLs

L'erreur la plus courante : rediriger uniquement la page d'accueil vers HTTPS en oubliant les pages internes. Chaque URL de votre site doit avoir sa redirection 301 individuelle. Verifiez en testant des URLs profondes comme http://votredomaine.com/mon-article/ ou http://votredomaine.com/ma-categorie/.

Oublier de mettre a jour le sitemap et robots.txt

Apres la migration, votre sitemap XML doit contenir des URLs HTTPS. Si votre plugin SEO genere le sitemap automatiquement (Yoast, Rank Math), la mise a jour est immediate apres le changement d'URL dans les reglages WordPress. Verifiez manuellement en accedant a https://votredomaine.com/sitemap_index.xml.

Le fichier robots.txt doit egalement reference le sitemap en HTTPS. Verifiez que la directive Sitemap: pointe vers https://votredomaine.com/sitemap_index.xml.

Ignorer les liens internes en dur

Les liens internes codes en dur dans vos contenus, widgets ou fichiers de theme peuvent rester en HTTP apres la migration. Ces liens generent des redirections 301 en chaine qui ralentissent la navigation et diluent le PageRank. Utilisez Better Search Replace ou un script SQL pour corriger ces URLs dans la base de donnees. Verifiez les fichiers de theme manuellement pour les URLs codees en dur dans le code PHP ou les templates.

Ne pas tester sur mobile

Le comportement du site apres la migration peut differer entre desktop et mobile. Certains themes WordPress chargent des ressources differentes selon le viewport. Testez votre site sur un appareil mobile reel ou avec les outils de developpement Chrome en mode responsive pour vous assurer que le HTTPS fonctionne correctement partout.

HSTS : la protection supplementaire contre les attaques de downgrade

Qu'est-ce que HSTS et pourquoi l'activer

HSTS (HTTP Strict Transport Security) est un mecanisme qui force les navigateurs a utiliser exclusivement HTTPS pour communiquer avec votre site. Sans HSTS, un attaquant peut tenter une attaque de "stripping SSL" : il intercepte la premiere requete HTTP (avant la redirection 301) et presente une version HTTP du site a la victime.

Avec HSTS, le navigateur sait qu'il doit toujours utiliser HTTPS pour ce domaine. Meme si l'utilisateur tape http:// dans la barre d'adresse, le navigateur converti automatiquement en https:// avant d'envoyer la requete. Aucune requete HTTP n'est emise.

Comment activer HSTS sur votre serveur

Sur Apache, ajoutez cette directive dans votre fichier .htaccess ou la configuration du virtual host :

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

Sur Nginx, ajoutez dans le bloc serveur HTTPS :

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

Le parametre max-age definit la duree (en secondes) pendant laquelle le navigateur doit forcer HTTPS. 31536000 secondes correspondent a 1 an. includeSubDomains etend la politique a tous les sous-domaines. preload permet l'inscription dans la liste de preload HSTS des navigateurs.

L'inscription sur la liste HSTS Preload

La liste HSTS Preload est une liste de domaines integree directement dans le code source des navigateurs (Chrome, Firefox, Safari, Edge). Les domaines inscrits sur cette liste sont automatiquement charges en HTTPS, meme lors de la toute premiere visite. Cela elimine la fenetre de vulnerabilite qui existe avant que le navigateur ait recu l'en-tete HSTS pour la premiere fois.

Pour inscrire votre domaine, rendez-vous sur hstspreload.org, verifiez que votre configuration respecte les prerequis (certificat valide, redirection 301, en-tete HSTS avec preload, includeSubDomains et max-age minimum de 1 an), puis soumettez votre domaine. L'inscription prend plusieurs semaines a se propager dans tous les navigateurs.

Attention : l'inscription sur la liste HSTS Preload est difficile a annuler. Assurez-vous que tous vos sous-domaines supportent HTTPS avant de vous inscrire.

Cas particuliers : e-commerce, multisite et CDN

E-commerce et certificats SSL

Pour un site e-commerce WordPress (WooCommerce), le HTTPS est une obligation legale autant que technique. Le RGPD et la directive europeenne sur les services de paiement (DSP2) imposent la protection des donnees personnelles et financieres. Un certificat DV gratuit suffit techniquement, mais un certificat OV affiche le nom de votre entreprise dans les details du certificat, ce qui renforce la confiance des acheteurs.

WooCommerce inclut une option "Forcer HTTPS sur les pages de paiement" dans ses reglages. Activez-la, mais forcez HTTPS sur l'ensemble du site, pas uniquement les pages de paiement. Un site partiellement securise est pire qu'un site totalement securise : les transitions entre HTTP et HTTPS generent des avertissements et des erreurs de contenu mixte.

WordPress Multisite et certificats Wildcard

Si vous gerez un reseau WordPress Multisite avec des sous-domaines, un certificat Wildcard couvre l'ensemble du reseau. Le certificat Wildcard pour *.votredomaine.com securise automatiquement tous les sous-domaines : blog.votredomaine.com, boutique.votredomaine.com, membres.votredomaine.com.

Let's Encrypt propose des certificats Wildcard gratuits depuis 2018. La validation requiert une verification DNS (DNS-01 challenge) au lieu de la verification HTTP classique. Votre hebergeur doit supporter cette methode de validation.

CDN et SSL : la double couche de chiffrement

Si vous utilisez un CDN (Content Delivery Network) comme Cloudflare, Fastly ou StackPath, la configuration SSL implique deux connexions : visiteur vers CDN et CDN vers votre serveur d'origine.

Mode Full SSL (recommande) : le CDN chiffre la connexion entre le visiteur et le CDN, et entre le CDN et votre serveur. Votre serveur d'origine doit avoir un certificat SSL valide.

Mode Full (Strict) : identique au mode Full, mais le CDN verifie que le certificat de votre serveur d'origine est valide et emis par une autorite de certification reconnue. C'est le mode le plus securise.

Mode Flexible (a eviter) : le CDN chiffre uniquement la connexion entre le visiteur et le CDN. La connexion entre le CDN et votre serveur reste en HTTP. Ce mode donne une fausse impression de securite et peut causer des boucles de redirection.

Depannage : les erreurs SSL les plus courantes

ERR_CERT_DATE_INVALID : certificat expire

Le certificat a depasse sa date de validite. Verifiez dans le panneau de votre hebergeur que le renouvellement automatique est actif. Si le renouvellement a echoue, regenerez manuellement le certificat. Les causes frequentes d'echec : changement de serveur DNS, site inaccessible pendant la validation, limite de taux de Let's Encrypt atteinte.

ERR_CERT_COMMON_NAME_INVALID : domaine incorrect

Le nom de domaine dans le certificat ne correspond pas au domaine visite. Cette erreur survient quand le certificat couvre exemple.com mais pas www.exemple.com (ou inversement). Regenerez le certificat en incluant les deux variantes du domaine. Sur Let's Encrypt, ajoutez les deux domaines dans la demande de certificat.

ERR_SSL_PROTOCOL_ERROR : configuration TLS defaillante

Le serveur et le navigateur ne parviennent pas a negocier un protocole TLS commun. Verifiez que votre serveur supporte TLS 1.2 ou 1.3. Si vous avez recemment modifie la configuration TLS, verifiez qu'au moins une suite de chiffrement commune est disponible. Utilisez SSL Labs pour diagnostiquer le probleme.

NET_ERR_CERT_AUTHORITY_INVALID : autorite non reconnue

Le certificat est emis par une autorite de certification que le navigateur ne reconnait pas. Ce probleme survient avec les certificats auto-signes (utilises en developpement) ou quand la chaine de certification est incomplete. Verifiez que le certificat intermediaire est correctement installe sur votre serveur.