Indy/OpenSSL: Komplette Zertifikatskette im Client ermitteln

[christophspaeth]

Hallo,

(wie) kann ich bei einem mit Indy+OpenSSL geschriebenen TLS-Client an das Root-Zertifikat kommen, ohne eine Liste mit erlaubten Root-Zertifikaten bereitzustellen?

Konkreter: Bei mit einem TIdSMTP (=SMTP-Client) möchte ich die komplette Zertifikatskette vom Server auslesen und zur Anzeige bringen.
Dazu habe ich im OnVerifyPeer Funktionalität, die mir die benötigten Werte ausgibt bzw. in eine Struktur schreibt. Das funktioniert grundsätzlich auch, aber für die root-CA wird das Event nicht ausgelöst. Liegt das an Indy bzw. OpenSSL oder habe ich nur etwas was falsch konfiguriert?

Beispiel: "mail.example.com" ist signiert von "StartCom Class 2 Primary Intermediate Server CA" ist signiert von "StartCom Certification Authority".
Nun bekomme ich ein Event für das Zertifikat "StartCom Class 2 Primary Intermediate Server CA" mit ADepth = 1 und ein Event für "mail.example.com" mit ADepth=0. Ich bekomme aber kein Event für "StartCom Certification Authority". Die VerifyDepth ist auf 9 gestellt (was wohl auch der default ist) und ich habe keine Datei mit Rootzertifikaten angegeben.

Certificate Info:
Subject: mail.example.com
Issuer: StartCom Class 2 Primary Intermediate Server CA
Certificate Info:
Subject: StartCom Class 2 Primary Intermediate Server CA
Issuer: StartCom Certification Authority

Delphi-Quellcode:

procedure TMyClass.InitTls;
var
  SslIoHandler: TIdSSLIOHandlerSocketOpenSSL;
begin
  SslIoHandler := TIdSSLIOHandlerSocketOpenSSL.Create(FSMTPClient);

  SslIoHandler.SSLOptions.Method := sslvTLSv1;
  SslIoHandler.SSLOptions.VerifyMode := [sslvrfPeer];
  SslIoHandler.SSLOptions.VerifyDepth := 9; // 9 is default: https://linux.die.net/man/3/ssl_ctx_set_verify_depth
//  SslIoHandler.SSLOptions.RootCertFile ; // don't have one
  SslIoHandler.OnVerifyPeer := TlsVerifyPeer; // Necessary for certificate verification

  FSMTPClient.IOHandler := SslIoHandler; // ownership of SslIoHandler is moved
  FSMTPClient.UseTLS := utUseRequireTLS;
end;

function TMyClass.TlsVerifyPeer(Certificate: TIdX509;
  AOk: Boolean; ADepth, AError: Integer): Boolean;
begin
  // store/output certificate info...

  // for now we do not want to continue - present certificates to the user first
  result := ADepth > 0; // false for leaf cert; true for (intermediate) CAs
end;

Zweiter Test: Gegen eine Exchange-Server Testinstallation mit "mail.testexchange.mydomain" signiert von "meineWindowsCA" bekomme ich nur das Peer-Zertifikat präsentiert, dafür gleich zwei mal (beide Male mit ADepth = 0; das erste mal mit AError = X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY(20), das zweite mal mit AError = X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE(21)).

schon mal Danke für die Hilfe!

[mjustin]

Welche Indy Version ist es, eine relativ neue oder eher etwas "antiquarisches"?

[christophspaeth]

Hallo mjustin,

Es ist kein Indy 9, falls du das meinst ;-)

Im Ernst: Das Projekt ist zwar noch auf Delphi XE2 und der dort mitgelieferten Indy-Version (10.5.8 wenn ich mich nicht täusche), aber das Verhalten hat sich mit Delphi Berlin (und folglich auch einer halbwegs aktuellen Indy?) nicht geändert.

Gruß Christoph

[christophspaeth]

Crosspost Info: Nachdem ich leider nicht weiter gekommen bin, habe ich das Thema jetzt auch mal auf StackOverflow gestellt: http://stackoverflow.com/questions/4...dy-and-openssl

[Codehunter]

An dem selben bzw. einem sehr ähnlichen Thema war ich auch schon mal dran. Die Verifizierung der kompletten Zertifikatskette und -infrastruktur ist denke ich ein ganz wichtiges Thema. Man findet aber in Bezug auf Indy so gut wie nichts darüber.

[mjustin]

Zitat:

Zitat von christophspaeth (Beitrag 1351911)

Crosspost Info: Nachdem ich leider nicht weiter gekommen bin, habe ich das Thema jetzt auch mal auf StackOverflow gestellt: http://stackoverflow.com/questions/4...dy-and-openssl

Die Antwort ist ja nun online:

"The server does not send the Root CA because the client must already have it.. ... If the client does not have the root, then a bad guy can simply swap-in his root and chain."

Frei übersetzt lese ich das so: ohne das Root Zertifikat bereits auf einem anderen Weg dem Client bereitgestellt zu haben, kann man die Root CA nicht prüfen. Für die Prüfung muss man kontrollieren, ob das vorletzte Zertifikat mit dem Root-Zertifikat signiert wurde, nehme ich an.

[christophspaeth]

Hallo,

danke an alle, die sich hier beteiigt und das Hirn zermartert haben :-)

Zitat:

Zitat von mjustin (Beitrag 1352078)

Frei übersetzt lese ich das so: ohne das Root Zertifikat bereits auf einem anderen Weg dem Client bereitgestellt zu haben, kann man die Root CA nicht prüfen. Für die Prüfung muss man kontrollieren, ob das vorletzte Zertifikat mit dem Root-Zertifikat signiert wurde, nehme ich an.

Damit wir es hier auch (halbwegs) vollständig haben eine kurze Zusammenfassung, so wie ich es verstanden habe:
- Manche Server schicken auch das Root-Zertifikat, manche nicht - das ist nach Standard auch nicht erforderlich
- Tatsächlich ist der Nutzen eines vom Server übertragenen Root-Zertifikats sehr beschränkt. Ohne eine bestehende Vertrauensstellung ist auch das Root-zertifikat nichs besonderes - niemand hindert mich, mir selber eine CA mit dem Namen "Symantec Root CA" (oder wie auch immer die heißt) nebst entsprechenden Intermediate-CAs erstellen. Und man muss auch bedenken, dass es in der Tat sehr unwahrscheinlich ist, dass ein Nutzer den Fingerprint der Root-CA überprüft.

Im der Folge bedeutet das aber, dass man eigentlich nur die beiden Möglichkeiten hat, sich entweder doch den Aufwand der Zusammenstellung und Pflege einer Root-CA-Liste antuen muss (nur am Rande die Frage: kann und darf man die Liste von Firefox verwenden?), oder auf die Anzeige des Root-Zertifikats (bzw. der ganzen Chain) zu verzichten und den Benutzer fragt "ist das der Fingerbadruck deines Server-Zertifikats?" - eine angezeigte Zertifikatskette täuscht hier möglicherweise eine "Echtheit" vor, die nicht überprüft wurde.

P.S.: Theoretisch könnte man wahrscheinlich auch die Zertifikatskette irgendwie an die Windows-CryptoAPI zur Überprüfung übergeben, da stellt sich mir aber die Frage der Sinnhaftigkeit, OpenSSL und CryptoAPI zu vermischen