# SSL-Zertifikate für viele Nutzer?



## fc90 (16. Jun 2011)

Hallo,

Ich hoffe der Titel ist etwas aussagekräftig. Wusste nicht wie ich mein Problem sonst kurz beschreiben soll.

Ich schreibe zur Zeit an einer kleinen Server-Client-Anwendung, die ich dann mehreren Nutzern zur Verfügung stellen möchte. Die Verbindung soll sicher über SSL erfolgen (hab ich schon programmiert und funktioniert auch).

Allerdings muss man ja nun für jeden Server und jeden Client ein neues Zertifikat erstellen. Wie stellt man das am besten an? Erstellt man die Zertifikate automatisch, oder kann man das ganz umgehen?

Ich will halt nicht jedem Client/Server ein einzelnes Zertifikat geben müssen, bei anderen Programmen geht das ja auch ohne das jeder einen extra Download hat


Ich hoffe mir kann jemand helfen und ich danke schon mal für sinnvolle Antworten.


----------



## homer65 (16. Jun 2011)

Ich dachte eigentlich, das nur jeder Server ein Zertifikat hatt. Während die Clients vom Server alle das gleiche Zertifikat bekommen.


----------



## fc90 (16. Jun 2011)

dann hab ich das vielleicht falsch verstanden.

Ich habe mir das bei diesem Tutorial angeschaut:
JAVA + SSL Tutorial

müsste ich dann sozusagen die keyStore-Datei vom Server zum Client schicken? Das wäre ja noch unverschlüsselt...


----------



## HoaX (16. Jun 2011)

Der Client benutzt in dem Tutorial den selben Keystore wie der Server, und zwar aus gutem Grund:
Der Client prüft das Zertifikat des Servers ob es gültig ist. Solange das Serverzertifikat selbstsigniert/von keiner großen Zertifikatstelle signiert ist, kennt der Client das Zertifikat natürlich nicht. Es wäre somit ohne weiteres für einen Angreifer möglich einen eigenen SSL-Proxy dazwischen zu schalten mit einem eigenen Zertifikat (da er das Originalzertifikat+Privatekey) nicht hat. Der Client würde das nicht erkennen. Darum wird in dem Beispiel dem Client das Zertifikat des Servers mittels Keystore bekannt gemacht, so dass er die Signatur aus dem Keystore mit der per SSL-Verbindung erhaltenen Signatur zu vergleichen und ggf. den Verbindungsabbau abzubrechen.

Wenn du eine solche Zertifikatprüfung nicht brauchst, dann kannst du auch eine eigene SSLSocketFactory betreitstellen die darauf verzichtet.
Kiran Thakkar's Blog: Dummny certificate authentication implementation


----------



## fc90 (16. Jun 2011)

vielen Dank für deine Antwort.

Wäre das dann trotzdem noch als sicher zu betrachten? Die Zertifikate machen doch eigentlich nichts anderes als die Identität zu verifizieren, oder?

Hier mal kurz beschrieben was genau ich will:

1. Verbindung wird gesichert aufgebaut (mit SSL).
2. Client sendet Benutzer und Passwort zum Server.
3. Server sendet Daten zurück.
4. Ende der verschlüsselten Verbindung.

Es sollte eben halt relativ abhörsicher sein, da ja die Benutzerdaten übertragen werden (vll. hashe ich die auch bevor ich sie übertrage?).


----------



## HoaX (16. Jun 2011)

Wenn der Client das Serverzertifikat nicht kennt, dann kann er dessen Identität auch nicht verifizieren. Wenn du also darauf angewiesen bist, dann benötigt der Client vorher schon eine Kopie des Serverzertifikats.


----------



## FArt (17. Jun 2011)

Der Unterschied zwischen Client- und Serverzertifikaten ist euch bekannt, oder?


----------



## fc90 (17. Jun 2011)

na die Zertifikate sind doch eigentlich nur dazu da um die Identität von Server oder Client zu bestätigen.

Ich hab mir das noch mal durch den Kopf gehen lassen, eigentlich brauche ich nur ein Zertifikat auf Serverseite, weil sonst könnte jemand einen Fake-Server aufmachen und würde am Ende die Daten im Klartext kriegen. Clientmäßig ist es ja eigentlich egal, wenn Benutzername und Passwort nicht stimmen gibts eh keine Daten.


----------



## ThreadPool (17. Jun 2011)

fc90 hat gesagt.:


> na die Zertifikate sind doch eigentlich nur dazu da um die Identität von Server oder Client zu bestätigen.
> 
> Ich hab mir das noch mal durch den Kopf gehen lassen, eigentlich brauche ich nur ein Zertifikat auf Serverseite [...]



IMHO Die Leute die das so machen veröffentlichen oft den Fingerprint des Zertifikats (auf einer normalen ungesicherten Seite), so kann man zumindest auf Sicht überprüfen ob das Zertifikat wohl das richtige ist bevor man sich über eine gesicherte Verbindung verbindet.


----------

