sslexplorer ansprechen (Zertifikat)

Moin, Ich habe einen Server auf dem der ssl-explorer läuft. Soweit gut. Über das Intranet und von lokal (aus dem eigenem Netzt) übers Internet (dyndns) kann ich Ihn ansprechen. Vom externen Netz aus nicht.

Ich rufe von lokal "https://....dyndns...." auf und muss einmal das unsichere Zertifikat bestätigen und gut ist, ich rufe dito von außerhalb, komme ebenfalls zur Aufforderung, bestätige diese und nichts passiert. Das der Router richtig konfiguriert ist, glaube ich daran zu erkennen das er mich ja zur Aufforderung (und somit zur Startseite) führt und zum anderen das "http://....dyndns...." mich zur Startseite einen weiteren Servers (Intranet Port 80) bringt.

Das Zertifikat das ich verwende ist das ssl-explorer Standard, auf "localhost" ausgestellte, und ich glaube das es daran liegt.
Ich habe mir daher beim ChaosComputerClub ein kostenloses besorgt. Einfach runterladen (cacert.pem) und importieren.
Das führt aber zu Fehler und nachdem ich es mit jedem möglichen Importpunkt probiert habe zum Absturz der Anwendung. Und zwar so das nichts mehr (meinem Wissensstand entsprechend) ging.

Jetzt bin ich mit meinem Latein am ende. Und ein Howto für "korrektes importieren eine korrekten (kostenfreien) Zertifikates um genau Dein Problem zu lösen" finde ich leider nicht. Meine Hoffnung ist, das es jemand gibt mit ähnlicher Erfahrung aber bereits einem Schritt weiter

Hi roemi,

ich kenne mich zwar bei deiner Konfiguration und auch mit deinem sslexplorer nicht aus (muss ich mir mal installieren ...), ich bin "nur" jemand, der berufsmäßig in einem Trustcenter Zertifikate produziert ... .

Das wichtigste bei der Nutzung von x.509-Zertifikaten ist, dass hier wirklich alles stimmen mus. Damit meine ich, dass zum einen der im Zertifikat eingetragene Name auch wirklich der Name des Servers ist (also ...dyndns ...) und vor allem, dass eine funktionierende Vertrauenskette besteht. Also angefangen beim vertrauenswürdigen Herausgeber bis hin zum Server- oder Clientzertifikat, welches das in den Herausgeber gesetzte Vertrauen von diesem erbt.
Während die etablierten Trustcenter von den meisten Herstellern der Browser, Mailprogramme und auch Betriebssysteme "von Hause aus" als vertrauenswürdig bewertet und somit auch gleich eingetragen werden, ist das bei den Herausgebern der so genannten "Kostnix-Zertifikate" nicht der Fall. Und das ist auch gut und richtig so, denn im Gegensatz zu den von etablierten Herausgebern hergestellter Zertifikate erfolgt bei den Kostnix keinerlei Identitätsfeststellung der Antragsteller. Und damit fehlt eben ein wichtiges Kriterium, das Vertrauen in denjenigen, dessen Namen im Z. eingetragen ist. Und deshalb musst du das Herausgeberzertifikat derartiger Herausgeber bewusst importieren und ihnen auch bewusst das Vertrauen trotz der o.g. Einschränkung aussprechen.
Unabhängig davon sind derartige Zertifikatge selbstverständlich im privaten Bereich völlig ausreichend. Und kryptologisch gibt es bei den Softwarezertifikaten (-Token) so wie so keine Unterschiede.

Du musst also erstens dafür sorgen, dass das Z. wirklich zu deinem Server passt.
Und zweitens musst du den "Vertrauensbaum" aufbauen. Also das Herausgeberzertifikat installieren und diesem das Vertrauen einstellen.
Der Import sowohl des Herausgeberzertifikates als auch deiner eigenen Schlüsseldatei (p12, pfx, aber auch pem) erfolgt normalerweise für das gesamte Betriebssystem selbsterklärend mit Tools wie Kleopatra. (Es gibt Ausnahmen, Programme wie Thunderbird oder Firewox und einige andere bringen einen eigenen Zertifikatsspeicher mit!) Nach dem Import musst du das Herausgeberzertifikat und auch dein eigenes dort sehen können. Was ich nicht weiß ist, ob die von dir erwähnte Datei "cacert.pem" wirklich eine Schlüsseldatei ist, also auch wirklich beide Schlüssel enthält. Wurdest du beim Import nach einem Passwort gefragt? Bei ".pem" kann es sich nämlich sowohl um ein reines (öffentliches) Zertifikat, aber auch um eine Schlüsseldatei (Zertifikat + privateKey) handeln!

Wenn es sich nur um eine private Anwendung handelt (kommerzielle Anwender benutzen keine Kostnix-Zertifikate ...), dann kannst du auch sehr komfortabel mit Tools wie "xca" oder "tiny-ca" selbst Zertifikate erzeugen. Zumindest zum Üben ist das eine wunderbare Sache.

Ich hoffe, dass ich dir etwas helfen konnte.

MfG Peter

Jepp, erstmal danke.

Ich verwende den Zugang einzig und alleine! Von daher ist die Meldung bezügl. Vertrauem nicht zu dramatisch. Wichtig ist, das es geht.

Ich habe nun mit Openssl eine Zertikikat erstellt. Als letztes den Server-Key selbst zertifiziert. Nun habe ich eine "datei.mit.name.crt".

1. dyndns ist wie no-ip.org eine Orga die auf die gemeldete IP weiterleitet. Nimmt man als Common Name nun "....dyndns.org" oder den Namen des Servers der auch in der Hosts steht bzw. beim ping auf die lokale IP erscheint? Bevor er nach dem Zertifikat fragt hat er ja die Weiterleitung bereits passiert und kennt den "....dyndns.org" gar nicht.

2. im ssl-explorer gibt es die Möglichkeit ein Zertifikat zu importieren. Da das ganze über Browser geschieht, befinde ich mich nicht auf dem Server selbst sondern auf einem Client. Da bekomme ich den "Vertrauensbaum" geistig nicht umgesetzt. Muss ich eine der Dateien mit Endung key und/oder csr irgendwo auf dem Server parken?

Klar kannst du mit openssl auf der Konsole die Zertifikate erzeugen. Puristen machen das so Trotzdem empfehle ich dir eine gui wie "xca". Ist einfach leichter und auch anschaulicher.

Es gibt, wie ich schon erklärt habe, verschiedene Formate für die einzelnen Dateien. "pem" ist von außen nicht gleich zu erkennen, erst wenn du reinschaust siehst du, ob dort nur die public oder evtl. auch die secret Keys drin sind. Besser ist ein Export nach p12 oder pfx für die Schlüsseldatei und der oder cer oder crt für das Zertifikat. crt ist also ein Zertifikat.

Jetzt müsste ich mir den sslexplorer ansehen. Runtergeladen habe ich ihn schon, installieren werde ich ihn (als für mich nicht unbedingt notwendige Software) nicht auf meiner Arbeitskiste. Also evtl. heute Abend, wenn meine Frau nix anderes vor hat ... .
Aus deinen Worten entnehme ich, dass dieses Programm einen eigenen Zertifikatsspeicher hat. Muss ich mir einfach mal ansehen.

In das Zertifikat musst du den dyndns-Namen eintragen. Und der Client / die Clients müssen die Zertifikatsdatei importieren. Als Serverzertifikat darf der secretKey entweder kein Passwort haben oder (einige Programme wollen das so) das PW muss in einer conf hinterlegt werden. Weiß ich also auch nicht.

Wenn du nur ein einziges Zertifikat erzeugt hast, dieses also "selbstsigniert" ist, brauchst du kein Herausgeberzertifikat. Sonst muss es auch auf dem Server und dem Client importiert werden.

So, mehr kann ich jetzt wirklich nicht dazu sagen, ohne dass ich das Programm gesehen habe.
Entweder ich mache das heute Abend - oder in einer Woche. Dazwischen liegen ein paar Tage Urlaub.

MfG Peter

Hi, ich bekomme es nicht hin. Nun habe ich durch eine Neuconfig des ssl-explorers ein neues Zertifikat erzeugt. Dies mit "korrekten" Daten. Von mir (aber im gleichen netz) funktioniert alles bestens. Von außerhalb = "Zertifikatsfehler" (der IE 7 ist der einzige der eine solche Meldung bringt). Ich kann exakt einmal auf die Seite zugreifen. Das heißt ich stehe vor der Tür und klopfe. Der Türsteher sagt, zeig mir Deinen Ausweis macht die Tür aber nicht auf. Wenn ich ein zweites mal komme, komme ich gar nicht mehr bis zur Tür :???: Hier scheint Firefox sich zu merken das es eh keinen Sinn macht. Unter "Extras", "Einstellungen", "Erweitert" lösche ich die Zertifikate immer.

Noch was ist mir aufgefallen. Ich habe zwischenzeitlich zwei IP-Weiterleitungen. Beide leiten von extern aber die https Anfrage nicht weiter. Nehme ich aber die IP von den Seiten, funktioniert das anklopfen (wie gesagt, einmal). Prüfen diese Weiterleitungen auch schon das Zertifikat?

Vermutlich merken sich dies sch... Moderne Webbrowser sowas und ich müsste den gesamten Cache leeren.

Was kann man da den falsch machen?

Ich habe noch eine Steigerung.

Mein Kumpel kann von sich aus auf meinen sslexplorer und bekommt den Logon.
Er kann auch von hier auf seinen sslexplorer zugreifen und dann von sich dort auf meinen.
Aber er kann von hier ebenfalls nicht direkt auf meinen sslsxplorer.

Fazit: Mein sslexplorer rennt! (aber nicht für mich von hier) (wobei "hier" egal ist und überall sein kann )