Bonjour tout le monde,
Avant tout, je tiens à rapidement m'expliquer pourquoi est-ce que je place ce sujet dans 'Hébergement Web' plutôt que 'SSL Gateway', l'élément déclencheur est bel et bien un certificat SSL mais ne survient que sur les hébergements mutualisés.
Il faut savoir que la plupart des requêtes en interne (de son site à... toujours son propre site) sont bloquées en voici la raison:
> Hello,
> Les clusters du Mutu sont constitués de centaines de machines derrière
> un (gros) load balancer (quelques Gbit/s).
> Lorsque vous commandez un certificat SSL pour un hébergement, il est
> installé sur le load balancer. Jamais sur les "webs" (les machines qui
> hébergent vos sites), essentiellement pour des raisons de sécurité et de
> performance.
> Pour des raisons de performance, chacune des adresses IP du cluster sont
> montée en locale sur chaque machine du cluster. C'est optimisation
> astucieuse qui permet de traiter encore plus vites les requêtes d'un
> site vers lui même, sans repasser par toute la chaine de load balancer /
> routeur / CDN / ... Bref, ça va plus vite.
> Sauf que.. les certificats SSL ne sont pas installés en local. En fait,
> c'est même encore plus subtile que ça: le port 443 de Apache est
> configuré en HTTP, pas en HTTPS quand vous êtes en local. Et en local
> uniquement.
> C'est encore une astuce de performance. Le HTTPS demande du chiffrement,
> qui est couteux. De moins en moins cher sur le matériel actuel, mais
> tout de même. Et il n'apporte rien en local car l'ensemble de la chine
> de confiance est sur la même machine et donc parfaitement contrôlée.
> Bref, si vos requêtes du site vers lui même vont vite, c'est grâce à
> toutes ces optimisations. Dans ce cas, vous pouvez simplement utiliser
> sur http://
> Si vous avez absolument besoin de passer par le port 443 (car Wordpress
> le redirige par exemple), vous pouvez aussi utiliser l'adresse
> http://toto.com:443 qui force curl à utiliser le port 443 mais sans en
> attendre de chiffrement.
> Bonne journée,
J'ai mis ce paragraphe entier sous quote car cela ne provient pas de moi mais j'ai relevé cette erreur sur mes WordPress et j'ai peur que quelques erreurs de mes PrestaShop viennent de là, elles aussi. Sur WordPress, j'ai quelques erreurs de connexions avec le plugin JetPack (ça dépends du moment), je n'arrive pas du tout à obtenir / envoyer des pings et quelques fonctionnalités du célèbre module SecuPress sont H.S., ayant contacté le support de SecuPress, voici leur réponse:
> Hello Lenny, effectivement ce'st bien le soucis SSL+OVH qui est présent.
> Pour le scan malware, j'ai réalisé la même requête en mode bloquant pour la reproduire et l'erreur est "cURL error 35: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol"
> Il n'existe pas de solution de notre côté, tout plugin faisant une requete ajax sur le site (donc depuis le site vers le site, cible et source identique) aura le problème.
> Donc les crons aussi théoriquement.
> J'imagine que OVH ne peut pas laisser ça comme ça, TOUS les WP SSL chez eux sont touchés, SecuPress ou pas.
> Que faire à part attendre OVH ou changer d'hébergeur …
D'après le support de JetPack, c'est aussi à cause des SSL OVH.
À quand un SSL pleinement compatible?
Lecture supplémentaires:
https://wordpress.org/support/topic/curl-error-35-error140770fcssl-routinesssl23_get_server_hellounknown-protoc/
https://bugs.reinom.com/view.php?id=1783
OVH devrait rapidement trouver un nouveau moyen de gérer les certificats SSL
Sujets apparentés
- Impossible de mettre en place certificat ssl
43141 
05.12.2016 14:02
- SSL actif mais site web non sécurisé
30406 20.05.2018 14:33
- Ssl0.ovh.net : impossible de vérifier l'identité serveur
26510 17.05.2019 13:38
- Problème SSL/multisite "Une erreur est survenue lors de la modification du ou des domai
23188 17.02.2020 09:04
- Certificat SSL et VPS
19378 01.02.2017 11:56
- Smtp ssl0.ovh.net = Problème d'envoi avec Orange Pro
9691 28.03.2019 07:52
- Redirection 301 et SSL
9377 10.09.2017 09:16
- Impossible de regénérer certificat SSL
9118 20.09.2017 18:55
- Certificat SSL en cours de création trop longue !
9005 04.04.2018 19:18
Bonjour,
De mon côté j'ai le même problème : tous les CRON de mon site sont bloqués, des plugins tels que UpdraftPlus et Secupress ne peuvent plus fonctionner correctement, et c'est vraiment très gênant. Cela fait un moment que ça dure, j'espère que le problème pourra rapidement être solutionné !
Jessica
Réponse de @vcasse à ce sujet, il y a plusieurs mois, sur l'ancien forum :
[quote]Bonjour chmod777,
Tout d'abord, désolé pour le délai. On a regardé pas mal de choses autour de SSL et pas pris le temps de checker ce sujet. Merci aussi pour le fichier, on a pu tester et identifier rapidement le soucis.
L'erreur SSL provient du fait que lorsque vous tentez d'appeler votre propre site sur le serveur web, il n'y a pas de certificat SSL. En fait, lorsque vous faîtes une requête vers votre propre site, la requête ne repasse pas pas nos load balancers mais passe seulement par les sockets interne du serveur web.
Sauf que nous n'avons pas déployé les certificats SSLs sur les serveurs web : on aurait simplement pas la place de les stocker en local (oui, on a beaucoup de certificats !)
La bonne nouvelle c'est qu'en terme de sécurité, appeler son propre site en HTTPS ou en HTTP, ca ne change rien quand ca reste sur la même machine : si quelqu'un peut intercepter le traffic, c'est qu'il a déjà bien trop de droits sur la machine.
Ca peut cependant poser soucis pour les personnes qui redirigent automatiquement le port 80 vers 443 (enfin ceux qui font http vers https). Une possibilité est d'utiliser directement le port 443 en http. Par exemple, utliser : $testpage = 'http://'.$_SERVER['SERVER_NAME'].':443/image.jpeg';
Cordialement,
Vincent[/quote]
--------------------
Sinon, "TOUS les WP SSL chez eux sont touchés, SecuPress ou pas."
Ah bon... Et à quel niveau on peut remarquer ça ?
Bonjour à tous,
Nous sommes en train de tester une solution afin que les appels en local fonctionnent en HTTPS. Il repasseront dans ce cas par le load balancer.
Nous validons actuellement que tout fonctionne correctement. Lorsque nous serons assurés de cela, nous le déploieront sur l'infrastructure. Dans tous les cas, nous vous tiendrons au courant dans la roadmap.
Cordialement,
Vincent
Cela vient du support officiel de SecuPress, un plugin qui est quand même massivement utilisé par la communauté WordPress !
C'est à cause des grosses usines à gaz comme Wordpress que les hébergements sont ralentis pour les vrais devs! :-p
Apprenez à le sécuriser vous-même déjà.
Le-même genre de développeurs qui utilisent des BootStrap et Cie à tout va et qui utilisent au final, un nombre de ressources similaire à WordPress :stuck_out_tongue: ?
... voire certainement plus. Mais bon c'est tout dans un gros plat de spaghetti, ça fait moins gros de l'extérieur.
Rien ne vaut Joomla pour obtenir des performances optimales.
Arrêtez de vous bagarrer : HTML, CSS, JS et un soupçon de PHP là où c'est vraiment utile. :nut_and_bolt::grinning:
Bizarre quand même: j'ai - plutôt : je gère - quelques sites sur des "Mutus Perso" - je pense bien connaitre ces Mutus depuis le temps, je connais bien ce projet " https://letsencrypt.org/ ", les relations commerciales qui existe entre OVH et Letsencrypt, la décision d'OVH de signer un pacte avec letsencrypt.org pour offrir à toutes les clients Mutu une simple méthode pour avoir son "certificat", autrement dit, son accès : https://.
Le simple fait que ça marche, ce n’est presque pas croyable.
Ça marche vraiment :=> https://www.choeurlemance.fr/ Ce site est un WP 'nature' sans polu-ware (autrement dit : plugins).
**WP fonctionne très bien avec le SSL depuis des années.**
Quand ça foire, c'est:
Soit c'est un plugin (des plugins !) qui a été écrit sans prendre en compte que peut être pas tout les liens 'internes' sont des http://votre-domaine.tld/...
Soit, tout connement, l’utilisateur à codé en dur un lien comme http://votre-domaine.tld/../uploads/blablabla.pdf (il a du mettre "../uploads/blablabla.pdf " comme URL locale).
.... et boumm ......
Pourtant, les requêtes CRON d'un tas de personnes ne fonctionnent pas. Ainsi que le fichier xmlrpc qui permet de recevoir ou envoyer des pings, ... Tout cela fait partie officiellement de WordPress.
La publication en différé d'un article ou page ne fonctionne pas en https.
J'ai testé en désactivant tous les plugins, cela n'a rien changé, je dois utiliser le cron d'OVH.
Même message d'erreur pour ma part :
Message d’erreur : cURL error 35: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol.
Il survient sur la "mise à jour réseau" d'un multisite Wordpress, hébergé chez OVH ... pas assez calé à mon niveau pour trouver une solution :sob:
J'ai fait des tonnes de test, avec SSL, sans SSL, avec WP à poil ! rien n'y fait ...
Exactement les mêmes soucis depuis la mise en place du SSL gratuit, c'et vraiment très handicapant pour Wordpress...
Vivement une solution car ce n'est pas viable.
J'ai également ces problèmes depuis la mise en place du SSL gratuit. Wordpress fonctionne mais les tâches cron ne se lancent pas... donc au final ce n'est pas viable.
Bonjour,
Nous avons trouvé une solution que nous allons mettre en place sur l'infrastructure d'ici la fin de l'année. Les scripts de mises à jour et les crons devraient alors fonctionner correctement.
Bonne journée,
Vincent
Bonjour,
En attendant, plus de ssl sur gravelines (cluster020).
Pouvez-vous internenir ?
J.
Nous n'avons aucun soucis de signaler sur la disponibilité des sites en HTTPS. Pouvez vous donner plus de détails ?
Vincent
Nous avons l'invite : La connexion n’est pas sécurisée.
Ticket numéro 9950195925
Merci de ne pas donner d'information sur ce forum.
C'est vraiment aléatoire ! Maintenant tout est à nouveau normal. :/
Faites-vous des tests ?
Bonjour,
Nous n'effectuons pas de tests actuellement sur le SSL.
Nous ne reproduisons pas le soucis mais allons continuer à investiguer.
Pouvez vous me confirmer que tout est bon pour vous ?
Cordialement,
Vincent
Oui, plus de problème pour le moment.
Merci à vous!
Julia
Une bonne nouvelle ! Vivement que ce souci soit résolu, merci Vcasse.
Bonjour
Ayan aussi cette erreur
cURL error 35: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
22 taches cron sont bloquées dont updraftplus et j'en passe.
A quand cette fameuse mise à jour
cela devient critique...
Merci
ETA 30 jours :
Possibilité d'appeler son site en HTTPS depuis un script en SSH, CRON ou depuis un web sans avoir d'erreur
C'est à dire
Suis pas trop expert ...
J'ai essayé
function ovhwpcron($url) {
if ($url == "https://monsiteweb.com/wp-cron.php") return "http://monsiteweb.com:443/wp-cron.php";
return $url;
}
add_filter('site_url', 'ovhwpcron');
et rien de plus
Ca veut dire que OVH a annoncé qu'ils allaient traiter le problème "sous une trentaine de jours" en gros dans un mois :blush:
Ton site est sous wordpress, si oui désactive la redirection automatique HTTP vers HTTPS.
Si ton sitemap est en https, les robots indexeront ton site en HTTPS.
Active le HSTS et tes visiteurs seront en HTTPS aussi automatiquement
et tes crons tourneront toujours.
c à d je supprime
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://monsiteweb.com/$1 [R,L]
et insere à la place (pour un an)
Header set Strict-Transport-Security "max-age=31530000" env=HTTPS
??
Merci de ton aide Buddy
Oui. Même ceci tout court
Header set Strict-Transport-Security "max-age=31530000"
Pour vérifier que le hsts est en place, après tu testés ton site sur
http://testuri.org/sniffer
Dans les HTTP Response Headers tu dois avoir
Strict-Transport-Security: max-age=31536000;
tes visiteurs seront redirigées vers la version https de ton site dès la 2eme page visitée.
le mieux de pas utiliser wp😂😂 soit de faire en joomla ou développer en fullstack en pure php.
oui surtout pas besoin jetpack, et autre plugin qui ne sert presque rien en même temps wp très dépendance script php pour modifier le fichier htaccess (exemple plugin booletproof)
ok
J'ai
Cache-Control: max-age=2592000
Expires: Mon, 16 Jan 2017 22:33:11 GMT
pourquoi 2592000 ? Un mystère alors que j'ai paramétrer 31530000...
Bref on verra si mes cron fonctionnent enfin
Bonsoir,
tu ne lis pas la bonne ligne ;)
çà c'est la mise en cache de la page,
la ligne qui concerne le HSTS commencent obligatoirement par
**Strict-Transport-Security**: max-age=159600000
Autant pour moi
Exact
Strict-Transport-Security: max-age=31530000
merci encore
Malgré tout cela cela ne fonctionne toujours pas ...
6 mois est recommandé inclus le hsts ; includesubdomain; preload;
à la ligne 173
https://github.com/alexonbalangue/Website-Secute-referencer/blob/master/Stable/FullStack%20DEV%20(Without%20Framework%20and%20CMS)/domain-name/.htaccess
sans l'URL c'est compliqué de dire ce qui ne vas pas ...
Mes domaines sont en HSTS depuis plus d'un an, le problème OVH a toujours été là ;)
Le HSTS n'est là que pour rediriger les visiteurs vers le HTTPS car si tu rediriges tout vers le HTTPS alors les crons seront aussi redirigés.
Sur mes sites, je ne force pas la redirection HTTP => HTTPS, mais j'ai mis le HSTS donc tous les visiteurs basculent automatiquement en HTTPS mais mes crons en http marchent toujours ...
Donc il ne faut pas faire la redirection http->https, contrairement à ce que conseille la doc OVH?
Idealement oui il faut la faire.
Quand tu as des crons qui tournent non, il faut activer le HSTS et avoir un sitemap avec les liens en HTTPS (comme çà bing et google t'indexent en HTTPS )
Et bien sur si votre lien est bien htst à vérifier sur ssllabs.com que le nom de domaine en question avant de dire sa marche pas (n'oublions pas de cliquer sur le lien de clear).
A mon avis c'est mort pour avoir le retour des crons fonctionnels comme le disait OVH avant la fin de l'année ...
Ils ont annoncé dans 30 jours à la dernière roadmap de la semaine dernière.
Donc ça risque plutôt d'être mi janvier voire fin janvier car ils sont souvent optimistes sur les délais.
Ah oui je n'avais pas vu cette roadmap.. Merci !
Concernant les autres CMS ou programmation à la main, ils sont aussi impactés?
Si tu programmes a la main, il suffit de faire un appel à http:// plutôt que https://
idem.
Meme punition pour moi :
> WP HTTP Error: cURL error 35: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO
lorsque je tente d'afficher le flux RSS de l'un de mes sites sur un autre de mes sites (tous 2 hébergés en multi-sites)
:confused:
Mes flux RSS sont passés ce matin, je ne sais pas si tu as eu la-même chose.
Sinon OVH, des nouvelles sur la release date du fix?
Pareil pour les flux RSS aux alentours de 11h30 !
Bonjo
Oui, j'ai résumé les informations ici : https://community.ovhcloud.com/community/fr/appels-https-depuis-son-site-ou-un-cron?id=community_question&sys_id=327371c881928210f0780f07683eb2a9
Nous ne l'avons pas encore déployé car nous avons freezé nos travaux durant cette période de fin d'année, afin d'éviter des surprises sur les sites entre la dinde et la bûche.
Joyeuses fêtes de fin d'année,
Vincent
Et aussi en prévision du bug de l'an 2017, n'oublions pas que c'est nombre premier :imp: :vertical_traffic_light:
Buddy, s'il te plait peux-tu rappeler le lien de la roadmap, je le cherche toujours.
Et on est fin janvier les cron passent toujours en http sans supporter le ssl.
Optimiste de chez optimiste !!!
pour les travaux c'est en cours !!
à suivre ici !
http://travaux.ovh.net/?do=details&id=22251
Bonne journée :)
https://community.ovhcloud.com/community/fr/roadmap-des-hebergements-web?id=community_question&sys_id=a9d2718c355a82d0f078b41a47e1f0e9
C'est ici : https://community.ovhcloud.com/community/fr/roadmap-des-hebergements-web?id=community_question&sys_id=a9d2718c355a82d0f078b41a47e1f0e9
Toujours la même erreur
cURL error 35: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
En attente d'une résolution !!!
Merci
Et ton hébergement est sur le cluster 12 ou 14 ?
Bonjour,
Tu m'as fait la même remontée par messagerie privée (et je t'ai d'ailleurs répondu).
Suite à ton feedback sur le cluster14, nous avons identifié que le traffic passant par le CDN avait toujours le soucis.
Nous intégrons maintenant le CDN. Le soucis est normalement résolu pour vous.
Cordialement,
Vincent
Une solution efficace pour réactiver le Cron WP en attendant que OVH gère le problème : le désactiver dans WP et le lancer via le Cron OVH :
- dans wp-config : define( 'DISABLE_WP_CRON', true );
- ensuite dans l'hébergement : Plus > Tâches planifiées - Cron > Ajouter une planification : commande à exécuter : wp-cron.php
et ça repart !
Est-ce que les gens qui sont sur 12, 14, 17 et 21 peuvent confirmer que c'est résolu ? Je suis sur 15 donc encore quelques jours à attendre ;)
Bonjour @Lisa
Je te confirme avoir eu plusieurs retours client qui me confirmaient que tout était réglé. @VincentF1, tu confirmes ?
Cordialement
Guillaume F.
Personnellement, les "pings" sont toujours inactifs même avec cette manipulation, j'attends la solution OVH.
C'est curieux car le wp-cron est exécuté à l'identique, qu'il soit lancé par wp ou par le serveur.
Les cron events des pings sont-ils créés et non exécutés, ou bien pas créés du tout ?
Si le cluster a bien été mis à jour http://travaux.ovh.net/?do=details&id=22251 , il faut indiquer le cluster pour que le bug soit corrigé.
Bonjour, à quand le cluster 13? merci
Le calendrier est dispo sur travaux.ovh.net section hébergement web
(le lien dans mon poste précédent y amène directement)
Bonjour,
Le problème se pose toujours de mon côté. Où en est sa résolution ? OVH a t'il mis en place une solution alternative ?
Merci
Bonjour,
quel cluster ? quoi comme problème exactement ?
Cordialement, janus57
Bonjour Janus,
Je pensais que nous étions tous sur le même problème dans ce topic.
Donc ce message d'erreur lors de la tentative de sauvegarde : cURL error 35: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
Bonjour,
En lisant les informations, l'on voit que le déploiement du correctif est en cours, il faut ensuite regarder la date par rapport à son cluster et l'on a la réponse de la date de déploiement pour son propre site.
Effectivement, 2017-02-08: cluster011 & cluster013, merci! :)
Bien sûr je suis dans le dernier cluster...mais apparemment, on tient le bon bout :)
017-02-09: cluster015 & cluster020
Merci pour les infos
Cluster 20 - impossible de faire un backup auto sur wp en attente egalement
B onjour,
Depuis 11h30 environ, nous avons à nouveau des erreurs SSL :
> Votre connexion n'est pas privée
Il se peut que des pirates soient en train d'essayer de dérober vos informations sur le site www. monsite .com (par exemple, des mots de passe, des messages ou des informations sur vos cartes de paiement). NET::ERR_CERT_COMMON_NAME_INVALID
ssl sur gravelines (cluster020).
Il y a une intervention en cours ?
Merci!
Julia
Bon ... Les erreurs CURL et compagnie qui survenaient à cause de la problématique de ce sujet sont revenus ... Tous les WordPress OVH que je possède qui sont sous un serveur mutualisés sont touchés !