SSL Mail funktioniert nach Umstellung von Berlin nach Rio nicht mehr

[skoschke]

Hallo,

eine mit Berlin entwickelte App für Windows und Android holt und sendet Mails.

Dies funktionierte mit Delphi Berlin einwandfrei, nach Umstieg auf Rio bekomme ich unter Windows Could Not Load SSL Library Fehler und unter Android wird keine Verbindung hergestellt.

Am Code der App wurde in dieser Hinsicht nichts verändert, die beiden libcrypto.so und libssl.so aus Cersion 1.02h sind unverändert.

Ich habe nicht den geringsten Ansatz, wo ich die Ursache finden könnte!

Danke für Tips
Ciao
Stefan

[Daniel]

Sind INDY-Komponenten beteiligt? Denn dafür gab es unlängst einen Patch, gerade für das Zusammenspiel mit SSL:
"Web Server applications built with the Indy library (for Windows) are unable to load a SSL certificate. The issue was reported on Quality Portal as RSP-27144"

http://cc.embarcadero.com/Item/30906

[philipp.hofmann]

Zusatzfrage: Lieferst du nach Android-32 aus oder als Bundle nach Android-64 und Android-32? Bei Bundles ist zusätzlich folgender Fix relevant:
https://cc.embarcadero.com/item/30905

und du findest nützliche Infos hier, wie man die Pfade für die SSL-Libraries setzen muss in folgendem Thread
https://www.delphipraxis.net/202777-...id-32-apk.html

Hier der relevante Part, welchen man aber auch für Android-32-Apps genauso ausprobieren kann:

Delphi-Quellcode:

  {$IFDEF ANDROID}
    IdOpenSSLSetLibPath(String.Empty);
    IdSSLOpenSSLHeaders.Load();
    error:=IdSSLOpenSSLHeaders.WhichFailedToLoad();
    if (length(error)>0) then
    begin
      IdOpenSSLSetLibPath(IncludeTrailingPathDelimiter(TPath.GetLibraryPath));
      IdSSLOpenSSLHeaders.Load();
      error:=IdSSLOpenSSLHeaders.WhichFailedToLoad();
      if (length(error)>0) then
      begin
        IdOpenSSLSetLibPath(IncludeTrailingPathDelimiter(TPath.GetDocumentsPath));
        IdSSLOpenSSLHeaders.Load();
        log.d('SSL-Version(3): '+OpenSSLVersion);
        error:=IdSSLOpenSSLHeaders.WhichFailedToLoad();
        if (length(error)>0) then
        begin
          log.d('SSL-Errors: '+error);
        end;
      end else begin
        log.d('SSL-Version(2): '+OpenSSLVersion);
      end;
    end else begin
      log.d('SSL-Version(1): '+OpenSSLVersion);
    end;
  {$ENDIF}

[skoschke]

Danke, danke, danke, da habe ich ja erst mal jede Menge zu lesen...

Ich melde mich dann wieder...

Ciao
Stefan

[himitsu]

War es nicht so, dass die neueren Internet-Komponenten im Delphi das SSL vom System (Windows) nutzen?
Sich von Indy zu verabschieden und die neuen im Delphi enthaltenen Komponenten zu nutzen würde dann bedeuten, dass man nicht mehr mit den SSL-DLLs im Indy kämpfen muß.

Aber neben Indy verwenden auch DataSnap, InterBase und EMS ebenfalls das OpenSSL.

[philipp.hofmann]

Downloads und Uploads sollte man besser mit den Internet-Komponenten von Delphi durchführen. Die direkte E-Mail-Kommunikation geht damit aber nicht. Hier ist mir auch keine bessere Komponente als die Indy-Implementierung bekannt. Daher gibt es hier eine Abhängigkeit zu OpenSSL.

[skoschke]

Zitat:

War es nicht so, dass die neueren Internet-Komponenten im Delphi das SSL vom System (Windows) nutzen?
Sich von Indy zu verabschieden und die neuen im Delphi enthaltenen Komponenten zu nutzen würde dann bedeuten, dass man nicht mehr mit den SSL-DLLs im Indy kämpfen muß.

Wie versende ich mit den neueren Komponenten unter Android Mails mit SSL ohne einen Intent zu starten, wo der Nutzer erst noch quittieren muss?

Außerdem schreibst Du :

Zitat:

das SSL vom System (Windows) nutzen

ich aber möchte unter Android senden!

Ciao
Stefan

[himitsu]

Zitat:

Zitat von skoschke (Beitrag 1457008)

Wie versende ich ...

Gute Frage. :oops:

Zitat:

Zitat von skoschke (Beitrag 1457008)

ich aber möchte unter Android senden!

Wenn die das SSL von dem einem OS verwenden, dann werden sie bestimmt in den anderen OS es nicht anders machen. :stupid:

[philipp.hofmann]

Ich kenne keine Möglichkeit eine Mail ohne Benutzer-Quittierung zu versenden, außer eben mit Indy.

Und ja, mit den neuen Internet-Komponenten übernimmt das OS immer die SSL-Implementierung, d.h. für Android, wie für iOS, wie für MacOS und Windows (und wahrscheinlich auch Linux). Daher ist dies schon deutlich schicker, als Downloads und Uploads mit Indy durchzuführen. Aber hier geht es eben um Mails und nicht um Downloads und Uploads.

[skoschke]

so, folgender Code

Delphi-Quellcode:

  {$IFDEF ANDROID}
    IdOpenSSLSetLibPath(String.Empty);
    IdSSLOpenSSLHeaders.Load();
    error:=IdSSLOpenSSLHeaders.WhichFailedToLoad();
    if (length(error)>0) then
    begin
      IdOpenSSLSetLibPath(IncludeTrailingPathDelimiter(TPath.GetLibraryPath));
      IdSSLOpenSSLHeaders.Load();
      error:=IdSSLOpenSSLHeaders.WhichFailedToLoad();
      if (length(error)>0) then
      begin
        IdOpenSSLSetLibPath(IncludeTrailingPathDelimiter(TPath.GetDocumentsPath));
        IdSSLOpenSSLHeaders.Load();
        log.d('SSL-Version(3): '+OpenSSLVersion);
        error:=IdSSLOpenSSLHeaders.WhichFailedToLoad();
        if (length(error)>0) then
        begin
          log.d('SSL-Errors: '+error);
        end;
      end else begin
        log.d('SSL-Version(2): '+OpenSSLVersion);
      end;
    end else begin
      log.d('SSL-Version(1): '+OpenSSLVersion);
    end;
  {$ENDIF}

bringt in jedem Zweig eine riesen Liste WhichFailedToLoad und ich bekomme weiterhin CouldNotLoadSSLLibrary-Fehler.

Unter RadStudio Berlin funktionierte alles problemlos, da muss es doch irgendeinen Unterschied zum neuen Rio geben?

Ciao
Stefan

[Klaus01]

Das Format der Applikation (32 oder 64 Bit) ist unter beiden Delphi Versionen die gleiche?

Grüße
Klaus

[skoschke]

Ja, Android 32 Bit

Was mir jetzt aufgefallen ist:
Eine Testfunktion zum Verbinden mit Posteingangs- und Ausgangsserver geht ohne Fehlermeldung, erst beim Senden kommt das CouldNotLoadSSLLibrary

Delphi-Quellcode:

var
  smtp: TIdSMTP;

    smtp := TIdSMTP.Create(nil);
    SSL := TIdSSLIOHandlerSocketOpenSSL.Create(nil);
    msg := TIdMessage.Create(nil);
    try
      smtp.ConnectTimeout := 60000;
      smtp.Host := 'smtp.1und1.de';
      smtp.Port := 465;
      smtp.Username := user;
      smtp.Password := pwd;
      SSL.Destination := 'smtp.1und1.de' + ':' + IntToStr(smtp.Port);
      SSL.Host := 'smtp.1und1.de';
      SSL.Port := smtp.Port;
      SSL.SSLOptions.Method := sslvTLSv1_2;
      smtp.IOHandler := SSL;
      smtp.UseTLS := utUseExplicitTLS;
      msg.CharSet := 'iso-8859-1';
      msg.Subject := 'Test';
      msg.Recipients.add.Address := mailadr;
      msg.FromList.add.Address := mailadr;
      msg.Body.Text := 'Das ist ein Test';
      smtp.Connect;
      smtp.Send(msg); // <-- hier knallt es
      smtp.DisConnect;
    except
.....

Ciao
Stefan

[philipp.hofmann]

Also bei mir funktioniert es so mit Android-32 und auch Android-Bundle (32 und 64) mit Delphi Rio.
Die 64-Bit-Version habe ich von hier:
https://git.fairkom.net/chat/faircha...android-arm64/
und die 32-Bit-Version habe ich von hier:
https://git.fairkom.net/chat/faircha...sl/android-arm

In welche Pfade deployst du die beiden so-Dateien und mit welchem Namen (Bereitstellung)?

[skoschke]

Hallo,

die Bereitstellung erfolgt in assets\internal, ich verwende die 102h-Version, Deine 102j scheint ja neuer zu sein, habe sie schon geladen....

Nach unendlichem Suchen habe ich jetzt die Ursache, warum es erst beim Senden knallte, Connect und Login zum Server funktionierte:

Die Angaben Benutzername, Passwort und zugehörige Mailadresse passte nicht zusammen (da wäre ich nie drauf gekommen da Angaben vom Kunden),
weiterhin funktioniert sslvTLSv1_2 nicht auf älteren Devices und als letztes muss man beim Server von Alfahosting sich vor jedem Sendevorgang noch mal identifizieren.

Das nicht funktionierende sslvTLSv1_2 (mit sslvTLSv1 gibt es keine Probleme) brachte die Meldung CouldNotLoadSSLLibrary (die ja eigentlich nicht richtig ist) und damit habe ich mich im Kreis gedreht :-)

Ob ich jetzt noch Deine Variante 102j einbaue weiß ich noch nicht, wer weiß was da wieder knallt...

Ciao
Stefan

[fppoels]

Web Server applications built with the Indy library (for Windows) are unable to load a SSL certificate. The issue was reported on Quality Portal as RSP-27144