freeX: UUCP über SSL über TCP

Mails lesen und schreiben

Wer einen Server im Internet betreibt, der Mails annimmt und verwaltet, benötigt häufig auch eine Möglichkeit, Mails sicher einzuliefern und abzuholen, manchmal auch von beliebigen Orten im Internet. UUCP ist prädestiniert für Store-and-Forward und kann zudem leicht mit einem SSL-Tunnel betrieben werden.

1. Ein eigener Mail-Server 2. Store and Forward 3. UUCP via TCP 4. Mail-Server auf UUCP umstellen 5. UUCP-Server 6. UUCP über SSL 7. Offizieller SSL-UUCP-Port 8. SSL-Zertifikate 9. Server-Zertifikat erzeugen 10. Diffie-Hellman Parameter 11. Zertifikat anzeigen 12. SSL-Tunnel auf dem Server empfangen 13. UUCP über SSL-Tunnel 14. Resources

Im Internet Mails lesen und verschicken kann auf verschiedene Arten erfolgen. Die einfachste Konfiguration beinhaltet ein Programm wie kMail oder Thunderbird, das Mails über IMAP oder POP3 abholt und lokal darstellt. Ausgehende Mail wird von diesen Programmen direkt per SMTP an den Mail-Server des Providers geschickt.

Etwas komplizierter ist die Konfiguration eines eigenen lokalen Mail-Systems, das ausgehende Mails an den Mail-Server des Providers schickt, lokale Mails jedoch weiterhin lokal ausliefert und eingehende vielleicht sogar noch durch Spam- und Virenfilter schickt. In einem solchen System wird z.B. Mutt als Mail-Programm verwendet, denn Mutt benötigt ein lokales Sendmail-Programm zum Verschicken von Mails und bietet viel (textbasierten) Komfort im Umgang mit Mails.

Wenn der eigene Rechner nur über dynamische Adressen im Internet erreichbar ist bzw. sich ins Internet einwählt, sollte er keine Mails direkt an die Empfänger ausliefern. Stattdessen sollten ausgehende Mails höchstens an den Mail-Server des Providers geschickt werden. Dieser hat eine offizielle Adresse und liefert sie aus.

Viele Mail-Server akzeptieren aufgrund des hohen Spam-Aufkommens keine Mails mehr von sogenannten Dialup-Adressen. Das ist ein kleiner Schutz gegen Spam von Zombie-Rechnern, ferngesteuerten Rechnern, die zum Verschicken von Spam mißbraucht werden. Daher sollte in einem solchen Fall unbedingt der Mail-Server des Providers verwendet werden.

Einen Mail-Server hinter einer dynamischen Adresse zu betreiben ist ebenfalls gewagt. Selbst wenn die IP-Nummer mit einem DynDNS-Dienst zu einem einheitlichen Namen wird, kann nicht gewährleistet werden, daß kein anderer einwählender Rechner unter der eingetragenen IP-Adresse erreichbar ist, wenn der eigene Rechner gerade nicht mit dem Internet verbunden ist. Mails könnten somit an den falschen Rechner ausgeliefert werden.

Um Mails von einem IMAP- oder POP3-Server abzuholen und lokal auszuliefern, wird das Programm »fetchmail« verwendet. Anschließend werden sie von einem beliebigen Mail-Programm, das auf eine lokale Mailbox zugreifen kann. Zum Suchen in Mailboxen wird neben Mutt selbst auch »grepmail« verwendet.

Wer einen Shell-Account mit SSH-Zugang auf dem Mail-Server besitzt, sollte die Mails allerdings nicht direkt über POP3 oder IMAP abholen, sondern jeweils einen SSH-Tunnel aufbauen. Dann wird das zum Abholen benötigte Paßwort nicht mehr im Klartext im Internet übertragen und man bietet Angreifern weniger Möglichkeiten.

Ein eigener Mail-Server

Wer jedoch einen eigenen Server bzw. einen virtuellen Server im Internet betreibt, möchte diesen vielleicht auch als eigenen Mail-Server verwenden. Der Vorteil darin wäre, mehr Kontrolle über den Mailverkehr zu haben, bedeutet jedoch auch mehr Verantwortung zu übernehmen und den Rechner vernünftig zu konfigurieren.

Der Rechner soll Mails annehmen und an den eigenen Rechner Zuhause, im Büro oder unterwegs weiterleiten, sowie Mails von dort annehmen und an Empfänger im Internet ausliefern. Auf die eigentliche Konfiguration des Mail-Servers soll in diesem Artikel jedoch nicht näher eingegangen werden. Einen Mail-Server zu betreiben erfordert etwas Erfahrung und setzt Wissen über SMTP und Mail-Verkehr voraus.

Sowohl eingehende als auch ausgehende Mails sollen dabei durch den Mail-Server transportiert werden. Eigene Mails von einer dynamischen IP-Adresse sollen akzeptiert und ausgeliefert werden. Allerdings dürfen Mails an nicht-lokale Empfänger nicht von beliebigen Rechnern angenommen werden, da der Rechner sonst als offenes Spam-Relay mißbraucht werden kann. Dieses sollte heutzutage die Voreinstellung bei der Konfiguration sein.

Store and Forward

Eine Möglichkeit zur Realisierung besteht in der Autorisierung einer Verbindung, bevor Mails verschickt werden. Diese Technik wird SMTP-AUTH genannt. Eine andere Möglichkeit besteht darin, ebenfalls auf POP und IMAP zu verzichten und komplett auf eine Store-and-Forward genannte Technik umzusteigen.

In den Anfangszeiten der elektronischen Kommunikation, als nur sehr wenige Computer eine dauerhafte Verbindung zu anderen besaßen, war diese Methode usus. Damals hat fast jeder Rechner Mails zwischengespeichert und bei Bedarf gezielt seine Nachbarn weitergegeben. Die Verbindungen zu den Nachbarn wurden weltweit in speziellen Routing-Tabellen vermerkt. Abhängig davon, wie oft die einzelnen Computer eine Verbindung zum Nachbarn aufgebaut haben, wurden Mails mehr oder weniger schnell zum Empfänger transportiert.

Auf diese Weise funktionierte nicht nur das frühe Internet auf Basis von Unix-to-Unix-CoPy (UUCP), sondern auch das Fidonetz, Maus-Net, Z-Netz und weitere Mailbox-Netze. Zusammengefaßt wurden sie unter dem Oberbegriff Usenet, das alle Mail bzw. News empfangenden Computer einschließt.

Auch wenn UUCP auf den ersten Blick vielleicht antiquiert erscheinen mag, ist es doch die prädestinierte Methode, nicht permanent ans Internet angebundene Rechner mit Mails (und Usenet News) zu versorgen. Darüberhinaus ist das Protokoll etabliert und die Software ausgereift, denn sie wird bereits seit über 20 Jahren eingesetzt.

UUCP kopiert im Prinzip nur Dateien von einem Rechner auf einen anderen, auf dem sie verarbeitet werden. Teilweise werden die Dateien gleich für das Verschicken an einen weiteren Computer vorgesehen, meistens werden sie jedoch lokal verarbeitet.

Früher wurde UUCP häufig über serielle Schnittstellen und Modems eingesetzt, um auf dem UUCP-Server eingewählt News-Artikel und Mails auszutauschen. Seit permanente Verbindungen und Internetanschlüsse auch für Privatpersonen erschwinglich sind, ist UUCP bei vielen in Vergessenheit geraten.

Einige Hartgesottene, die früher mit UUCP gearbeitet haben, setzen es jedoch weiterhin ein, allerdings inzwischen über das Internet-Protokoll TCP und nicht mehr via Modem. Dabei ist die Technik die gleiche geblieben, lediglich das Übertragungsmedium hat sich geändert.

UUCP via TCP

Die Konfiguration von UUCP über TCP unterscheidet sich fast nicht von der über ein Modem, das an einer seriellen Schnittstelle angeschlossen ist, und wird zudem in der Dokumentation von UUCP ausführlich beschrieben. An dieser Stelle soll daher nur kurz auf die wichtigsten Einstellungen eingegangen werden.

Abbildung 1: Mails per Store-and-Forward mit Server

Die Konfiguration von Taylor-UUCP, dem freien UUCP-Paket, das den meisten freien Unix-Derivaten beiliegt, befindet sich z.B. im Verzeichnis »/etc/uucp«. Die für die Verbindung zu einem benachbarten Rechner benötigten Konfigurationsdateien sind »port«, »config« und »call«. In der Datei »port« steht der folgende Eintrag, mit dem die Verbindungsart »tcp« für Verbindungen über TCP definiert wird:

   port tcp
   type tcp

In der Datei »config« werden die benachbarten Rechner indirekt über sogenannte »sys«-Dateien konfiguriert, die mit dem Befehl »sysfile« eingebunden werden. Die wichtigsten Einstellungen pro System sind die folgenden:

   system server
   time Any
   port tcp
   address server.doma.in

Wenn dieses in der Datei »sys.server« steht, wird sie mit der Zeile

   sysfile /etc/uucp/sys.server

eingebunden. Als Port wird hier bereits »tcp« angegeben, da nicht mehr über ein Modem gearbeitet werden soll. Für eine Modemverbindung würde man als Port einen der in der Datei »port« beschriebenen seriellen Ports angeben sowie eine Telefonnummer. Das Schlüsselwort »port« stammt noch aus der Zeit, in der nur Modemverbindungen verwendet wurden. Es wurde für TCP-Verbindungen lediglich wiederverwendet.

In der Datei »call« wird schließlich das Paßwort für den entfernten UUCP-Server zusammen mit dem verwendeten Login eingetragen:

   server uclient passwort

Für eine derartige Konfiguration wird automatisch der TCP-Port »uucp« verwendet, so wie er in der Datei »/etc/services« konfiguriert ist. Dort sollte normalerweise der Port 540 für UUCP-Verbindungen eingetragen sein. Mit dieser Konfiguration wird die Verbindung zum Server mit dem Befehl »uucico -S server« aufgebaut. Dieser Befehl wird mit der gewünschten Häufigkeit in der Crontab des lokalen Benutzers »uucp« eingetragen.

Mail-Server auf UUCP umstellen

Damit der lokale Mail-Server Mails an externe Empfänger mittels UUCP verschickt, wird als sogenannter Smarthost der entfernte UUCP-Server eingetragen und als Transportmedium »uucp« gewählt. Wie das im einzelnen erfolgt, hängt stark von der verwendeten Software ab. Für Postfix zum Beispiel werden dazu die folgenden Zeilen in der Datei »main.cf« benötigt:

   relayhost = server
   default_transport = uucp

Wer Sendmail einsetzt, benötigt die folgenden Zeilen in der Datei »sendmail.mc«, aus der die eigentliche Konfiguration erstellt wird:

  MAILER(uucp)dnl
  define(`SMART_HOST', uucp-dom:server)

Für Exim sieht die Konfiguration etwas komplexer aus. Zuerst wird ein spezieller Transport für UUCP im Abschnitt für Transports in »/etc/exim/exim.conf« hinzugefügt:

   uucp:
     driver = pipe
     user = nobody
     command = "/usr/bin/uux -r - $host!rmail ${local_part}"
     return_fail_output = true

Anschließend wird der Smarthost konfiguriert. Hilfreich ist es, wenn bereits eine Konfiguration für ein System mit Smarthost vorliegt, die lediglich erweitert wird. Im Abschnitt für Router wird dazu der folgende Eintrag geschrieben:

   smarthost:
     driver = domainlist
     transport = uucp
     route_list = "* server"

Anschließend liefert auch Exim Mails an nicht-lokale Adressen über UUCP aus. Überprüfen läßt sich dieses Verhalten bei allen Sendmail-Varianten mit einer Testmail, die an eine Adresse geschickt wird, die über UUCP geroutet werden müßte.

Mit dem Befehl »uustat -s server« werden die Namen der Datenpakete im Ausgangskorb für den UUCP-Rechner »server« angezeigt. Das Programm »uustat« bietet vielfältige Möglichkeiten, Daten im Spoolverzeichnis anzuzeigen und sogar mit »-k« zu löschen.

UUCP-Server

Auf dem als Server fungierenden Rechner wird UUCP ähnlich konfiguriert wie auf dem Client, allerdings wird dort das Paßwort nicht in der Datei »call« sondern in der Datei »passwd« eingetragen. Diese wird gelesen, wenn sich ein Rechner versucht, per UUCP einzuloggen. Dazu wird das folgende Format verwendet:

   uclient  passwort

Die allgemeine Konfiguration von UUCP sah vor Jahren vor, daß mit einem »u« beginnende Logins auf einer seriellen Schnittstelle an UUCP weitergegeben werden. Diese Sonderregelung muß für TCP-Verbindungen nicht mehr getroffen werden, denn über den UUCP-Port läuft vom Konzept her ausschließlich UUCP. Als Konvention wurde jedoch häufig beibehalten, daß sich ein Client mit »uclient« auf dem Server einloggt.

Damit sich ein Client per TCP auf dem UUCP-Server einloggen kann wird der Port mit dem Programm »uucico« verbunden. Wann immer eine Verbindung zum Server über den Port UUCP geöffnet wird, soll das Programm »uucico« gestartet werden und nach einem Paßwort fragen, die Authentifizierung übernehmen und bei Erfolg Daten über ein UUCP-Protokoll empfangen und verschicken.

Die Verbindung wird mit den Internet-Superservern »inetd« bzw. »xinetd« angenommen. Wer »inetd« einsetzt, konfiguriert diese Zuordnung in der Datei »/etc/inetd.conf« mit der folgenden Zeile ohne Zeilenumbrüche:

   uucp  stream  tcp     nowait  root    /usr/sbin/tcpd /usr/sbin/uucico -l

Für »xinetd« wird der Port in »/etc/xinetd.conf« bzw. bei moderneren Versionen in einer Datei im Verzeichnis »/etc/xinetd.d« folgendermaßen konfiguriert:

   service uucp
   {
        socket_type = stream
        protocol    = tcp
        server      = /usr/sbin/uucico
        server_args = -l
   }

UUCP über SSL

Wenn Mails nun tatsächlich per UUCP verschickt und empfangen werden, wird es Zeit, die Verbindung zu verschlüsseln. Bisher wird insbesondere das Paßwort zum Einloggen nicht unverschlüsselt übertragen. Ein Angreifer im Internet könnte es aus dem Datenverkehr mitlesen und die Mails abfangen.

Prinzipiell gibt es zwei Möglichkeiten, dieses zu erreichen. Zum einen kann die Verbindung zwischen Client und Server durch einen SSH-Tunnel gelegt werden, wenn gleichzeitig ein Shell-Account auf dem UUCP-Server existiert.

In diesem Fall wird vor dem eigentlichen Verbindungsaufbau, eine SSH-Verbindung zum Server erstellt, durch die die eine TCP-Verbindung zum UUCP-Port auf dem Server getunnelt wird. Als lokaler Port wird dazu der UUCP-Port (der ggf. auf einen nicht-privilegierten Port verschoben wird) verwendet, und als UUCP-Server »localhost«.

Wenn auf dem UUCP-Server kein Shell-Account verwendet werden kann, bietet es sich an, einen SSL-Tunnel mit dem Programm »stunnel« zu legen und darüber den UUCP-Verkehr abzuwickeln. Auch bei dieser Variante wird vor dem eigentlichen Verbindungsaufbau der verschlüsselnde Tunnel angelegt.

Das Programm »stunnel« ist dafür gedacht, beliebige Netzwerkdienste SSL-fähig anzubieten. Dabei wird auf beiden Seiten der Verbindung die Standardeingabe passend umgebogen. Besonders einfach ist die Einrichtung, wenn der Client auch eine Verbindung über die Standardeingabe unterstützt. Dann müssen keine TCP-Ports umgebogen werden, was immer auch unerwünschte Seiteneffekte haben kann.

Das ist bei Taylor UUCP erfreulicherweise der Fall. Dazu wird in der Datei »ports« ein neuer Port »stdin« eingeführt,

   port stdin
   type stdin

der anschließend in »sys.server« anstelle des bisherigen angegeben wird:

   port stdin

Offizieller SSL-UUCP-Port

Für die Abwicklung von UUCP über eine SSL-Verbindung wurde bei der "Internet Corporation for Assigned Names and Numbers" (IANA) der offizielle Port 4031 reserviert. Dieser wird auf dem Client und dem Server in »/etc/services« eingetragen, wenn die Zuweisung dort noch nicht enthalten ist:

   suucp    4031/tcp    # UUCP over SSL

In der weiteren Konfiguration wird der symbolische Name »suucp« für diesen Port angegeben und nicht mehr der numerische Port.

SSL-Zertifikate

Beim Aufbau einer SSL-Verbindung präsentiert der SSL-Server ein digitales Zertifikat, das bestätigen soll, daß der Rechner auch der ist, der er vorgibt zu sein. Der anrufende Client kann das Zertifikat mit einem bereits gespeicherten vergleichen und die Verbindung ablehnen, wenn beide nicht übereinstimmen. Damit wird versehentliches Einloggen auf dem falschen Rechner verhindert. Vielen dürfte dieses Verhalten von SSH bekannt sein.

Das Zertifikat bestätigt die Echtheit eines privaten Schlüssels in Verbindung mit dem angegebenen Rechnernamen und wird üblicherweise von einer Zertifizierungsstelle signiert. Es kann jedoch auch ein selbstsigniertes Zertifikat verwendet werden.

Jeder Stunnel-Server lädt beim Programmstart einen privaten Schlüssel, der für die weiteren Operationen benötigt wird. Aus welcher Datei dieser gelesen wird, geht aus der Ausgabe von »stunnel -V« hervor. Wenn mehrere SSL-Dienste angeboten werden, ist es sinnvoll, die Datei jeweils mittels »-p datei« anzugeben, um für die verschiedenen Dienste unterschiedliche Schlüssel unabhängig voneinander zu verwenden.

Server-Zertifikat erzeugen

Als nächstes werden daher ein privater Schlüssel sowie ein SSL-Zertifikat für den UUCP-Server angelegt. Wenn der Server bereits vollständig eingerichtet ist und nur der Client konfiguriert werden muß, ist dieser Schritt natürlich nicht erforderlich.

Wenn der Client überprüfen soll, daß die Verbindung auch zum richtigen Server aufgebaut wird, kopiert man das Zertifikat ohne den zugehörigen privaten Schlüssel in ein spezielles Verzeichnis auf dem Client-Rechner. Dort wird »stunnel« dieses beim Aufbau der Verbindung anhand eines Hashwerts suchen.

Der SSL-Schlüssel wird mit dem Programm »openssl« aus dem gleichnamigen Paket generiert. Dabei wird gleichzeitig ein selbstsigniertes Zertifikat erstellt, das später durch ein externes ersetzt werden kann. Zusammen werden sei mit dem folgenden Befehl generiert:

   openssl req -new -x509 -days 365 -nodes -keyout suucp.pem -out suucp.pem

Mit dieser Befehlszeile wird die Gültigkeit des Zertifikats auf ein Jahr begrenzt. Voreingestellt sind nur 30 Tage, was für diese Anwendung relativ kurz ist. So muß allerdings daran gedacht werden, das Zertifikat in einem Jahr, ggf. samt Schlüssel, zu erneuern. Es ist durchaus möglich, eine höhere Gültigkeitsdauer anzugeben.

In diesem Fall werden der Schlüssel und das Zertifikat in der gleichen Datei gespeichert. Ein möglicher Ort für SSL-Schlüssel auf dem Server ist das Verzeichnis »/etc/ssl/certs«. Die Datei sollte zusätzlich mit »chmod 600 suucp.pem« vor zu neugierigen Blicken geschützt werden. Sonst könnte der private Schlüssel von einem böswilligen lokalen Anwender auf einen anderen Rechner kopiert werden und dort eine falsche Identität vorgaukeln.

Diffie-Hellman Parameter

Neue Versionen von stunnel erwarten in der gleichen Datei, in der das Zertifikat und der Schlüssel gespeichert werden, die Initialisierung für den Algorithmus von Diffie-Hellman (DH). Die bereits erzeugte Datei wird daher um die DH-Parameter ergänzt.

Die folgende Befehlszeile verwendet zufällige Zeichen und erzeugt via »openssl« mit einem Zufallsalgorithmus die Parameter, die an die oben generierte Datei angehängt werden.

   dd if=/dev/urandom count=2 | openssl dhparam -rand - 512 >> suucp.pem

Es ist sehr wichtig, daß die Dateiberechtigungen für das Zertifikat auf dem Server 0600 entsprechen, andererseits wird stunnel/openssl die Verbindung auf der Client-Seite mit einer irrsinnigen Fehlermeldung (SSL3_GET_RECORD:wrong version number) beenden.

Zertifikat anzeigen

Sowohl der Schlüssel als auch das Zertifikat werden in einer Textdatei gespeichert, allerdings in einem binären Block, der für Menschen schlecht zu lesen ist. Um sich die Details des Zertifikats anzeigen zu lassen wird daher erneut das Programm »openssl« benötigt. Mit folgendem Befehl werden alle wichtigen Informationen angezeigt.

   openssl x509 -text -subject -dates -fingerprint -noout -in suucp.pem

Die Zertifikate sucht »stunnel« beim Verbindungsaufbau ebenfalls im Verzeichnis »/etc/ssl/certs«, was jedoch mit dem Parameter »-a« geändert werden kann. Der Dateiname des jeweiligen Zertifikats entspricht dabei einem aus dem Zertifikat berechneten Hashwert. Es ist sinnvoll, der Datei mit dem Zertifikat zum besseren Verständnis einen sprechenden Namen zu geben, z.B. »2005-suucp.pem«, und anschließend einen symbolischen Link für den Hashnamen anzulegen. Der Hashwert wird ebenfalls mit »openssl« berechnet:

   openssl x509 -hash -noout -in suucp.pem

Als Suffix wird ».0« erwartet, so daß der Name des Links z.B. »a49283f5.0« lautet.

SSL-Tunnel auf dem Server empfangen

Als nächstes wird der UUCP-Server so eingerichtet, daß auf dem »suucp«-Port auch ein Programm horcht, die Verbindung annimmt und an den UUCP-Port bzw. an das Zielprogramm weiterleitet. Auf dem Server nimmt »stunnel« die Verbindung an, präsentiert das vorher erstellte Zertifikat und leitet die Verbindung unverschlüsselt an den bereits konfigurierten UUCP-Zugang über TCP weiter.

Daher sollte der eigentliche Dienst auch auf dem gleichen Rechner laufen. Sonst würde wieder ein Teil der Verbindung unverschlüsselt über ein potentiell unsicheres Netzwerk übertragen.

Die Weiterleitung wird mit dem Parameter »-r localhost:uucp« konfiguriert. Das Programm verbindet sich dann seinerseits mit dem Rechner »localhost« über den Port »uucp«. Dort wartet schon das weiter oben bereits konfigurierte Programm »uucico« auf die eingehende Verbindung. Für den »xinetd« wird die folgende Konfiguration für SSL-UUCP hinzugefügt:

   service suucp
   {
        socket_type = stream
        protocol    = tcp
        server      = /usr/sbin/stunnel
        server_args = -p /etc/ssl/certs/suucp.pem -r localhost:uucp
   }

Die Konfiguration dieses Ports für den BSD Internet Superserver »inetd« erfolgt analog.

UUCP über SSL-Tunnel

Der letzte Schritt betrifft den Aufbau der UUCP-Verbindung. Diese wird nicht mehr direkt über »uucico -S server« initiiert, sondern von nun an über das Programm »stunnel«. Der bisherige Eintrag in der Crontab wird daher durch einen neuen ersetzt, in dem der SSL-Tunnel aufgebaut und anschließend mit »uucico« verbunden wird.

Der Aufruf von »stunnel« sieht dann wie folgt aus:

   /usr/sbin/stunnel -c -r server.doma.in:suucp -v 3 -l uucico -- uucico -S server -D

Dieser Befehl wird als »root« ausgeführt bzw. in eine Crontab von »root« geschrieben. Der Parameter »-c« schaltet dabei das Programm »stunnel« in den Client-Modus um, so daß ein lokales Programm mit der aufgebauten Verbindung verbunden werden kann. Dieses wird mit dem Parameter »-l« angegeben. Zusätzlich dazu werden nach dem trennenden doppelten Bindestrich »--« der vollständige Programmaufruf angegeben.

Normalerweise startet »uucico« ein neues Programm, das im Hintergrund ausgeführt wird. Dieses Verhalten ist jedoch wenig hilfreich, wenn »uucico« die Standardeingabe vom aufrufenden Prozeß übernehmen und verwenden soll. Daher wird es mit dem Parameter »-D« daran gehindert, sich vom Terminal zu lösen.

Mit dem Parameter »-v« von »stunnel« wird eingestellt, wie Zertifikate zu behandeln sind. In der Voreinstellung wird keine Überprüfung der präsentierten Zertifikate durchgeführt. Mit »-v 3« wird jedoch eingerichtet, daß »stunnel« das vom Server angebotene SSL-Zertifikat gegen die lokal vorliegenden prüft. Wenn kein spezielles Verzeichnis mit »-a verzeichnis« spezifiziert wurde, sucht »stunnel« den Hashnamen des präsentierten Zertifikats im voreingestellten Verzeichnis. Das ist wahrscheinlich »/etc/ssl/certs«, was mit »stunnel -V« leicht überprüft wird.

Resources

• Stunnel FAQ: Using Certificates with Stunnel
• SSL Certificates HOWTO
• UUCP over SSL HOWTO, Harald Welte
• Secure Shell für Profis, Martin Schulze, freeX 5/05, S. 61ff

Quelle: freeX 1/06