bonjour,
depuis une mise à jour d'une extension (payplug for woocommerce) j'ai le message suivant, dans la page de configuration de l'extension:
cURL error 35: Unknown SSL protocol error in connection to api.payplug.com:443
j'ai contacté l'éditeur qui me renvoie vers ovh.
Ovh m'indique qu'il faut être en stable plutôt qu'en Legacy.
si je passe en stable, j'ai une erreur de connexion à la base de donnée...
de retour vers ovh, on me renvoie vers le créateur du thème dans wordpress.
le créateur me demande de réinitialiser mon thème par défaut et voir si le problème persiste...
La question est : vais-je perdre toute ma configuration en revenant avec le thème initial??
en vous remerciant
cURL error 35: Unknown SSL protocol error in connection to api.payplug.com:443
Sujets apparentés
- Impossible de mettre en place certificat ssl
43163
05.12.2016 14:02
- SSL actif mais site web non sécurisé
30427
20.05.2018 14:33
- Ssl0.ovh.net : impossible de vérifier l'identité serveur
26532
17.05.2019 13:38
- Problème SSL/multisite "Une erreur est survenue lors de la modification du ou des domai
23199
17.02.2020 09:04
- Certificat SSL et VPS
19386
01.02.2017 11:56
- OVH devrait rapidement trouver un nouveau moyen de gérer les certificats SSL
15640
06.12.2016 08:45
- Smtp ssl0.ovh.net = Problème d'envoi avec Orange Pro
9700
28.03.2019 07:52
- Redirection 301 et SSL
9387
10.09.2017 09:16
- Impossible de regénérer certificat SSL
9130
20.09.2017 18:55
- Certificat SSL en cours de création trop longue !
9008
04.04.2018 19:18
Bonjour,
Typiquement je pense que vous aviez installé ce WordPress via une installation en 1clic quand c'était encore l'ancien système.
Du coup vous allez sûrement devoir migrer votre BDD du SQL Module vers une "vraie" BDD.
Cordialement, janus57
Bonjour,
Legacy utilise de "vieux" protocoles de sécurité qui sont probablement désactivé depuis le 30 juin par les systèmes de paiement.
Il faut régler le problème de connexion à la base de données. (il y a pas mal de sujet dessus)
il faut remplacer l'ancien nom du serveur SQL par quelque chose du style nom_de_la_bdd.mysql.db
merci pour vos réponses.
je me suis connecté sur "l'ancienne" base et je l'ai exportée.
ensuite je me suis connecté sur la nouvelle et importé la précédente.
j'ai aussi modifié les identifiants dans config.php...
j'ai modifié ensuite mon environnement en stable.
Pas mieux :"Erreur lors de la connexion à la base de données" !!!!
oups j'avais pas modifié le nom du serveur !!! tjs sur l'ancien.
résolu
Bonjour,
Avez vous résolu le problème ?
Aujourd'hui paylug refuse de se connecter( il fonctionnait bien avant) j'ai le même message lors de l'activation du mode de paiement :
cURL error 35: Unknown SSL protocol error in connection to api.payplug.com:443
Merci.
Bonjour,
Vous êtes bien sûr l'environnement stable ?
Cordialement, janus57
bonsoir,
oui c'est résolu depuis le 16/07 ;-)
Bonjour,
Je vous remercie pour votre retour, j'ai résolu le soucis
J'ai reçu une réponse du service technique, j'ai du créer un fichier .ovhconfig au même niveau avec mon dossier www contenant la configuration suivante :
app.engine=php
app.engine.version=7.0
http.firewall=none
environment=production
container.image=stable
Bonjour ,
J'ai le même message d'erreur mais avec l'API mailjet,
cURL error 35: Unknown SSL protocol error in connection to api.mailjet.com:443
j'ai modifié mon fichier .ovhconfig dans le repertoire de mon site, à savoir www
app.engine=php
app.engine.version=7.2
http.firewall=none
environment=production
container.image=stable
mais pour moi aucun effet, j'ai toujours l'erreur , c'est sporadique mais cela dure au moins 2 heures à chaque fois.
Quelqu'un peut-il m'aider à fixer le problème ?
Bonjour,
normalement le .ovhconfig devrais être à la racine du FTP et devrais être unique, car si vous en avez plusieurs la configurer peut tourner en fonction du .ovhconfig qui est pris en compte.
Cordialement, janus57
je viens de tester un `.ovhconfig` ala htaccess. c'est celui qui est situé dans le répertoire courant *ou* supérieur qui est pris en compte
donc ne pas seulement de cantonner au root `/`, vérifier (et supprimer?) des `.ovhconfig` éventuels dans le dossier du script, `www` j'imagine
la configuration dans le manager ne modifie que le `.ovhconfig` du root
Bonjour,
Le fichier de configuration doit être placé au même niveau avec le www, il n'aura aucun effet au sein du répertoire.
non
si
Bonjour,
Pour mon cas le fichier dans le dossier n'a aucun effet, possible qu'il y avait un autre dans la racine j'ai pas fait attention, reste à vérifier la priorité
comme tout, avant d'affirmer, tester
comme dit (et testé) comme un .htaccess ou un .user.ini
Merci pour vos commentaires,
Après nouveau retour du fournisseur API, dans mon cas, le problème vient du fait que le fournisseur api a un système de protection contre les tentative abusives de connexion, au bout de plusieurs tentatives échouées le fournisseur api (mail jet dans mon cas) bloque pendant 1 heure l'adresse ip du site, pendant le laps de temps j'ai donc l'erreur" cURL error 35", ce qui explique le caractère aléatoire du problème. Dans mon cas je suis sur un offre performance 1 chez OVH, et je comprends que mon adresse ip n'est pas fixe et qu'elle partagée avec d'autres clients OVH. Le fournisseur API m'explique que le problème ne vient pas de moi directement mais des autres qui partagent la même ip que moi, et me conseille donc de basculer sur une offre avec IP fixe et dédiée , j'ai quoi comme solution chez OVH d'après vous ? basculer sur une offre CLOUD WEB ?
concernant le .ovhconfig, qui était bien pris en compte dans mon cas au final : Je comprends donc que la bonne pratique , si on est utilise pas le multisite, est de supprimer le .ovhconfig du dossier www et de conserver uniquement celui qui est créé par "ovh manager" à la racine du repertoire www , c'est bien ça ?
moui, c'est pas ce que j'appellerais une bonne pratique, mais le manager Ovh gère le `/.ovhconfig` et que je vois parfois ***en plus*** un `/www/.ovhconfig`, qui surchargera donc le fichier parent.
supprimer le secondaire permet de se référer aux indications du manager
mon hypothèse était que le souci était du à un souci de version dans le container
si on est dans le cadre d'un multisite/multiconfig ne pas tenir compte de ma remarque