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
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 
?
… 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. 
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 
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.
ssl sur gravelines (cluster020).
Pouvez-vous internenir ?
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.