FAQ n°24051, publiée le 22/02/2023, mise à jour le 04/10/2023
Dans quel cas un échange HTTPS ou FTPS peut échouer après la recompilation d'une application en version 28 ?

La version 28 de WINDEV, WEBDEV et WINDEV Mobile utilise maintenant la couche OpenSSL en version 3 pour sécuriser les échanges qui nécessitent un chiffrement : HTTP, FTPS. Cela s'applique aux applications sous Windows, Android, iOS... Dans les versions antérieures, OpenSSL 1.1 servait.


Exceptionnellement il peut arriver que l'appel d'un webservice SOAP ou d'une API REST en HTTPS, ou la connexion à un serveur FTPS, soit possible dans une version antérieure, mais échoue en version 28. En effet, l'application recompilée en version 28 impose une sécurité maximale de l'échange avec OpenSLL 3, et certains serveurs peuvent ne pas la supporter.


Par exemple la fonction RESTEnvoie ou HTTPEnvoie échoue avec :


Le serveur HTTP ne répond pas. Vérifiez l'adresse et l'accessibilité au serveur.

Code erreur 100072 ou 100138

Message d'erreur système 35

SSL connect error 35


ou : 


Le chargement du fichier de certificat a échoué.

Code erreur : 101820

Erreur interne :

error:0A00018E:SSL routines::ca md too weak






Dans ce cas, il est important de contacter l'administrateur du serveur, car l'échec est le plus souvent révélateur d'une couche SSL en version trop ancienne sur le serveur, ou de certificats trop anciens (négociation tls en échec ou cipher erroné...). Le log du serveur web ou ftp montre précisément la différence en enchaînant l'appel valide dans une version antérieure, puis celui qui échoue en version 28.


Si sur le serveur web ou ftp contacté rien ne permet de trouver l'origine du défaut, il est conseillé de joindre au Support Technique Gratuit le code d'appel, ou de connexion. Cela permet à l'équipe développement de tracer l'échange avec ce serveur particulier afin de déterminer : 

  • s'il faut une adaptation du framework en version 28 pour respecter des contraintes particulières de ce serveur (ajout par exemple de nouvelles erreurs de sécurité à ignorer avec la propriété IgnoreErreur),

  • ou s'il y a une défaillance réelle de ce serveur à signaler en urgence à ses administrateurs.



A partir d'exemples déjà signalés au support, trois cas ont pu être isolés : 


  • Renégociation sécurisée non supportée par le serveur :

    OpenSSL 3 considère comme une faille de sécurité importante le fait qu'un serveur ne supporte pas la renégociation sécurisée (https://www.rfc-editor.org/rfc/rfc5746). Par défaut la connexion n'est pas faite avec en retour une erreur "Le serveur ne répond pas" avec le message d'erreur système : "SSL connect error".

    Afin de permettre la connexion, la solution recommandée est de mettre à jour le serveur contacté pour qu'il supporte la renégociation sécurisée. C'est une exigence de sécurité actuelle.

    S'il s'agit du serveur d'un tiers ne pouvant pas être mis à jour, on peut autoriser quand même la connexion en ignorant cette erreur, mais la sécurité est amoindrie. La variable RestRequete ou HttpRequête doivent être complétée de l'erreur que l'on accepte d'ignorer : 
    maReq.IgnoreErreur = httpIgnoreRenégociationNonSecurisée

  • Utilisation d'un certificat serveur avec des ciphers et algorithme de signature de niveau de sécurité 0 :

    OpenSSL 3 considère dépréciés les certificats dont l'algorithme de chiffrement est 0.
    Par exemple rsa-pkcs1-sha1 est un algorithme de sécurité 0 (visible dans les propriétés du certificat dans un navigateur qui affiche une page du site). Si un serveur utilise un certificat qui a été signé avec cet algorithme, et que le client utilise OpenSSL 3, le serveur ferme la connexion TLS. Cela provoque également le retour "le serveur ne répond pas" avec le message d'erreur système : "SSL connect error".

    Afin de permettre la connexion, la solution recommandée est de mettre à jour le certificat du serveur contacté pour qu'il utilise un chiffrement actuel.

    S'il s'agit du serveur d'un tiers ne pouvant pas être mis à jour, il est possible d'ignorer l'erreur mais la sécurité est réduite : 
    maReq.IgnoreErreur = httpIgnoreDéprécié

Voir aussi: HTTPS, HTTPEnvoie, RESTEnvoie, FTP