SSL Zertifikate

[Guest]

Über Zertifikate habe ich einiges gelesen, aber nun haben sich einige Fragen aufgetan.

Und zwar geht es darum eine HTTP-Verbindung auf SSL umzustellen.

Die HTTP-Verbindung findet nicht im Browser statt sondern von einer WebStart Applikation.
D.h. die Verschlüsselung findet im Hintergrund statt.


Nun stelle ich mir die Frage ob es das Geld wert ist VeriSign oder Thawte aufzusuchen. Reicht in diesem Fall (trotz kommerzieller Nutzung) nicht ein eigenes Zertifikat?
Wenn ich das richtig sehe hat es doch keinen Nutzen ausser der Authentifizierung der Firma.

Die Leitung ist doch ebenso Verschlüsselt, richtig?!
Bzw ist die Leitung mit der Sicherheit verschlüsselt mit der es das Zertifikat ist? Das verstehe ich nicht ganz.

 

[maki]

Browser "kennen" die großen & teuren Frimen wie Verisign, falls sie ein Zertifikat finden dass von einer dieser Firmen stammt, vertrauen sie ihm automatisch, bei allen anderen bekommt der User eine Warnung angezeigt.

Was die Sicherheit betrifft gibt es keinen Unterschied.

 

[Wildcard]

Die Verbindung ist gleich sicher (bzgl. Datenübertragung), das ist nicht das Problem.
Es geht viel mehr darum, eine Identität sicherstellen zu können. Die meisten Anwendungen die SSL verwenden unterstützen einige Well-Known Root CAs (besagte VeriSign, Thawte, ...) alle anderen werden als unbekannt entweder verworfen, oder dem Anwender präsentiert.
Ein 'echtes' Zertifikat muss aber kein Geld kosten. Schau dir beispielsweise mal CAcert an. Sobald deine Identität zweifelsfrei festgestellt wurde, kannst du Zertifikate ausstellen. Die werden dann zwar immer noch nicht von IE und co. erkannt (wenn man das CAcert Root Zertifikat nicht importiert), sind aber zumindest eine echte Authentifizierung.

 

[meister-g]

danke für die infos...

eine frage bleiben aber noch offen:

warum reden die zertifikatstellen von 128/256 bit verschlüsselung?

welche verschlüsselung habe ich bei meinem eigenem zertifikat?! die die ich für den key angegeben habe? (-keyalg)
wenn ja und ich nehme rsa wieviel bit sind das?


edit: gast oben war ich.. fehler beim einloggen

 

[meister-g]

Hallo,


ich bin beim Thema SSL schon soweit, dass alles reibungslos funktioniert.

Nun hat sich aber etwas Neues aufgetan:

Zur höchsten Sicherheit bzw um den Zugang zu steuern möchte ich auch eine Client Identifizierung durchführen und den Client Keystore manuell verteilen.
Das heißßt der client Keystore wird nicht automatisch beim Deployen in die Applikation eingetragen, sondern zur Laufzeit angegeben.
Das funktioniert soweit auch.

Überraschenderweise in mehreren Szenarien:

1. Server-Keystore exportiert Zertifikat und es wird in den Client-Keystore importiert
Überaschenderweise funktioniert die SSL-Verbindung auch, wenn ein Client-Keystore nur durch den Import des Server-Keystores erstellt wird (ich hatte einen Fehler in meiner Batch), d.h. der Client-Keystore enthält kein eigenes Schlüsselpaar
2. Server-Keystore exportiert Zertifikat und es wird in den Client-Keystore importiert, Client Keystore exportiert Zertifikat und es wird im Server-Keystore importiert.

Unerwartetes Ergebnis:
Die Verbindung klappt bei beiden Varianten auch mit abgelaufenem Client-Schlüssel.
Ein Keytool zeigt mit an, dass es wirklich abgelaufen ist. Die Server Logs zeigen eine Zeit nach Ablauf an.


Kann mir das einer erklären?



Ist es gar nicht möglich Client-Schlüssel zu erstellen die ablaufen können? Sollte doch eigentlich möglich sein!?
Wenn ja, wie?!


server.bat

echo Erstellen des Server KeyStore in Datei server.keystore
%java_home%\bin\keytool -genkey -alias server -validity 1000 -dname "CN=Servername" -keyalg RSA -keypass changeit -storepass changeit -keystore server.keystore 

echo Exportieren des Server Zertifikats vom Keystore in die Datei server.cer
%java_home%\bin\keytool -export -alias server -storepass changeit -file server.cer -keystore server.keystore

client.bat (REMs sind cross-zertifizierung)

echo Erstellen des Client KeyStore in Datei client.keystore
%java_home%\bin\keytool -genkey -alias client -validity 1 -dname "CN=Client" -keyalg RSA -keypass changeit -storepass changeit -keystore client.keystore 

REM echo Exportieren des Client Zertifikats vom Keystore in die Datei client.cer
REM %java_home%\bin\keytool -export -alias client -storepass changeit -file client.cer -keystore client.keystore

echo Importieren des Server Zertifikats in den Client Keystore 
%java_home%\bin\keytool -import -v -noprompt -trustcacerts -alias trustcert -file server.cer -keystore client.keystore -keypass changeit -storepass changeit

REM echo Importieren des Client Zertifikats in den Server Keystore 
REM %java_home%\bin\keytool -import -v -noprompt -trustcacerts -alias trustcert -file client.cer -keystore server.keystore -keypass changeit -storepass changeit

Kommentiert man in client.bat den ersten keytool-Befehl aus, so kann mit dem Keystore mit importiertem Server-Zertifikat aber ohne eigenen Schlüssel auch die Verbindung aufgebaut werden. Hätte ich so nicht erwartet.


Edit: auch bei Ablaufen des Server Zertifikates funktioniert die verschlüsselte Verbindung!
Ist das bei selbst erstellten Zertifikaten immer so???

 

[meister-g]

edit... doch nix

aber obiges problem herrscht nach wie vor...weiss niemand was dazu?!

 

[FArt]

Welches genau ist "obiges Problem"?

 

[meister-g]

Dass abgelaufene Zertifikate keine Rolle spielen.

 

[Wildcard]

Das hängt von der verwendeten Implementierung des TrustManagers ab. Diesen kannst du beliebig verändern, aber eigentlich sollte der Default-TrustManager diese Checks durchführen. Welchen hast du gesetzt?

 

[meister-g]

Alles was ich client-Seitig mache ist zur Laufzeit:

System.setProperty("javax.net.ssl.trustStore", Res.getUserDir(user) + "client.keystore");
System.setProperty("javax.net.ssl.trustStorePassword", "changeit");

oder beim Deployen:

<sysproperty key="javax.net.ssl.trustStore" value="${trustStore}"/>
<sysproperty key="javax.net.ssl.trustStorePassword" value="${trustStorePassword}"/>

Wie setze ich den TrustManager bzw. was muss ich ändern um abgelaufene client-Zertifikate nicht zuzulassen?

 

[Guest]

ich bitte nochmal um hilfe... bin langsam am verzweifeln.


nachdem die ssl-verbindung ja grundsätzlich funktioniert habe ich seit wochen nun ein neues problen:

als applikation gestartet funktioniert es, deployed als webstart in keinem fall.
ich benutze den gleichen server, die gleichen client und server zertifikate, alles komplett identisch.

javax.net.ssl.trustStore, javax.net.ssl.trustStorePassword

habe ich
- über ant durch sysproperty gesetzt
- über die jnlp als properties weitergegeben
- über die jnlp über die vm weitergegeben (-Djavax...)
- zur laufzeit (System.setProperty...) gesetzt

(nur um sicher zu sein, dass die properties gesetzt sind. eine ausgabe zur laufzeit bestätigt das auch. anmerkung: nicht bei allen varianten)


tomcat wirft immer folgende exception:
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

was mir sagt, dass beim handshake etwas schiefgelaufen ist.


viel lesen bringt mir die vermutung (aber auch keine wirklich sicheren aussagen), dass die webstart sandbox keine selbst signierten zertifikate zulässt.

daraufhin habe ich mein eigenes zertifikat als root-zertifikat (und auch in den anderen gruppen) manuelle über das java control panel hinzugefügt.
ausserdem habe ich es auch /security/cacerts hinzugefügt

wieder kein erfolg.



was kann ich noch machen?
ich kapiere nicht warum unter dem jre alles klappt und in der webstart sandbox gar nicht mehr.

mein letzter weg war die idee dann eben doch ein vertrauenswürdiges zertifikat zu erstellen. dafür gibt es diverse trials, z.b. von thawte.... das nimmt aber meinen request nicht an: "intranet not supportet" weil ich den rechnernamen angegben habe. soll ich jetzt extra einen webserver aufziehen oder nutzen um das deployment zu testen? ich bin ja nicht einmal sicher, ob die sache mit einem richtigen zertifikat überhaupt funktioniert.

kann mir irgendjemand weiterhelfen?

das ist doch kein sonderfall ssl über webstart zu nutzen (das herunterladen der programmdateien ist kein problem. es geht darum, dass das programm an sich eine https verbindung aufbauut)

ich bitte um alle möglichen infos, da ich langsam echt verzweifel

 

[Wildcard]

Ich würde mal sagen das ein Webstart Anwendung nicht einfach den TrustStore verbiegen kann, denn selbiger ist ja eben dafür verantwortlich die Rechte der Anwendung einzuschränken.
Was genau ist jetzt dein Problem? Das Verbindungen vom Client auch dann akzeptiert werden wenn das Zertifikat abgelaufen ist?
Wie gesagt, dafür ist der Server verantwortlich, warum bastelst du also gerade am Webstart Client?

 

[meister-g]

Das Probleme mit den abgelaufenen Zertifikaten habe ich nun einordnen können.
Anscheinend ist es so, dass per default abgelaufene Zertifikate akzeptiert werden.
Aber das ist nun erstmal nebensächlich bzw. habe ich schon eine Idee wie ich das hinbekomme.



Mein aktuelles Problem hier nochmal genau beschrieben:

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed
tritt auf nach dem Deployment zum Webstart. Und ich verstehe nicht warum. Denn der Zugriff auf das truststore-File erfolgt über das Dateisystem.
http und https via Start als normale Java Applikation funktioniert einwandfrei.

So sezte ich den truststore:
System.setProperty("javax.net.ssl.trustStore", "ABSOLUTER_PFAD");
System.setProperty("javax.net.ssl.trustStorePassword", "changeit");
Ich habe auch die anderern Varianten ausprobiert die Properties zu setzen (tag sysproperty beim deployen via ant, übergabe in der jnlp über die jvm (-Dkey)

Ich habe unendlich viele Kombinationen ausprobiert die keystores zu handlen. U.a. auch das Server-Zertifikat in den JRE truststore (cacerts) aufzunehmen, was ja default ist.

Meine konkrete Frage:
Was ist konkret in der WebStart Sandbox anders? Was kann ich tun?
Ich möchte einfach nur dass die https-Verbindung nun endlich auch über WebStart funktioniert.

Generell zur Erklärung: Es handelt sich um einen Client, welcher via SOAP mit dem Servlet auf dem Tomcat kommuniziert. Diese Kommunikation soll nun verschlüsselt werden.

 

[meister-g]

edit: technische probleme, 3 mal gepostet

 

[meister-g]

edit: technische probleme, 3 mal gepostet

 

[Wildcard]

http://java.sun.com/docs/books/tutorial/deployment/webstart/security.html

 

[meister-g]

Ich verstehe nicht was mir dort Informationen zum Lösen meines Problems geben könnte?

Hätte ich nicht die Sun-Seiten und dazu noch sehr lang das www durchforstet hätte ich wohl nicht hier um Rat gefragt.

Wenn Du offensichtlich Ahnung von der Sache hast, Wildcard, hast Du nicht ein paar Zeilen für mich die mir weiterhelfen?

 

[Wildcard]

Nun, du wolltest wissen was die Webstart Sandbox von einer normalen Applikation unterscheidet:

Java Web Start dynamically imports certificates as browsers typically do. To do this, Java Web Start sets its own https handler, using the java.protocol.handler.pkgs system properties, to initialize defaults for the SSLSocketFactory and HostnameVerifier .

Webstart setzt also eigene Handler und ich vermute das es an dieser Stelle mit deinen Änderungen kollidiert.

Für dein Problem sollte also eigentlich dieser Hinweis der relevante sein:

You can ensure that your own customized SSLSocketFactory and HostnameVerifiter are used by doing one of the following:

* Install your own https handler, to replace the Java Web Start https handler. For more information, see the document A New Era for Java Protocol Handlers .
* In your application, invoke HttpsURLConnection.setDefaultSSLSocketFactory or HttpsURLConnection.setDefaultHostnameVerifier only after the first https URL object is created, which executes the Java Web Start https handler initialization code first.

 

[meister-g]

Teilroblem gelöst, neues Problem .


Der Fehler war, dass das Servlet selbst mit der gleichen URL auf Resourcen zugreifen wollte.
Die Verbindung vom Client zum Servlet lief fehlerfrei.

Nun habe ich mich weiter mit dem Thema SSL und Keystores beschäftigt und wollte die ganze Sache endlich deployed als WebStart zum Laufen bekommen. Und wieder gibt es Probleme.
Ohne Client Authentifizierung funktioniert alles einwandfrei: Entweder nach Popup von WebStart dem Zertifikat zu vertrauen (vg. normale Applikation Exception) oder mittels angegebenen TrustStore bzw im JRE-Truststore importiertem eigenen Server-Zertifikat.

Mit Client-Authentifizierung klappt alles als Applikation wunderbar:

System.setProperty("javax.net.ssl.keyStore", dir + "client.keystore");
System.setProperty("javax.net.ssl.keyStorePassword", "clientpass");
System.setProperty("javax.net.ssl.trustStore", dir + "client.keystore");
System.setProperty("javax.net.ssl.trustStorePassword", "clientpass");

(client.keystore enthält eigenes Schlüsselpaar, welches im Serverzertifikat importiert ist und importiertes TrustStore vom Server.


Beim Start über Webstart bekomme ich ein Popup "Identifizierung erfoderlich". Dazu eine Liste aber diese ist leer.
Interessant, dass das Popup beim Start der Anwendung erscheint, bei der noch keine Verbindung aufgebaut wird.

Mein nächster Gedanke war auch deshalb, dass ich evtl beim Start über Webstart nicht mehr zur Laufzeit die Properties setzen kann. Deshalb habe ich beim Ant-Deployen folgendes gemacht:

<sysproperty key="javax.net.ssl.trustStore" value="c:\client.keystore"/>
<sysproperty key="javax.net.ssl.trustStorePassword" value="clientpass"/>
<sysproperty key="javax.net.ssl.keyStore" value="c:\client.keystore"/>
<sysproperty key="javax.net.ssl.keyStorePassword" value="clientpass"/>

kein Erfolg.

Über die JNLP:

java-vm-args="-Djavax.net.ssl.keyStore=c:\client.keystore -Djavax.net.ssl.keyStorePass=clientpass -Djavax.net.ssl.trustStore=c:\client.keystore -Djavax.net.ssl.trustStorePass=clientpass"

ebenfalls kein Erfolg.


Wildcard gab mir ja den Link mit der Information, dass WebStart eigene Handler setzt.
Doch aus dem weiterführenden Link werde ich nicht schlau wie ich vorgehen soll. Bzw benutze ich die angegebenen Methoden und Klassen (SSLSocketFactory HostnameVerifier HttpsURLConnection.setDefaultSSLSocketFactory HttpsURLConnection.setDefaultHostnameVerifier) nicht.

Kann mir jemand weiterhelfen?

 

[Wildcard]

Ich meine das schon erwähnt zu haben:
Ich bin mir zwar nicht 100% sicher, aber ich kann mir beim besten Willen nicht vorstellen das eine Webstart Anwendung den Keystore austauschen kann. Damit die Anwendung überhaupt Rechte bekommen kann muss die Signatur mit dem Keystore abgeglichen werden. Würde es dann Sinn machen wenn die JNLP/die Anwendung diesen Keystore ungefragt austauschen kann?

EDIT:
Mal was anderes, hast du schonmal so versucht?

Djavax.net.ssl.keyStore=/c:/client.keystore

 

[meister-g]

danke, das werd ich mal ausprobieren.

wenn ich den keystore nicht ändern kann - wie kann ich ihn dann zumindest setzen?

den truststore kann ich ja z.b. in security/cacerts eintragen. und was ist mit dem keystore? auch dort?
und/manuell in der Systemsteuerung->Java->Zertifikate? Wenn dort - wo exakt? Und was hat es an dieser Stelle mit Client-Zertifikaten auf sich? Man muss ein Passwort angeben aber das ist immer ungültig.

 

[meister-g]

der führende slash hat leider auch nichts genützt.

wie kann ich denn nun
- der webstart anwendungen den keystore mitteilen oder
- einen client keystroe/ ein client zertifikat installieren?

zu letzterem:
will ich ein client-zertifikat über das java control panel (wie auch zb im firefox) installieren (wenn ich das richtige installiert habe sollte es ja funktionieren - laut http://weblogs.java.net/blog/stanleyh/archive/2005/06/security_and_ne_1.html bzw den java-einstellungen wird automatisch das richtige gewählt oder es muss eben ein eintrag aus der liste gewählt werden. diese liste ist ja eben bei mir leer) bekomme ich die aufforderung ein passwort einzugeben - und dieses ist immer falsch (leer, beliebig, keystore/truststore passwort). es muss doch an dieser stelle ein zertifikat installiert werden? wenn ja wie mache ich das bzw was ist das passwort bzw wie umgehe ich es.
gibt es auch einen konsolenbefehl für diese installation? der weg über das control-panel für jeden anwender wäre sehr ekelig. bzw. gibt es wie für den truststore "cacerts" ein keystore file, das java/webstart für das speichern der keystores/zertifikate verwendet?

 

[meister-g]

ich finde für das zuletzt beschriebene problem keine lösung.
kann hier niemand weiterhelfen?


eigentlich handelt es sich ja nur um eine reguläre client-authentifizierung über webstart.
sollte dch kein exotischer anwendungsfall sein.

 

[meister-g]

ich bin langsam am verzweifeln, habe aber neue erkenntnisse.

damit schildere ich jetzt noch einmal step-by-step mein problem, evtk kann ja jemand helfen.

ziel: ich möchte eine ssl-verbindung mit client-authentifizierung über einen webstart-client realisieren

standpunkt: als applikation funktioniert alles einwandfrei. hier kann ich zur laufzeit oder über ein ant-buildfile den keystore (+ggf den truststore, ich verwende zur zeit aber den jre-default, d.h. ich habe dort meinen server eingetragen) setzen. ssl-verbindung klappt mit client-authentifiizierung

nach dem deployment habe ich das problem, dass beim start der anwendung ein webstart-dialog zur zertifikatauswahl kommt. die liste ist leer und die anwendung kann nicht gestartet werden, da ich eben kein zertifikat auswählen kann.
grund offensichtlich: die entscheidenden properties javax.net.ssl.keyStore und javax.net.ssl.keyStorePassword sind nicht gesetzt.

wie kann ich diese setzen? (außer wie oben beschrieben, was unter javaws keinen effekt nach sich trägt)

mein versuch über das jnlp funktioniert leider nicht. evtl habe ich ja hier aber einen fehler drin:

<?xml version="1.0" encoding="UTF-8"?>

<jnlp 
 spec="1.0+" 
 codebase="https://mycodebase" 
 href="myjnlp.jnlp">
 
  <information>
   ...
  </information>

  <security>
  	<all-permissions />
  </security>

  <resources>
    <j2se version="1.6+" initial-heap-size="128m" max-heap-size="512m" java-vm-args="-Dtest=test -Djavax.net.ssl.keyStore=c:/client.keystore -Djavax.net.ssl.keyStorePass=clientpass"/>
    <jar href="lib/classes.jar" main="true" />

...

(zusätzlich den truststore setzen bringt nichts, es liegt wirklich am keystore bzw dass die property nicht gesetzt ist)

starte ich die anwendung (was nur geht wenn ich über http gehe oder die client-authentifizierung abschalte) mit dieser jnlp und gebe mir die parameter aus, so sind diese leer (gleiche ausgabe ohne webstart-deployment und mit oben genanntem setzen gibt die properties korrekt aus). auch die test-property ist zur laufzeit leer. das zeigt, dass ich entweder einen fehler mache oder systemproperties so nicht gesetzt werden können.

folglich erkennt javaws keinen keystore / kein zertifikat und bringt den dialog.

aber wie teile ich webstart denn nun die properties mit? habe ich im jnlp einen fehler? wenn nicht wie geht es noch?

alternative wäre wahrscheinlich die zertifikatliste zu füllen - mit meinem client-zertifikat.
hier müsste der weg Java Control Panel -> Sicherheit -> Zertifikate wohl richtig sein. und hier vermute ich "Client-Authentifizierung" (zur sicherheit habe ich alle anderen kategorien durchprobiert). nur in dieser kategorie kann ich allerdings kein zertifikat installieren. ich werde aufgefordert ein passwort einzugeben - egal was ich eingebe (leer, keystorepasswort, truststorepasswort) es funktioniert nicht.
oder wenn nicht durch die oberfläche: sind die client-zertifikate (so wie die serverzertifikate fürs jre in cacerts) irgendwo gespiechert und können z.b. mit dem keytool bearbeitet werden? wäre mir sowieso lieber, weil man dann für jeden client einen batch laufen lassen könnte und sich nicht durch die oberflächen klicken muss.


zwei lösungswege, ich finde die lösung aber nicht und verzweifel schon ewig daran.


das paket ssl + webstart + clientauthentifizierung ist doch nicht so exotisch. wie haben das andere hinbekommen?

 

[meister-g]

ich habe nachgelesen, dass über die jnlp nur bestimmte attribute der jvm über "java-vm-args" übergeben werden könnnen, sonst geht es so:

<property name="javax.net.ssl.keyStore" value="c:/client.keystore"/>
<property name="javax.net.ssl.keyStorePassword" value="changeit"/>

das setzt erfolgeich diese attribute (tracen wenn ich die anwendung ohne client authentifizierung starte), ändert allerdings nicht am verhalten.


kann wirklich keiner weiterhelfen?


ich finde 1000 infos darüber wie ich zertifikate erstelle, aber nicht wie ich sie webstart mitteile oder als client-authentifzizierungs-zertifikat für java eintrage.

anmerkung noch: auch für den browser kann ich die zertifikate nicht installieren. auch dort gibt es eine passworteingabe über die ich nicht hinwegkomme.

hat das evtl damit zu tun, dass ich selbssiginierte zertifikate verwende?

 

[Fancy]

Moin,

anmerkung noch: auch für den browser kann ich die zertifikate nicht installieren. auch dort gibt es eine passworteingabe über die ich nicht hinwegkomme.

hat das evtl damit zu tun, dass ich selbssiginierte zertifikate verwende?

Nein. Für den Import des selbstsignierten Zertifikats in den Browser oder in das Java Control Panel brauchst Du die Datei im PKCS#12 Format. Bei der Erstellung dieser Datei (es muss der private Schlüsselteil, das öffentliche Zertifikat, sowie ggf. ein selbstsigniertes CA Zertifikat enthalten sein) hast Du mit ziemlicher Sicherheit ein Passwort angeben müssen. Mit diesem Passwort wurde die Datei gesichert und genau dieses Passwort wird beim Import verlangt. Falls Du kein Passwort gesetzt hast, setze eins, dann sollte es gehen.

Beispiel:

C:\Users\Fancy>openssl genrsa -out self.key 1024
Loading 'screen' into random state - done
Generating RSA private key, 1024 bit long modulus
.............++++++
.............++++++
e is 65537 (0x10001)


C:\Users\Fancy>openssl req -new -key self.key -x509 -out self.crt
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:.
Organization Name (eg, company) [Internet Widgits Pty Ltd]:.
Organizational Unit Name (eg, section) []:.
Common Name (eg, YOUR name) []:Fancy
Email Address []:fancy@...


C:\Users\Fancy>openssl pkcs12 -export -in self.crt -inkey self.key -out self.p12

Loading 'screen' into random state - done
Enter Export Password:
Verifying - Enter Export Password:

Das so erstellte self.p12 läst sich überall problemlos importieren.

Übrigens machen selbstsignierte Client-Zertifikate dauerhaft nicht wirklich sinn, da die Prüfung der Gültigkeit gegen ein Wurzelzertifikat erfolgen sollte. Du solltest Dir mindest eine minimale PKI aufbauen. Dazu reicht es einfach ein selbstsigniertes Wurzelzertifikat zu erstellen und mit diesem dann das Server-Zertifikat sowie die einzelnen Client-Zertifikate zu signieren. In den Truststore der einzelnen Rechner kommt dann nur Dein selbstsigniertes Wurzelzertifikat. Und in den jeweiligen Keystore das passende Client-Zertifikat (incl. privatem Schlüsselteil, importiert als P12).

Gruß,
Michael