✔ Neuland Zertifikate

[melmager]

Also ich richte grade einen neuen Server für ein KMU ein die ich nebenbei etwas IT mässig unter die Arme greife.

In dem Zusammenhang wollte ich endlich mal LDAP einführen.
Der LDAP Server möchte aber mehrere Zertifikate haben wenn man den mit TLS fahren möchte - und das bringt mich etwas ins schleudern.
Ein klassisches Verständnissproblem

Fangen wir mal einfach an - sprich was ich verstanden habe:
SSL einrichten - mit keygen werden zwei Schlüssel erzeugt - der private wird weitergegeben, der private bleibt auf dem Server. Am Ende kann man sich mit Hilfe des privaten Schlüssels einloggen.

so jetzt kommt der Part den ich noch nicht ganz verstanden habe:
bei TLS brauche ich offensichtlich ein CA Zertifikat
drei Möglichkeiten:
Für teuer Geld kaufen
für kleines Geld/umsonst Geld besorgen (letsencrypt.org)
selber so tun als währe man ein CA. (der teil geht nur solange man nicht an die öffendlichkeit geht)

1) erstelle ein CA datei: ca-key.pem
2) scheinbar muss daraus ein root zertifikat erstellt werden (vererbung ? ) ca-root.pem

jede menge fragen beantworten beim erstellen

3) root zertifikat in richtiges Verzeichnis rein
4) eignes zertifikat erstellen (scheinbar erneut ne ableitung) zertifikat-key.pem

und scheinbar muss beim einrichten von LDAP Server mit TLS alle drei zertifikate mitgegeben werden (warum auch immer)

ist der Ablauf so richtig ?
CA zertifikat > root zertifikat > eigenes Zertifikat

Und wo liegt der Unterschied zwischen p12/pfx und pem Zertifikat ?

ich konnte gestern erfolgreich aus pem ein p12 machen (weil ein p12 als root zertifikat gefordert wurde)
aber was ich da gemacht habe - kein Plan

hilft irgendwie ein elsterzertifikat weiter - immerhin eine pfx Datei ?
warum gibst es im pem eine key Datei ? (und andre kein plan was die machen)
ist das pem sowas ähnliches wie eine verschlüsselte zip Datei ? (immerhin konnte ich mein
pem Zertifikat öffnen) weiss nur nicht was ich da sehe :-(

 

[melmager]

Noch ne Frage. Diesmal zu den Selbst erstellten SSH Zertifikaten und zugriff auf externe rechner

Wenn ich mit Rechner "meinrechner" in "rechnerA" mich über SSH einloggen will,
erstelle ich ja ein Zertifikatspaar public/privat das public kommt auf den "rechnerA"

soweit so gut
Was ist nun besser wenn es noch rechnerB / C usw gibt:
A) ich verteile einfach den Public teil auf alle Rechner
B) ich erstelle ein Key Paar Pub/privat für jeden externen rechner

Gibt es ein Vorteil wenn Version B gemacht wird ?

 

[sheel]

Hi

bin mir

SSL einrichten - mit keygen werden zwei Schlüssel erzeugt - der private wird weitergegeben, der private bleibt auf dem Server. Am Ende kann man sich mit Hilfe des privaten Schlüssels einloggen.

Versteh das nicht ganz.

SSL/TLS ist einmal prinzipiell etwas zur Verschlüsselung der übertragenen Daten und/oder Authentifizierung (Echtheitsüberprüfung) vom Server und/oder Authentifizierung vom Client (selten, aber möglich).
Rein technisch kann man die privaten/public Keys auch zum Signieren von beliebigen Daten verwenden: Person A signiert irgendwelche Daten mit dem eigenen privaten Key, unda dnere Personen mit dem Publickey von A können prüfen dass diese Daten wirklich von A signiert wurden (und nicht von Personen, die so tun, als wären sie A).

Wenn der private Key am server ist ist das für Zweck 1 und 2 nützlich, für 3 (Clientauth) aber nicht.

Der public Key (beim ersten "privat" ist wohl "public" gemeint) wird an die Ciients gegeben, ja, bzw. auch am Server platziert damit der die auch an neuen Clients verteilen kann (falls man das nicht selbst macht).
Aber warum soll man sich mit "dem privaten Key einloggen"?

so jetzt kommt der Part den ich noch nicht ganz verstanden habe:
bei TLS brauche ich offensichtlich ein CA Zertifikat
drei Möglichkeiten:
Für teuer Geld kaufen
für kleines Geld/umsonst Geld besorgen (letsencrypt.org)
selber so tun als währe man ein CA. (der teil geht nur solange man nicht an die öffendlichkeit geht)

Um es auseinander zu nehmen:

Das Zertifikat am Server enthält auch Infos wofür dieser Key ist. zB. das HTTPS-Zert dieser Seite hier ist zB. für die DNS-Domains tutorials.de und www.tutorials.de (es gibt auch Wildcards für alle Subdomains usw., egal).
Für Übertragungsverschlüsselung ist das egal, aber es ist wichtig für die Echtkeitsprüfung des Servers.

Hier wieder zwei Fälle:
a) Der Client, der sich gerade verbindet, hat den Publickey (zB. bei früheren Verbindungsversuchen gesendet bekommen). Der Publickey da drin wird dann auch für die Verbindung verwendet. Das reicht schon, um zu prüfen, ob der Server von tutorials.de der selbe Server wie bei früheren Besuchen war (Angenommen, der private Key am Server wurde von keinem Unbefugten kopiert und selbst verwendet - in dem Fall hilft SSL/TLS nicht)
b) Der Client hat den Publickey noch nicht, und der Server bietet deshalb das Senden an. Woher weiß man hier, dass der Server auf der anderen Seite der Verbindung das "echte" tutorials.de ist? Geht mit den bisher genannten Mitteln eigentlich nicht. Der Publickey vom Server ist eben der Publickey vom Server, und sagt es ist tutorials.de, aber das kann jeder behaupten.
Für den Zweck gibt es ein paar (hoffentlich vertrauenswürdige) Ober/Root-CAs, die auch private/public Keys haben, und von denen die Publickeys schon mit dem Browser etc. (bei LDAP wohl nicht der Browser) mitgeliefert werden (also immer vorhanden sind). Als Admin von tutorials.de kann ich mit meinen Keys zu einer RootCA gehen, irgendwie bestätigen dass ich tutorials.de-Admin bin, und mein Zert von denen dann signieren lassen. Der CLient kann dann mit den Publickeys der RootCAs, der er ja schon hat, prüfen, ob das neu gesendete Serverzertifikat für tutorials.de auch von dieser CA bestätigt wurde.

Das umständliche Zertifikatsverteilung wird also mit einem System aus wenigen Ober-CAs gelöst, die theoretisch perfekt sind, ihren Privatekey nicht verlieren usw. . Praktisch gibt es bei vielen Probleme - entweder mangelnde interne Sicherheit (gab wirklich schon Fälle, wo der Privatekey in falsche Hände kam), und/oder zu wenig Überprüfung bei Kunden, ob die die angegebene Domain etc. wirklich besitzen (vor allem deswegen verschwinden immer mal wieder CAs aus den vorinstallierbaren Listen der Clientsoftwares, weil die Softwarehersteller nicht mehr der Meinung sind, dass die CAs sicher genug arbeiten). (Nächstes Problem ist gewolltes Signieren gefälschter Zerts für Regierungen usw....)

Lange Rede kurzer Sinn, diese CAs sind die "teuer"-Kategorie.

Letsencrypt usw. gibts deswegen, weil die eben teuer und teilweise nicht sicher sind: Kostet eben nichts und macht immerhin eine automatische Prüfung, ob ein Privatekey-besitzer auch die Domain kontrolliert.

(Es gibt auch eine Sonderart von Zertifikaten, die im Browser extra noch markiert werden (grün uw.), bei denen auch die beantragende Person selber geprüft wird (Ausweis etc.). Diese Art gibts derzeit nicht von Letsencrypt, weil man das nicht wirklich automatisieren kann, und Mitarbeiter nicht gratis sind).

Und Zertifikate, die nicht oder mit einem eigenen Oberzertifikat signiert wurden, haben eben das Problem dass das Oberzertifikat bei den Clients nicht vorhanden ist, und damit sinnlos ist.
Wie beschrieben ist das kein Problem, wenn jeder CLient den eigenen Publickey schon hat, oder auf irgendeine (sichere) andere Art bekommen kann, und das ist eben hauptsächlich in Firmennetzwerken der Fall.

Und wo liegt der Unterschied zwischen p12/pfx und pem Zertifikat ?

Ist nur eine andere Art, wie Key usw. in einer Datei abgespeichert werden.
pfx/p12 kann außerdem beide Keys enthalten (Private und Public). Pem ist üblicherweise Public, und .key der Private dazu.

hilft irgendwie ein elsterzertifikat weiter - immerhin eine pfx Datei ?

Weiterhelfen für was?

ist das pem sowas ähnliches wie eine verschlüsselte zip Datei ? (immerhin konnte ich mein
pem Zertifikat öffnen) weiss nur nicht was ich da sehe

Pem ist üblicherweise nicht verschlüsselt, und nein, es ist kein Zip. Es ist eben ein eigenes Dateiformat - keine Ahnung womit du es öffnen wolltest, aber ein Jpg-Bild in Notepad schaut auch nicht schön aus. Es gibt schon Software, die einem lesbare Infos daraus anzeigt, aber kein Texteditor. Siehe OpenSSL für die Shell zB.

 

[sheel]

Zu SSH:

Anders als bei TLS ist hier Übertragungssicherheit und "Client"authentifizerung die Hauptanwendung.

Der PrivateKey gehört NICHT auf den Server. Nur Public.

Wenn man das so hat...
Der selbe Key für mehrere Server ist prinzipiell kein Problem. Wenn einem der eine Key gestohlen wird hat der Angreifer aber eben auch Zugriff auf alle Server.

 

[Bratkartoffel]

Wenn einem der eine Key gestohlen wird hat der Angreifer aber eben auch Zugriff auf alle Server.

Zumindest so lange, bis man diesen aus der "authorized_keys" wieder entfernt hat.
Das Risiko ist aber ohnehin überschaubar, der Angreifer kennt normalerweise keine Hosts, zu dem der Schlüssel passt. Hier müsste also schon mehr schief laufen. (Schlüssel ausspähen, Username ausspähen, Hosts ausspähen)

Grüsse,
BK

 

[melmager]

Also:
in dem File "authorized_keys" landen alle pub key von den Servern die sich einloggen wollen.
beim rechner der sich einloggen will ist die datei id_rsa ist dann der "private Key" dazu passend.
siehe ssh-copy-id
was mir noch unklar ist:
bei mehreren keys, werden die dann auch an die Files id_rsa / Id_ras.pub angehängt (die default einstellung) oder arbeitet dann man mit "ssh -i ~/.ssh/nocheinkey xxxxxx" ?

das file known_hosts speichert ja den fingerprint der Server , das andre ist ja user bezogen so wie ich das verstanden habe.

 

[sheel]

Mehrere Keys in der File funktionieren nicht unbedingt. Also entweder mit dem Parameter, oder eine kompliziertere Config in der zentralen Configfile.

 

[melmager]

Jo mittlerweile arbeite ich mit einer config im User Bereich - ist einfacher wie die Option i
ich werde mal demnächst meine ssh Erkenntnisse als tutorial verwursteln