Stunnel mit zertifikat, wie geht das?

[amzd]

Hallo,
Weiß jemand, wie ich einen Stunnel benutzen kann.
Ich habe sles11 sp2 x64.
Darauf läuft ein Dealer Management System über http.
Eine neue Schnittstelle soll diesen LInux DMS-Server nun via https kontaktieren.

Jetzt dachte ich, ich könnte einen stunnel einrichten.
Kann ich damit dem Linux Server beibringen, dass er auf Port 444 (z.B.) via https von einer externen Schnittstelle angesprochen wird, dass der Stunnel das in http übersetzen soll und an Port 5550 dieses Servers (also an localhost) weiterleitet und alles was vom DMS vom localhost dann via http zurückkommt dann über den stunnel an den Anfragenden gesandt wird?

So was ich gelesen habe muss der stunnel auf beiden Seiten installiert werden, aber das will ich gar nicht, da die Anfrage von der Schnittstelle ohnehin in https kommt.
Also muss nur in https angenommen werden, umgewandelt werden in http und alles was das DMs als Antort senden möchte dann wieder über den Stunnel raus gesendet werden.
Geht das oder gibt es eine andere Möglichkeit?

Danke und gruß
Andreas

[L00NIX]

Dafür ist stunnel da:
Einen nicht verschlüsselbaren Dienst (Protokoll) mit einer TLS-verschlüsselten Schicht zu versehen und das Protokoll darin an den dahinter liegenden Dienst weiterzuleiten. Dazu muss stunnel nur auf der Server-Seite installiert werden, dieser wird dann vom Client (Browser oder was das Ding sonst anspricht) via HTTPS kontaktiert.

Grundsätzlich wäre es besser, HTTPS direkt im Webserver zu konfigurieren. Würde mich wundern, wenn der Webserver des DMS das nicht kann (Apache?).

Gruß
L00NIX

[mkahle]

In der Annahme, dass Du ein SSL-Zertifikat bereits hast, kannst Du folgende stunnel Konfiguration verwenden:



chroot = /var/stunnel/
cert = /pfad/zum/zertifikat.crt
key = /pfad/zum/privaten/schlüssel.key
pid = /stunnel-imaps.pid
setuid = nobody
setgid = nogroup
CApath = /pfad/wo/die/root/zertifkate/liegen
debug = 0
output = /var/log/stunnel-444.log
client = no
connect = 127.0.0.1:5550


Die Pfade für cert, key, pid und CApath sind relativ zu chroot zu verstehen, d.h. das Zertifikat muss dann beispielsweise und /var/stunnel/pfad/zum/zertifikat.crt abgelegt werden.

stunnel kannst Du beispielswseise über xinetd started lassen, in dem Du folgende Konfiguration zum xinetd hinzufügst:


service tcp444
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = root
server = /pfad/zu/stunnel
server_args = /pfad/zur/obigen/konfigurationsdatei
instances = 25
}


Damit das ganze funktioniert muss auch noch der folgende Eintrag in /etc/services stehen:


tcp444 444/tcp


HTH

[TheDarkRose]

Dazu sollte ein Apache Reverse Proxy auch reichen.

[amzd]

Hallo Loonix, hallo mkahle,

erst mal Danke fürs Draufschauen.
Also der Webserver kann kein https, weil es der Webserver vom DMS (Dealer Management System) ist und kein Apache.
Deswegen kam das Thema ja überhaupt erst auf.

Die Firma hat eine eigene Zertifikatsstelle für interne Zertifikate. Dort habe ich das Zertifikat beantragt (das CSR hingesandt) und dann mein Zertifikat bekommen - das allerdings nicht mal auf .crt endetete. Wahrscheinlich muss ich es in eine Datei packen und der dann einen Namen geben auf .crt (?)
Ich nehme an, dass das so angelegt ist, dass die root-Zertifikate irgendwo anders liegen und vermerkt ist, dass alle internen Rechner nun zugreifen dürfen.
Jedenfalls habe ich keinerlei root-Zertifikate - woher auch?
D.h. den Punkt, dass ich auf dem lokalen Server eine Stelle definieren soll, wo root-Zertifikate liegen,(die ich irgendwie hinterlege) verstehe ich noch nicht so richtig, oder hat sich das mit der Beantragung des Zertifikats an zentraler Stelle erledigt?

Bin jetzt etwas ratlos, was ich bei CAPath einzutragen habe. Könnt Ihr mir da noch mal aushelfen?
Wo hättet ihr denn root-Zertifikate her bekommen? Werden die bei self-signed certificates gleich mit erzeugt?

Zum "Hinzufügen der Konfiguration zum inetd": welche config-Datei ist das genau, oder geht das im yast?
Danke und viele Grüße
Andreas

[TheDarkRose]

Darum sagte ich ja. Nimm einen Apache und richte einen Revers-Proxy damit ein. Zertifikate enden meist auch auf .pem und das ist ok.

[L00NIX]

Hallo Andreas,



Bin jetzt etwas ratlos, was ich bei CAPath einzutragen habe. Könnt Ihr mir da noch mal aushelfen?
Wo hättet ihr denn root-Zertifikate her bekommen? Werden die bei self-signed certificates gleich mit erzeugt?


Ein bisschen theoretisches Verständnis zu TLS-Verschlüsselung deinerseits wäre schon hilfreich.

Self-Signed (selbst signierte) Zertifikate sind, wie der Name schon sagt, von sich (quasi als Zertifizierungsstelle/ CA) selbst signiert. Da das jeder machen kann, sind diese Dinger nicht vertrauenswürdig.

"Gute" Zertifikate sind von den Zertifizierungsstellen signiert, die in den gängigen Browsern und Betriebsystemen mitgeliefert werden, z.B. Geotrust, Verisign, etc. Auch bei denen gibt es aber Unterschiede, was den Typ des Zertifikats angeht, und damit verbunden den Preis für den gewünschten Zertifikatstyp. …Kommerzielle Anwendungen wie Online-Shops kommen um so ein "gutes" Zertifikat nicht herum!

Für Tests oder Anwendungen, wo man selbst Hand auf alle zugreifenden Clients hat (z.B. in einer Windows-Domäne), kann man auch eine interne CA aufsetzen und von dieser die Zertifikate signieren lassen. Diese CA muss dann auf jedem zugreifenden Client als "Vertrauenswürdige Stammzertifizierungsstelle" (Windows-spezifische Bezeichnung) eingetragen sein. Bei Linux-Systemen oder Browsern (z.B. Firefox) gibt es auch Stellen, an denen das Zertifikat der CA hinterlegt werden muss. Danach gelten alle von dieser CA signierten Zertifikate automatisch als vertrauenswürdig.

Die Aktualisierung der "offiziellen" CAs übernimmt normalerweise die Distribution oder die Browser-Update-Funktion. Man vertraut hier darauf, dass kein "Mist" mit einfließt, also CAs, die völlig ungeprüft und willkürlich jedem Zertifikate ausstellen. Soll schonmal vorgekommen sein... ;)

Für deinen Anwendungsfall heißt das:

Nimm für's Testen ein selbst-signiertes Zertifikat und klicke die Warnmeldung im Browser (bewusst) weg. Es funktioniert trotzdem.
Wenn der stunnel oder Apache Reverse Proxy funktioniert, kannst du ein "gutes" Zertifikat besorgen und einbauen.

Gruß
L00NIX

[L00NIX]

Die Firma hat eine eigene Zertifikatsstelle für interne Zertifikate. Dort habe ich das Zertifikat beantragt (das CSR hingesandt) und dann mein Zertifikat bekommen - das allerdings nicht mal auf .crt endetete. Wahrscheinlich muss ich es in eine Datei packen und der dann einen Namen geben auf .crt (?)


Der Inhalt der Datei ist entscheidend, nicht die Endung. Mit OpenSSL kann man aber sämtliche Formate hin- und herkonvertieren.

Gruß
L00NIX

[amzd]

Hi,

OK, ich hatte caPath leer gelassen, weil ich ein "gutes" Zertifikat besorgt hatte und sofort verwendet hatte.
Soweit schien alles zu funktionieren, nur wenn ich stunnel im detached daemon mode laufen lasse mit
stunnel &
dann beendet er sich kurz drauf und läuft nicht durch.
Das könnte andeuten, dass das Zertifikat nicht funktioniert, aber vielleicht ist es auch etwas anderes.
jedenfalls bekomme ich von außen: connection refused. D.h. auf dem Port hört keiner.
Wenn ich netstat -nlp aufrufe wird 444 nicht abgehört.
Aber nirgends sagt er etwas.
Habe debug=7 gesetzt.
Dennoch keine log-Datei in /var/log
Hatte als Logdatei stunnel-444.log spezifiziert, die aber gar nicht erst angelegt wurde.
Was kann ich jetzt machen?
Danke und Gruß