Zertifikat nutzen

**christophspaeth**

Hallo zusammen,
auch wenn das ursprüngliche Problme gelöst zu sein scheint, möchte ich noch ein paar Punkte anmerken:
1) Als Ergänzung zu mjustin: Assertor stellt compilierte Versionen von OpenSSL (meistens schon kurz nach den offiziellen Erscheinen) zur Verfügung, siehe dazu

http://www.delphipraxis.net/114945-i...updates-6.html. Auf dem Server liegen sie meistens auch schon bevor sie hier in der DP gepostet werden.
2) Um das Problem mit indy und Openssl zu umgehen, hat Embarcadero mit einer der letzten Delphi-Versionen einen eigenen http-Client eingeführt, der auch für https kein openSSL benötigen und zur Zertifikatsprüfung den Windows CertStore verwenden soll. Damit habe ich aber noch keine Erfahrung, und sollte ich etwas falsches geschrieben haben, bitte ich um Korrektur!

**Zwirbel**

Zitat von Zwirbel:

Hallo,

per TRestClient/TRestRequest greifen wir auf eine Schnittstelle eines Kunden zu, derzeit noch per HTTP. Wenn unser Schnittstellen-Programm produktiv gehen soll, dann soll es aber per HTTPS arbeiten. Dazu stellt uns der Betreiber der Schnittstelle dann ein "Zertifikat" zur Verfügung. Damit habe ich bisher keine Erfahrung. Leider habe ich auch auf mehrfache Anfrage dieses Zertifikat nocht nicht erhalten und kann mir so noch keine Vorstellung davon machen, was das eigentlich genau ist (vermutlich eine Datei, so stelle ich mir das vor). Ich wurde lediglich gefragt, ob wir ein Zertifikat in unsere Anwendung einbinden könnten. Ich wüsste aber nicht wie man in Delphi Seattle ein solches einbindet (irgendwo in den Projektoptionen oder so).

Nun bin ich der Spur

http://docwiki.embarcadero.com/RADSt...oraussetzungen nach gegangen, und habe mir eine TIdHTTP und eine TIdSSLIOHandlerSocketOpenSSL-Komponente aufs Formular gepappt, aber welche Properties muss ich nun wie füllen?

zusammenfalten · markieren

Delphi-Quellcode:

			object IdHTTP: TIdHTTP

  IOHandler = IdSSLIOHandlerSocketOpenSSL

  AllowCookies = True

  ProxyParams.BasicAuthentication = False

  ProxyParams.ProxyPort = 0

  Request.ContentLength = -1

  Request.ContentRangeEnd = -1

  Request.ContentRangeStart = -1

  Request.ContentRangeInstanceLength = -1

  Request.Accept = 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8'

  Request.BasicAuthentication = False

  Request.UserAgent = 'Mozilla/3.0 (compatible; Indy Library)'

  Request.Ranges.Units = 'bytes'

  Request.Ranges = <>

  HTTPOptions = [hoForceEncodeParams]

  Left = 120

  Top = 408

end

object IdSSLIOHandlerSocketOpenSSL: TIdSSLIOHandlerSocketOpenSSL

  MaxLineAction = maException

  Port = 0

  DefaultPort = 0

  SSLOptions.Mode = sslmUnassigned

  SSLOptions.VerifyMode = []

  SSLOptions.VerifyDepth = 0

  Left = 120

  Top = 460

end

Letztere hat ein Property SSLOptions und darin ein "CertFile"- und ein "RootCertFile"-Property, da könnte ich mir vorstellen, dann ein "Zertifikat", wie ich es erhalten soll, einzutragen. Aber wie verbandel ich das ganze mit dem Rest der Anwendung? Wirklich was erhellendes habe ich im Netz dazu nicht gefunden. Und mit der Indy-Doku komme ich auch nicht klar (viele Links auf der Webseite sind tot), da finde ich kein rudimentäres Beispiel, das die Verwendung von TIdHTTP oder TIdSSLIOHandlerSocketOpenSSL zeigt.

Hat jemand ein Beispiel an der Hand wie man mit TIdHTTP/TIdSSLIOHandlerSocketOpenSSL Zertifikate nutzt?

Danke. Gruß, Markus

Ich komme noch mal zurück auf meine eigene Frage. Das Problem wurde nämlich bis jetzt noch nicht gelöst. Die Schnittstelle selbst ist zwar seit Jahren im Einsatz, aber bisher halt über HTTP, ohne Zertifikat. Mein Problem ist immer noch, ich weiß nicht ob und wenn ja, was ich tun muss, um das Zertifikat, das mir die IT-Abteilung des Kunden zur Verfügung gestellt hat, zu „kommunizieren“. Das Zertifikat steckt in einer Datei mit der Endung „.CER“. Es sieht so aus:

markieren

Code:

			-----BEGIN CERTIFICATE-----

[ca. 2700 Zeichen]

-----END CERTIFICATE-----

Letztlich habe ich dann in der Registry einen Eintrag der Art:

markieren

Code:

			[HKEY_CURRENT_USER\SOFTWARE\Microsoft\SystemCertificates\addressbook\Certificates\[40 Zeichen]]

"Blob"=hex:[Hex-Werte]

Die Schnittstelle selbst arbeitet mit den Komponenten „TRestClient“, „TRestRequest“ und „TRestResponse“. Wie gesagt, seit Jahr und Tag per HTTP ohne Probleme.

Wenn ich jetzt einfach die URL die ich habe, umstelle von:

markieren

Code:

http://1.1.1.1/dings/v1.1

auf:

markieren

Code:

https://1.1.1.1/dings/v1.1

und dann das „Execute“ des TRESTRequest absetzte erhalte ich:

markieren

Code:

Modul: REST-Anforderung fehlgeschlagen: Unspecified certificate from client

Was bedeutet die Fehlermeldung nun konkret? Was ist da „unspezifiziert“?

Erschwerend kommt hinzu, dass ich von meinem Entwicklungsrechner aus per VPN mit der Kundeninfrastruktur verbunden bin. Aus Erfahrung weiß ich, dass es bei einigen Dingen schon einen Unterschied gemacht hat, ob man direkt im entsprechenden Zielnetzwerk unterwegs ist oder eben von „außen“ per VPN kommt.

Leider kann mir die Kunden-IT auch nicht wirklich weiter helfen.

Es wurde z. B. empfohlen mal mit einer PowerShell eine Abfrage an die Schnittstelle abzusetzen, um sozusagen das prinzipielle Funktionieren des Zertifikates zu testen:

markieren

Code:

			Invoke-WebRequest -Uri "https://1.1.1.1/dings/v1.1" -Certificate 'Cert:\CurrentUser\[40-Zeichen]'
		

Das liefert mir aber:

markieren

Code:

			> PS C:\WINDOWS\system32> Invoke-WebRequest -Uri "https://1.1.1.1/dings/v1.1" -Certificate 'Cert:\CurrentUser\[40-Zeichen]'

> Invoke-WebRequest : Der Parameter "Certificate" kann nicht gebunden werden. Der Wert

> "Cert:\CurrentUser\[40-Zeichen]" kann nicht in den Typ

> "System.Security.Cryptography.X509Certificates.X509Certificate" konvertiert werden. Fehler: "Das angegebene Pfadformat

> wird nicht unterstützt."

> In Zeile:1 Zeichen:85

> + ... Certificate 'Cert:\CurrentUser\[40-Zeichen] ...

> +                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>     + CategoryInfo          : InvalidArgument: (:) [Invoke-WebRequest], ParameterBindingException

>     + FullyQualifiedErrorId : CannotConvertArgumentNoMessage,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

Da bin ich mit meinem Latein am Ende.

Ich setze noch Delphi 10 Seattle ein. Lässt sich mein Problem durch Umstieg auf die aktuelle Version lösen?

Oder kann mir jemand aus eigener Erfahrung bestätigen, dass man, um ein Zertifikat (wie ich es oben beschrieben habe) in seinem eigenen Code zu nutzen gar nichts tun muss? Und das Zertifikat muss einfach auf dem Rechner, auf dem die HTTPS-Abfrage gestellt wird, vorhanden sein?

Danke im Voraus für etwas Erhellung. Gruß, Markus

**mjustin**

Zitat von Zwirbel:

Oder kann mir jemand aus eigener Erfahrung bestätigen, dass man, um ein Zertifikat (wie ich es oben beschrieben habe) in seinem eigenen Code zu nutzen gar nichts tun muss? Und das Zertifikat muss einfach auf dem Rechner, auf dem die HTTPS-Abfrage gestellt wird, vorhanden sein?

Danke im Voraus für etwas Erhellung. Gruß, Markus

"CertFile"- und ein "RootCertFile"-Property kenne ich nur von Indy HTTP Server - diese Properties muss man nicht zuweisen, der HTTP Client benötigt sie nicht. Daher würde ich sie erst einmal ignorieren.

Das Zertifikat des HTTPS Servers kann man auch mit dem Web Browser downloaden und dann mit der CR Datei vergleichen. Sind sie identisch, ist die CR Datei einfach nur das Serverzertifikat. Der Anbieter des Webservice sollte die Frage ob es das Server- oder ein Clientzertifikat ist eigentlich beantworten können.

Ich würde daher einfach die "CertFile"- und ein "RootCertFile"-Property leer lassen und einen REST Request ausführen. (Oder den Endpoint im Webbrowser oder per curl aufrufen)

**Codehunter**

Mir schwant da schon wieder übles... Zertifikate werden normalerweise nicht auf diese Weise verteilt, es sei denn es sind selbst erstellte weil man sich das Brimborium mit den CA sparen wollte.

Die biegt man dann mit viel Verrenkungen in den Zertifikatsspeicher von Windows rein, dreht an den Sicherheitseinstellungen rum bis die Verbindung "irgendwie" läuft und das nächstbeste Windows-Update dreht die Einstellungen wieder zurück. Meistens weil die Zertifikatskette nicht passt oder das Stammzertifikat wiederrufen wurde.

Für gewöhnlich stellt der Webserver die Public Keys selbst zur Verfügung und die Komponenten handeln die Verschlüsselung aus. Bei den Indys kann an die Prüftiefe noch einstellen (Zerti-Kette bis zum Stamm prüfen oder nicht), bei den REST-Komponenten geht das schon nicht mehr, weil alles an den Systemeinstellungen hängt.

Also kurz gesagt: Vergiss erstmal die Zertifikatsdateien. Schreib einfach statt http:// dann https:// in den URL und schau was passiert. Ggf. noch den Port manuell von 80 auf 443 ändern, mehr sollte eig. nicht nötig sein.

**Zwirbel**

Zitat von Codehunter:

Mir schwant da schon wieder übles... Zertifikate werden normalerweise nicht auf diese Weise verteilt, es sei denn es sind selbst erstellte weil man sich das Brimborium mit den CA sparen wollte.

Die biegt man dann mit viel Verrenkungen in den Zertifikatsspeicher von Windows rein, dreht an den Sicherheitseinstellungen rum bis die Verbindung "irgendwie" läuft und das nächstbeste Windows-Update dreht die Einstellungen wieder zurück. Meistens weil die Zertifikatskette nicht passt oder das Stammzertifikat wiederrufen wurde.

Für gewöhnlich stellt der Webserver die Public Keys selbst zur Verfügung und die Komponenten handeln die Verschlüsselung aus. Bei den Indys kann an die Prüftiefe noch einstellen (Zerti-Kette bis zum Stamm prüfen oder nicht), bei den REST-Komponenten geht das schon nicht mehr, weil alles an den Systemeinstellungen hängt.

Also kurz gesagt: Vergiss erstmal die Zertifikatsdateien. Schreib einfach statt http:// dann https:// in den URL und schau was passiert. Ggf. noch den Port manuell von 80 auf 443 ändern, mehr sollte eig. nicht nötig sein.

Danke, auch an mjustin, für die Antworten.

Vielleicht noch mal was zum Hintergrund. Unser Kunde bekommt von der IT-Abteilung dessen Netzwerk und auch Computer er nutzt das Zertifikat geschickt. Unser Kunde schickt das Zertifikat mir. Es fehlen jegliche Anweisungen, was ich a) mit dem Zertifikat machen soll oder b) wie man testen kann dass es funktioniert. Absolut null Info. Frage ich dann bei dieser IT-Abteilung nach, die Ansprechpartner auch für unseren Kunden ist, dann wissen diese Leute von der IT wenig bis nichts zu dem Zertifikat zu sagen. Bisher habe ich in der URL eine IP-Adresse verwendet (was bei HTTP wunderbar funktioniert hat), heute erfahre ich, ich soll den vollen DNS-Namen verwenden.

Dann habe ich im OnValidateCertificate des TRestClient das Accepted auf True gesetzt, wie ich es im Netz gefunden hatte, dass man das machen soll.

Und schon lautete die Fehlermeldung nicht mehr:
REST-Anforderung fehlgeschlagen: Server Certificate not accepted

sondern:
REST-Anforderung fehlgeschlagen: Unspecified certificate from client

Aber es kommt noch doller. Im OnValidateCertificate habe ich mir mal alle zur Verfügung stehenden Infos des „const [Ref] Certificate: TCertificate“ ausgeben lassen. Schön war schon mal, da stand tatsächlich etwas, was mit dem Zertifikat zu tun hatte. Aber, aufgemerkt, da stand nicht die URL drin die ich verwenden sollte, sondern es war noch ein Zeichen anders (zusätzlich) in der URL. Als ich die URL dann so geschrieben habe, wie sie auch im Zertifikat hinterlegt ist, kam keine Fehlermeldung mehr bzgl. des Zertifikats!

Daten habe ich aber trotzdem keine Empfangen, Fehlermeldung:
REST-Anforderung fehlgeschlagen: Execution of request terminated with unknown error

Es wird so sein wie so oft. Diese Test-Schnittstelle ist bei der IT-Abteilung gar nicht scharf geschaltet. Ich warte noch auf Feedback.

Ach ja, mein erster Gedanke war auch, ich nehme einfach statt http:// dann

https://, aber das funktionierte nicht. Vermutlich alleine deshalb nicht, weil ich a) mit IP-Adresse werkelte und b) weil die URL auch noch falsch war.

Ich berichte, wenn es was Neues gibt. Gruß, Markus

**Codehunter**

Oh weh. Grundsätzlich müssen Zertifikat, IP-Adresse und Hostname zusammen passen. Am Ende wird das auf beiden Seiten irgendwie zusammengeschustert. Hauptsache es läuft. Könnte mir vorstellen, so ähnlich ist es zwischen BRAK und ATOS auch gelaufen beim beA. Sicherheit kommt dabei aber mit Sicherheit nicht heraus. Tu dir selbst einen Gefallen und lehn den Auftrag ab.

OT: Weisst warum ich die REST-Komponenten nicht mag und wieder auf Indy zurück gewechselt bin? Weil man

bei Indy per TLS-Intercept die Schlüssel abgreifen und dann per Wireshark den Protokollfluss analysieren kann. Dann sieht man nämlich auch Fehler bei der Aushandlung der Verschlüsselung, ob schon TLS 1.2 verwendet wird oder noch 1.1 oder 1.0. Von SSL mal gar nicht zu reden.

**Zwirbel**

Zitat von Codehunter:

Oh weh. Grundsätzlich müssen Zertifikat, IP-Adresse und Hostname zusammen passen. Am Ende wird das auf beiden Seiten irgendwie zusammengeschustert. Hauptsache es läuft. Könnte mir vorstellen, so ähnlich ist es zwischen BRAK und ATOS auch gelaufen beim beA. Sicherheit kommt dabei aber mit Sicherheit nicht heraus. Tu dir selbst einen Gefallen und lehn den Auftrag ab.

Das ist leider keine Option. Unsere Software läuft schon seit 3,5 Jahren beim Kunden. Unser Kunde bekommt nun vom IT-Dienstleister - der dem Kunden die Hardware und das Netzwerk zur Verfügung stellt - die Aufforderung zukünftig die Daten die der Kunde vom IT-Dienstleister bezieht, mit Zertifikat abzufragen.

So wie es aussieht kriege ich das mit dem Zertifikat und den REST-Komponenten nicht gebacken und muss wohl in den sauren Apfel beissen nur deswegen auf Indy umstellen.

**Codehunter**

Die REST-Komponenten basieren (bei Win32 und Win64) auf WinInet und "erben" sozusagen diverse Sicherheitseinstellungen aus der Abteilung Internet Explorer. Dort wäre auch der Ansatz, das Zertifikat zumindest testweise einzuspielen. Bevor jetzt alles auf Indy umgestrickt wird.

Ich wollte mit meinen Bedenken nur zum Ausdruck bringen, dass SSL/TLS ja eigentlich erfunden wurde um die Transportsicherheit zu erhöhen. So wie du das beschreibst, bestehen auf beiden Seiten viele Ungewissheiten über die Problematik. Daher befürchte ich, wird das Vorhaben nicht den gewünschten Erfolg bringen. Egal ob nun mit WinInet oder Indy. Möglich, dass es "irgendwann" "irgendwie" läuft. Nur ob das dann auch das Prädikat "gesicherte Verbindung" verdient, steht in den Sternen.

**Zwirbel**

Zitat von Codehunter:

Die REST-Komponenten basieren (bei Win32 und Win64) auf WinInet und "erben" sozusagen diverse Sicherheitseinstellungen aus der Abteilung Internet Explorer. Dort wäre auch der Ansatz, das Zertifikat zumindest testweise einzuspielen. Bevor jetzt alles auf Indy umgestrickt wird.

Das hatte ich evtl. nicht klar genug geschrieben. Das Zertifikat habe ich in meiner Testumgebung installiert. Einfach Doppelklick auf der .CER Datei und dann immer <Weiter>, zum Schluss kam auch eine Meldung, dass die Installation erfolgreich abgeschlossen wurde. Aber ich habe ja gar keine Ahnung, weil mir die IT-Abteilung die mir das Zertifikat geschickt hat, nicht sagen kann, wie ich das Zertifikat zu installieren habe, ob ich es auch am richtigen Platz abgelegt habe. Man kratzt sich jetzt evtl. etwas am Kopf und fragt sich, wieso können die die einem so ein Zertifikat schicken auch nicht sagen was man damit zu machen hat. Aber so ist es leider. Mir sagt man lediglich, dass sie mit der Verwendung der Zertifikate unter Windows kaum/keine Erfahrungen haben, sie arbeiten nur unter Linux.

Zitat von Codehunter:

Ich wollte mit meinen Bedenken nur zum Ausdruck bringen, dass SSL/TLS ja eigentlich erfunden wurde um die Transportsicherheit zu erhöhen. So wie du das beschreibst, bestehen auf beiden Seiten viele Ungewissheiten über die Problematik. Daher befürchte ich, wird das Vorhaben nicht den gewünschten Erfolg bringen. Egal ob nun mit WinInet oder Indy. Möglich, dass es "irgendwann" "irgendwie" läuft. Nur ob das dann auch das Prädikat "gesicherte Verbindung" verdient, steht in den Sternen.

Das sehe ich auch so. Die Sicherheit erhöht das Zertifikat um kein Jota. Denn die URL ist aus dem öffentlichen Internet eh nicht erreichbar.

Und die Daten die man von der Schnittstelle geliefert bekommt sind trotzdem alles andere als streng geheim, im Gegenteil, das sind Infos, die man auf anderem Weg, jederzeit als Privatmann abrufen kann. Ich möchte hier keine Namen und Institutionen nennen.

Es ist zum Haareraufen.

**Codehunter**

Zitat von Zwirbel:

Mir sagt man lediglich, dass sie mit der Verwendung der Zertifikate unter Windows kaum/keine Erfahrungen haben, sie arbeiten nur unter Linux.

Geil. Der Traum einer ganzen Generation von Nerds

Aber das gibts in den letzten Jahren immer öfter. Windows ist nicht mehr das Allheilmittel.

Zitat von Zwirbel:

Denn die URL ist aus dem öffentlichen Internet eh nicht erreichbar.

Naja, die Grenze zwischen öffentlichen und privaten Netzen sind weicher als man gemeinhin denkt. Ich kenne Unternehmen, die hohe Beträge in Sicherheit investiert und die Mitarbeiter das noch am Start-Tag mit einem einzigen Tethering-fähigen Handy ausgehebelt haben.

Ich würde dir raten, die Insider bei deinem Dienstanbieter zu einem Grillabend einzuladen. Es geht nix über Vitamin B um solche Probleme aus der Welt zu schaffen