Discussion :

[fbalien]

Bonjour

je suis avec Delphi 13.1
j'utilise datasnap pour les échanges client serveur avec les filtres de chiffrement pc1 et rsa
j'utilise les dll ssleay32.dll et libeay32.dll pour la partie openssl mais elles sont un poil vieillottes
il n'y a pas moyen d'utiliser les dernières dll openssl en v3.5.7 par exemple, il existe la v4

[XeGregory]

Bonjour

je suis avec Delphi 13.1
j'utilise datasnap pour les échanges client serveur avec les filtres de chiffrement pc1 et rsa
j'utilise les dll ssleay32.dll et libeay32.dll pour la partie openssl mais elles sont un poil vieillottes
il n'y a pas moyen d'utiliser les dernières dll openssl en v3.5.7 par exemple, il existe la v4

https://slproweb.com/products/Win32OpenSSL.html



Maintenant à voir si ça fonctionne !

[fbalien]

Merci XeGregory pour le lien
cela fourni bien les dll pour openssl 3 et 4 mais avec un format qui ne semble pas supporté par datasnap a première vue

Le projet fbarchi.exe a déclenché la classe d'exception TDBXError avec le message 'Le chargement du module SSL a échoué. Une ou plusieurs méthodes mappées ne sont pas disponibles.'.

déjà le nom des dll change
pour la v4 libcrypto-4-x64.dll et libssl-4-x64.dll
v3 libcrypto-3-x64.dll et libssl-3-x64.dll
je suppose que le contenue des dll n'est pas compatible avec les anciennes dll
ps : j'ai tenté de renommer les dll

[ShaiLeTroll]

Regarde aussi sur ton disque, en plus de celle que tu utilises, tu peux en trouver un tas d'autres versions, j'ai déjà eu plus de 20 versions différentes sur un PC Win10, chaque outil contenant sa propre version des deux DLL, y compris des outils Microsoft.

libeay32.dll contient plus de 3500 fonctions, même Indy ne fourni pas tous les headers, j'en ai ajouté pour gérer manuellement lecture de fichier PEM et chiffrement RSA
Je crois que celles que j'utilise est 1.0.2.11 (1.0.2k), je ne peux pas le confirmer étant en vacances, ça doit dater de Delphi 10 Seattle, la dernière ça doit être la 1.0.2.21 (1.0.2u)

Après c'est libeay32.dll -> libcrypto.dll (cela peut contenir le numéro de version Libcrypto-1_1.dll)
En théorie si Remy Lebeau fourni les nouveaux binaires, il a forcement développé une version Indy compatible que remplace celle de ton Delphi (Note c'est pas la branche Master mais OpenSSL-1.1, pire il y a une Merge Request encore ouverte : Proposed Update to support OpenSSL 3.x and earlier versions depuis 2 ans, Indy est surement pas du tout compatible nativement avec OpenSSL 4, tu vas devoir bricoler localement une branche spécifique)

[XeGregory]

je suppose que le contenue des dll n'est pas compatible avec les anciennes dll

Il y a de fortes chances.

DataSnap est obsolète aujourd’hui, si tu veux une solution pérenne, tu peux migrer vers RAD Server ou mORMot 2.

Perso utilise RAD Server, si tu veux rester dans l’écosystème Embarcadero.

[XeGregory]

bonjour @ShaiLeTroll

Indy existe-t-il toujours ?
Est-il encore maintenu et mis à jour ?

Dans les nouvelles versions de Delphi, Indy est bien intégré, mais à partir de quelle version exactement ?

[ShaiLeTroll]

DataSnap était basé sur Indy, je ne sais pas si cela a changé, je ne le savais même pas obsolète, j'ai vaguement bossé dessus, en 2011, pour reporter du DCOM/COM+ (obsolète MS) ...

Indy existe-t-il toujours ?
Est-il encore maintenu et mis à jour ?

Pas la moindre idée, bloqué en D10 Seattle, je ne pourrais même pas te dire la version actuelle fournie de Indy avec D13.?
c'est bien cela nous fait bosser de faire, refaire et défaire.

Mais on peut librement installer une autre version, c'est ma situation actuelle, une version un peu plus récente que celle fournie avec D10 mais je ne sais pas laquelle ... et quelques sources bricolées maison, il me semble.

Dans les nouvelles versions de Delphi, Indy est bien intégré, mais à partir de quelle version exactement ?

J'ai découvert Indy9 en D6, ...

cela remplaçait les composants TMAPI ou TNMFTP de D4, je n'ai jamais adopté le Socket Indy, le TServerSocket était très bien (fallait juste jamais utiliser le mode Event)
J'avais abandonné Indy en XE2, lui préférant les API Windows gérant nativement le HTTPS sans DLL (une époque au pénible Handshake Error) ou le SFTP ou Tunnel SSH via SecureBlackBox (très cher)
J'ai repris Indy parce qu'utilisé où je bosse, mais j'ai écrit une partie à base de TRESTClient pour l'éviter (j'ai un code proxy qui émule TRESTClient en Indy pour le débogage, la version D10 de TRESTClient manque encore de couverture sur la gestion d'erreur)

RAD Server, on dirait Delos XML Rad, 20 ans plus tard


Sinon, en terme d'exposition, cela fait 20 ans au moins que je vois le serveur Delphi (TCP, HTTP) utilisable uniquement depuis le réseau local (un cluster AWS par exemple) et c'est des frontaux Web (Linux, Kubernetes, Docker, Nginx, Apache, PHP) qui exposent les API Métiers et le Middleware.

En 2002, j'avais déjà des projets où le serveur (machine) hébergeant le serveur (logiciel) avait deux voire trois cartes réseaux, chacun cloisionné, l'un pour les systèmes robotisés, l'un pour l'ERP Entrepot, l'un pour l'ERP Compta.
Spécifique a plusieurs métiers où les réseaux ne devaient pas être exposés.

[XeGregory]

J’utilise Delphi 12.



En regardant de plus près sur GitHub, il semblerait qu’Indy continue d’être mis à jour.



RAD Studio 13 Florence inclut une copie d’Indy 10.6.3.11
https://www.indyproject.org/2025/09/...o-13-florence/

il n'y a pas moyen d'utiliser les dernières dll openssl en v3.5.7 par exemple, il existe la v4

Maintenant, on est sûr : Indy propose uniquement la version OpenSSL 3.3.2 ; il est donc normal que la version 4 ne fonctionne pas.

Donc, si tu travailles avec RAD Studio 13 Florence et la dernière version d’Indy (10.6.3.11), alors la seule version la plus récente reste OpenSSL 3.3.2, qui normalement ne devrait pas poser de problème.