Certificats SSL : comprendre les erreurs courantes et les corriger

Le cade­nas affi­ché dans la barre d’adresse est deve­nu un stan­dard sur le web. Son absence ou l’apparition d’un aver­tis­se­ment de sécu­ri­té peut faire fuir les visi­teurs… et inquié­ter les moteurs de recherche.

Lorsqu’une erreur HTTPS appa­raît, le réflexe consiste sou­vent à régé­né­rer le cer­ti­fi­cat SSL. Pour­tant, dans de nom­breux cas, le pro­blème ne vient pas du cer­ti­fi­cat lui-même, mais d’une confi­gu­ra­tion incor­recte du site ou des redirections.

Dans cet article, nous allons voir com­ment fonc­tionnent les cer­ti­fi­cats SSL et sur­tout com­ment diag­nos­ti­quer les erreurs les plus cou­rantes afin de les cor­ri­ger rapidement.

Les certificats SSL en bref

Un cer­ti­fi­cat SSL sécu­rise la connexion entre le navi­ga­teur d’un visi­teur et le ser­veur qui héberge un site web : il chiffre les échanges de don­nées et confirme que le site cor­res­pond bien au nom de domaine affi­ché dans la barre d’adresse.

La grande majo­ri­té des sites uti­lisent aujourd’­hui des cer­ti­fi­cats Let’s Encrypt, une auto­ri­té de cer­ti­fi­ca­tion gra­tuite qui émet des cer­ti­fi­cats de type DV (Domain Vali­da­tion). La véri­fi­ca­tion se fait auto­ma­ti­que­ment, sans vali­da­tion humaine, et confirme uni­que­ment que vous contrô­lez le domaine concer­né. Elle ne véri­fie pas l’i­den­ti­té de l’en­tre­prise der­rière le site, contrai­re­ment aux cer­ti­fi­cats OV ou EV. 

Pour la qua­si-tota­li­té des usages (blogs, sites vitrines, e‑commerce), ce niveau est par­fai­te­ment suf­fi­sant : le chif­fre­ment est iden­tique, seule la véri­fi­ca­tion d’i­den­ti­té diffère.

Avant de corriger : identifier l’erreur

Avant de modi­fier la confi­gu­ra­tion d’un site ou de régé­né­rer un cer­ti­fi­cat, la pre­mière étape consiste sim­ple­ment à obser­ver le mes­sage affi­ché par le navi­ga­teur. Les erreurs HTTPS sont géné­ra­le­ment assez expli­cites et indiquent sou­vent la nature du problème.

Com­men­cez par regar­der la barre d’adresse : le cade­nas peut être accom­pa­gné d’un aver­tis­se­ment ou d’un mes­sage indi­quant que la connexion n’est pas entiè­re­ment sécu­ri­sée. Cer­tains navi­ga­teurs affichent éga­le­ment une men­tion indi­quant que la connexion a été sur­clas­sée auto­ma­ti­que­ment en HTTPS, ce n’est pas une erreur.

Si l’erreur n’est pas évi­dente, vous pou­vez éga­le­ment ouvrir les outils de déve­lop­pe­ment du navi­ga­teur (touche F12 dans la plu­part des cas). L’onglet Console per­met sou­vent de repé­rer rapi­de­ment un pro­blème de res­source char­gée en HTTP, typique des erreurs de mixed content.

Les erreurs SSL les plus courantes

Mixed content

Une erreur de mixed content appa­raît lors­qu’une page est char­gée en HTTPS, mais que cer­taines res­sources qu’elle uti­lise (images, scripts, feuilles de style ou polices web…) sont réfé­ren­cées en HTTP.

Les navi­ga­teurs modernes ne laissent plus pas­ser ces res­sources silen­cieu­se­ment. Selon le type de res­source, elles sont soit sur­clas­sées auto­ma­ti­que­ment en HTTPS, soit blo­quées : c’est notam­ment le cas des polices web réfé­ren­cées en HTTP. Dans les deux cas, le pro­blème n’est plus for­cé­ment visible dans la barre d’a­dresse. C’est la console des outils de déve­lop­pe­ment (touche F12) qui per­met de détec­ter les res­sources concernées.

Ce pro­blème sur­vient le plus sou­vent après une migra­tion d’un site HTTP vers HTTPS. Cer­taines URLs res­tent enre­gis­trées en HTTP dans la base de don­nées du site, dans les conte­nus, les médias ou par­fois dans les fichiers du thème ou d’une extension.

La cor­rec­tion consiste géné­ra­le­ment à rem­pla­cer les anciennes URLs HTTP par leurs équi­va­lents HTTPS. Sur un site Word­Press, cela peut se faire avec un outil de recherche et rem­pla­ce­ment dans la base de don­nées, par exemple avec l’extension Bet­ter Search Replace.

Il est éga­le­ment utile de véri­fier que les images, scripts et feuilles de style char­gés par le thème ou cer­taines exten­sions uti­lisent bien des URLs en HTTPS.

ERR_CERT_COMMON_NAME_INVALID

L’erreur ERR_CERT_COMMON_NAME_INVALID appa­raît lorsque le cer­ti­fi­cat SSL pré­sen­té par le ser­veur ne cor­res­pond pas au nom de domaine uti­li­sé dans le navi­ga­teur.
Autre­ment dit, le navi­ga­teur reçoit un cer­ti­fi­cat valide… mais pour un autre domaine. Dans ce cas, il ne peut pas confir­mer l’identité du site et affiche un aver­tis­se­ment de sécu­ri­té. Plu­sieurs situa­tions peuvent pro­vo­quer cette erreur.

Différence entre www et non-www

C’est l’un des cas les plus fré­quents. Un cer­ti­fi­cat peut être valide pour domaine.fr, mais pas pour www.domaine.fr, ou l’inverse.
Si le visi­teur accède à une ver­sion du domaine qui n’est pas incluse dans le cer­ti­fi­cat, le navi­ga­teur consi­dère que celui-ci ne cor­res­pond pas au site visité.

Sous-domaine non couvert par le certificat

Un cer­ti­fi­cat peut cou­vrir un domaine prin­ci­pal sans inclure tous ses sous-domaines.
Par exemple, un cer­ti­fi­cat valide pour domaine.fr ne couvre pas auto­ma­ti­que­ment blog.domaine.fr ou shop.domaine.fr. Si un visi­teur accède à un sous-domaine non pré­sent dans le cer­ti­fi­cat, l’erreur peut apparaître.

Migration de site ou propagation DNS

Lors d’un chan­ge­ment de ser­veur ou d’une migra­tion de site, le domaine peut poin­ter vers deux ser­veurs dif­fé­rents pen­dant un cer­tain temps.
Cer­tains visi­teurs arrivent alors sur l’ancien ser­veur, tan­dis que d’autres atteignent déjà le nou­veau. Si ces deux ser­veurs pré­sentent des cer­ti­fi­cats dif­fé­rents, le navi­ga­teur peut rece­voir un cer­ti­fi­cat qui ne cor­res­pond pas au domaine atten­du.
Ce type d’erreur dis­pa­raît géné­ra­le­ment une fois la pro­pa­ga­tion DNS terminée.

Domaine pointant vers le mauvais serveur

Dans cer­tains cas, la confi­gu­ra­tion DNS du domaine dirige les visi­teurs vers un ser­veur qui héberge un autre site. Le ser­veur pré­sente alors son propre cer­ti­fi­cat, qui ne cor­res­pond pas au domaine deman­dé, ce qui pro­voque l’erreur.

Dans tous ces cas, la cor­rec­tion passe par la même démarche : véri­fier les domaines cou­verts par le cer­ti­fi­cat (visibles dans les infor­ma­tions du navi­ga­teur), puis s’as­su­rer que le domaine ou sous-domaine concer­né y figure bien. Si ce n’est pas le cas, il fau­dra géné­rer un nou­veau cer­ti­fi­cat en incluant les variantes man­quantes. Si le cer­ti­fi­cat est cor­rect mais que l’er­reur per­siste, le pro­blème vient pro­ba­ble­ment de la confi­gu­ra­tion DNS : véri­fiez que le domaine pointe bien vers le bon serveur.

Boucle de redirection HTTPS

Une boucle de redi­rec­tion HTTPS se pro­duit lorsque le navi­ga­teur est redi­ri­gé en per­ma­nence entre deux URLs sans jamais par­ve­nir à char­ger la page. Le navi­ga­teur affiche alors un mes­sage indi­quant que la page redi­rige trop de fois (ERR_TOO_MANY_REDIRECTS) ou que la connexion n’est pas éta­blie cor­rec­te­ment.
Ce type de pro­blème appa­raît géné­ra­le­ment lorsqu’il existe plu­sieurs règles de redi­rec­tion contra­dic­toires dans la confi­gu­ra­tion du site ou du ser­veur. Plu­sieurs situa­tions peuvent pro­vo­quer ce comportement.

Redirections HTTPS en double

Il arrive qu’une redi­rec­tion vers HTTPS soit confi­gu­rée à plu­sieurs endroits en même temps : dans le fichier .htaccess, dans une exten­sion Word­Press ou direc­te­ment dans les réglages du ser­veur.
Ces règles peuvent entrer en conflit et pro­vo­quer une redi­rec­tion en boucle entre HTTP et HTTPS.

Mauvaise configuration dans WordPress

Word­Press pos­sède deux réglages impor­tants dans Réglages → Géné­ral :

• Adresse web de WordPress
• Adresse web du site

Si ces deux URLs ne sont pas confi­gu­rées cor­rec­te­ment (par exemple l’une en HTTP et l’autre en HTTPS), des redi­rec­tions inat­ten­dues peuvent apparaître.

Configuration incorrecte avec un proxy ou un CDN

Lors­qu’un site passe par un CDN ou un proxy, la connexion HTTPS est sou­vent ter­mi­née au niveau du ser­vice inter­mé­diaire avant d’être trans­mise au ser­veur. Si ce der­nier ne détecte pas cor­rec­te­ment que la connexion d’o­ri­gine est déjà en HTTPS, il peut ten­ter de redi­ri­ger à nou­veau, ce qui crée une boucle.

Avec Cloud­flare, ce pro­blème sur­vient fré­quem­ment lorsque le mode SSL est réglé sur Flexible : Cloud­flare se connecte alors au ser­veur en HTTP, tan­dis que le ser­veur tente de redi­ri­ger vers HTTPS. Pas­ser le mode SSL sur Full ou Full (strict) dans le tableau de bord Cloud­flare suf­fit géné­ra­le­ment à résoudre le problème.

Cache ou redirections persistantes

Cer­taines redi­rec­tions peuvent res­ter mémo­ri­sées dans le cache du navi­ga­teur ou du ser­veur. Après une modi­fi­ca­tion de confi­gu­ra­tion, le navi­ga­teur peut conti­nuer à appli­quer une ancienne redi­rec­tion.
Dans ce cas, vider le cache du navi­ga­teur ou du site peut suf­fire à résoudre le pro­blème.
La réso­lu­tion consiste géné­ra­le­ment à iden­ti­fier où se trouvent les règles de redi­rec­tion et à s’assurer qu’elles ne sont défi­nies qu’à un seul endroit.

Ce qu’il ne faut pas faire

Lorsqu’une erreur SSL appa­raît, la réac­tion la plus fré­quente consiste à modi­fier plu­sieurs réglages en même temps dans l’espoir que le pro­blème dis­pa­raisse. Cette approche com­plique sou­vent le diag­nos­tic et peut même aggra­ver la situa­tion.
Cer­taines erreurs reviennent par­ti­cu­liè­re­ment souvent.

Régénérer le certificat en boucle

Si une erreur HTTPS appa­raît, cela ne signi­fie pas for­cé­ment que le cer­ti­fi­cat est défec­tueux. Dans la plu­part des cas, le pro­blème vient plu­tôt d’une confi­gu­ra­tion incor­recte du domaine, des redi­rec­tions ou du DNS.
Régé­né­rer le cer­ti­fi­cat plu­sieurs fois ne résou­dra donc rien si la cause réelle du pro­blème n’est pas iden­ti­fiée.
Avec les cer­ti­fi­cats Let’s Encrypt, cette pra­tique peut même blo­quer tem­po­rai­re­ment la créa­tion de nou­veaux cer­ti­fi­cats. Le ser­vice applique en effet des limites de géné­ra­tion pour évi­ter les abus. Si plu­sieurs ten­ta­tives sont effec­tuées en peu de temps, l’émission de nou­veaux cer­ti­fi­cats peut être refu­sée pen­dant un cer­tain délai.
Dans ce cas, il faut géné­ra­le­ment attendre plu­sieurs heures avant de pou­voir géné­rer un nou­veau certificat. 

➔ La docu­men­ta­tion offi­cielle détaille ces limites : https://​let​sen​crypt​.org/​f​r​/​d​o​c​s​/​r​a​t​e​-​l​i​m​i​ts/

Désactiver HTTPS “temporairement”

Sup­pri­mer le cer­ti­fi­cat ou reve­nir à une ver­sion HTTP du site peut sem­bler être une solu­tion rapide, mais cela peut pro­vo­quer d’autres pro­blèmes : aver­tis­se­ments de sécu­ri­té dans les navi­ga­teurs, perte de confiance des visi­teurs et impact néga­tif sur le référencement.

➔ Une fois HTTPS acti­vé sur un site, il est pré­fé­rable de cor­ri­ger la confi­gu­ra­tion plu­tôt que de reve­nir en arrière.

Ignorer les avertissements de sécurité

Il arrive qu’un site conti­nue de s’afficher mal­gré un cade­nas bar­ré ou un mes­sage indi­quant que la connexion n’est pas entiè­re­ment sécu­ri­sée.
Même si la page semble fonc­tion­ner, ces aver­tis­se­ments indiquent géné­ra­le­ment un pro­blème réel, comme un mixed content ou un cer­ti­fi­cat mal configuré. 

➔ Ces aver­tis­se­ments ont un impact réel sur la confiance des visi­teurs et sur le réfé­ren­ce­ment. Mieux vaut une heure de diag­nos­tic qu’une erreur SSL lais­sée en place.

À retenir

• Les erreurs HTTPS ne viennent pas tou­jours du cer­ti­fi­cat SSL lui-même. Elles sont sou­vent liées à la confi­gu­ra­tion du site, aux redi­rec­tions, au DNS ou à des res­sources encore char­gées en HTTP.
• Avant d’agir, la pre­mière étape consiste tou­jours à iden­ti­fier pré­ci­sé­ment le mes­sage d’erreur affi­ché par le navi­ga­teur. Chaque erreur cor­res­pond géné­ra­le­ment à une cause spécifique.
• Une fois HTTPS acti­vé, cor­ri­ger la confi­gu­ra­tion est tou­jours pré­fé­rable à une désac­ti­va­tion, même tem­po­raire.