cURL error 35: Unknown SSL protocol error in connection to api.payplug.com:443

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.

Le fichier de configuration doit être placé au même niveau avec le www,

non

il n'aura aucun effet au sein du répertoire.

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 ?

comme tout, avant d'affirmer, tester
comme dit (et testé) comme un .htaccess ou un .use

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