Zertifikat nutzen

[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.