TIdHTTPServer + TIdServerIOHandlerSSLOpenSSL Frage

[TomyN]

Hallo

Ich habe eine Anwendung, die einen internen Webserver für den Zugriff über das lokale Netzwerk zur Verfügung stellt.
Mithilfe von TIdHTTPServer + TIdServerIOHandlerSSLOpenSSL funktioniert das auch über SSL / https, zwar mit einer Beschwerde über das selbst signierte Zertifikat aber soweit okay.
Aktuell verwende ich die Zertifikatsdatei ( x.crt) und die Schlüsseldatei (x.key). Nun möchte ich aber die Schlüsseldatei eigentlich nicht mit ausliefern, da ja damit das Zertifikat 'universell verwendbar' wäre.
Gibt es denn eine Möglichkeit https/ssl zur realisieren ohne die Schlüsseldatei zur Verfügung zu stellen? Wo und wie müsste ich dann das Passwort, dass ich bei der Schlüssselerstellung verwendet habe, eintragen?

Grüße
Tomy

[mjustin]

Der Server benötigt m.W. immer den Private Key ("Schlüssel"), da er damit ja die Kommunikation verschlüsselt.

Wenn der nicht weitergegeben werden soll, muss für jede Installation ein neues Zertifikat erstellt werden.

[TomyN]

Hi,
Verstehe ich soweit.
Gibt es vielleicht eine Möglichkeit, dass ganze in eine verschlüsselte Datei o.ä. zu packen, die dann erst zur Laufzeit entschlüsselt wird, also sozusagen ein 'Kombifile', das die Infos enthält und mit einem Passwort verschlüsselt ist.

Tomy

[mezen]

Zu allererst: Ich bestätige dies mit 100% Gewissheit dass du immer zu dem Zertifikat auch den privaten Schlüssel benötigst. So funktioniert halt asymetrische Kryptographie.

Bezüglich der Datei "verstecken": Du wirst dort keine zufrieden stellende Antwort finden. Du wirst immer in der Situation enden, dass du etwas verschlüsselt da liegen hast, aber da dein Programm das entschlüsseln können muss, wirst du auch immer den Schlüssel dort liegen haben. Und an diesen wird man immer per Reverse Engineering dran kommen.

Wenn du aber mit der Einschränkung leben kannst, dass nicht mehr DU den privaten Schlüssel kennst, sondern nur noch dein Programm, würde ich empfehlen den Schlüssel und Zertifikat erst beim Benutzer, vllt im Setup Programm, generieren zu lassen.
Alternativ die faule und unkomfortable (und daher eher schlechte) Lösung: Überlass dem Benutzer ein Zertifikat mit privaten Schlüssel deinem Programm zu geben.

[TomyN]

Hi,

Das ist mir (inzwischen) auch klar, ansonsten hätte das ganze ja überhaupt keinen Sinn. Ich verwende jetzt ein pfx File und das Passwort in in der Software. Das Zertifikat ist 'Self-signed' und daher ist ein 'Verlust' auch nicht weiter schlimm. Da die Möglichkeit der Steuerung über einen Browser nur ein 'Zuckerl' ist, kann ich aktuell damit leben.
Das ganze läuft auch nur im lokalen Netz und bisher auch ganz ohne SSL/HTTPS, weil es keine 'kritischen' Daten sind. Allerdings verweigern manche Browser inzwischen die Zusammenarbeit über 'normales' http gänzlich, wohingegen man es mit https und self-signed Zertifikat noch zum laufen bringt, wenn man auch einige Warnungen akzeptieren muss.
Ich habe das pfx Zertifikat als Cert-File und als Key-File eingetragen. Wenn ich es zusätzlich als root-cert file eintrage, funktioniert es nicht, da er es nicht entschlüsseln kann. Aber es funktioniert auch ohne root-cert Eintrag.

Falls jemand noch eine Idee hat, wie man bei einer Software, die normalerweise lokal läuft, aber auch einen Webserver zur Remotesteuerung im Browserfenster zur Verfügung stellt, für einen problemlosen Aufruf auch mit 'modernen' Browsern sorgen kann, der würde mir eine große Freude machen.

Tomy

[Redeemer]

Zitat von TomyN:

Hi,

Das ist mir (inzwischen) auch klar, ansonsten hätte das ganze ja überhaupt keinen Sinn. Ich verwende jetzt ein pfx File und das Passwort in in der Software. Das Zertifikat ist 'Self-signed' und daher ist ein 'Verlust' auch nicht weiter schlimm. Da die Möglichkeit der Steuerung über einen Browser nur ein 'Zuckerl' ist, kann ich aktuell damit leben.
Das ganze läuft auch nur im lokalen Netz und bisher auch ganz ohne SSL/HTTPS, weil es keine 'kritischen' Daten sind. Allerdings verweigern manche Browser inzwischen die Zusammenarbeit über 'normales' http gänzlich

Das halte ich für ein Gerücht.