12
Mikrotik: Client-to-Site IPSec-VPN mit Zertifikat-Authentifizierung
Hallo,
auf einem Mikrotik möchte ich für mehrere Road Warrior L2TP/IPSec-VPN-Zugänge einrichten.
Zunächst hatte ich die oft beschriebene Variante mit PSK genommen, was auch funktionierte, aber den Nachteil hat, dass sich alle Road Warrior denselben PSK teilen, was im Falle des Ausscheidens eines Mitarbeiters aus der Firma nervt, da dann auf allen Geräten aus Sicherheitsgründen der PSK geändert werden müsste.
Also habe ich eine Authentifizierung mittels Zertifikaten ins Auge gefasst. Am liebsten wäre mir dabei, die in v6 eingeführte Möglichkeit von RouterOS zu nutzen, im Mikrotik eine CA zu erstellen und damit eine PKI zu verwalten. Minimalistisch ist dies im Wiki beschrieben, siehe http://wiki.mikrotik.com/wiki/Manual:IP/IPsec#Creating_Certificates .
Ziel der ganzen Sache sollte dann sein, dass ich im Mikrotik ein Zertifikat widerrufen kann und danach keine Verbindung mehr von Geräten, auf denen dieses Zertifikat installiert ist, aufgebaut werden kann.
Grundsätzlich funktioniert nun sehr vieles, d.h. die selbstsignierte CA lässt sich schnell einrichten, Zertifikate ausstellen und auch die Verbindung selbst funktioniert.
Probleme treten beim Widerrufen von Zertifikaten auf. Über ca-crl-host kann ich einen Host für die CRL angeben. Hier mangelt es mir wohl an Verständnis:
Kann der Mikrotik die Rolle des CRL-Hosts übernehmen, d.h. kann ich hier die lokale IP des Mikrotiks nehmen?
Muss dies ein externer Host sein?
Gibt es für einen CRL-Check ein Protokoll?
Brauche ich also einen Server, der das entsprechende Protokoll spricht? Oder wird nur über ein HTTP GET eine Plaintext-Liste geladen und dann vom Router abgeprüft?
Bei mir funktionieren Verbindungen nur, wenn ich keinen ca-crl-host spezifiziere. In diesem Fall kann ich via "issued-revoke" zwar scheinbar erfolgreich Zertifikate widerrufen (diese bekommen das Flag "R"), beachtet wird dieser neue Status jedoch nicht, d.h. ein Verbindungsaufbau ist weiter möglich.
Habt Ihr Erfahrung, Ideen, Hinweise?
Vielen Dank,
tantalos
auf einem Mikrotik möchte ich für mehrere Road Warrior L2TP/IPSec-VPN-Zugänge einrichten.
Zunächst hatte ich die oft beschriebene Variante mit PSK genommen, was auch funktionierte, aber den Nachteil hat, dass sich alle Road Warrior denselben PSK teilen, was im Falle des Ausscheidens eines Mitarbeiters aus der Firma nervt, da dann auf allen Geräten aus Sicherheitsgründen der PSK geändert werden müsste.
Also habe ich eine Authentifizierung mittels Zertifikaten ins Auge gefasst. Am liebsten wäre mir dabei, die in v6 eingeführte Möglichkeit von RouterOS zu nutzen, im Mikrotik eine CA zu erstellen und damit eine PKI zu verwalten. Minimalistisch ist dies im Wiki beschrieben, siehe http://wiki.mikrotik.com/wiki/Manual:IP/IPsec#Creating_Certificates .
Ziel der ganzen Sache sollte dann sein, dass ich im Mikrotik ein Zertifikat widerrufen kann und danach keine Verbindung mehr von Geräten, auf denen dieses Zertifikat installiert ist, aufgebaut werden kann.
Grundsätzlich funktioniert nun sehr vieles, d.h. die selbstsignierte CA lässt sich schnell einrichten, Zertifikate ausstellen und auch die Verbindung selbst funktioniert.
Probleme treten beim Widerrufen von Zertifikaten auf. Über ca-crl-host kann ich einen Host für die CRL angeben. Hier mangelt es mir wohl an Verständnis:
Kann der Mikrotik die Rolle des CRL-Hosts übernehmen, d.h. kann ich hier die lokale IP des Mikrotiks nehmen?
Muss dies ein externer Host sein?
Gibt es für einen CRL-Check ein Protokoll?
Brauche ich also einen Server, der das entsprechende Protokoll spricht? Oder wird nur über ein HTTP GET eine Plaintext-Liste geladen und dann vom Router abgeprüft?
Bei mir funktionieren Verbindungen nur, wenn ich keinen ca-crl-host spezifiziere. In diesem Fall kann ich via "issued-revoke" zwar scheinbar erfolgreich Zertifikate widerrufen (diese bekommen das Flag "R"), beachtet wird dieser neue Status jedoch nicht, d.h. ein Verbindungsaufbau ist weiter möglich.
Habt Ihr Erfahrung, Ideen, Hinweise?
Vielen Dank,
tantalos
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 225534
Url: https://administrator.de/contentid/225534
Ausgedruckt am: 22.11.2024 um 08:11 Uhr
12 Kommentare
Neuester Kommentar
Hallo,
Wenn ein Zertifikat zurückgerufen wird, dann kommt es auf diese Liste und
wenn einen VPN Verbindung zustande kommt, wird eben nur überprüft ob das
Zertifikat zurückgezogen wurde oder noch gültig ist. Das ist alles.
dann muss normalerweise die Verbindung unterdrückt werden.
Gruß
Dobby
Muss dies ein externer Host sein?
NeinGibt es für einen CRL-Check ein Protokoll?
Meines Wissens nach nicht!Wenn ein Zertifikat zurückgerufen wird, dann kommt es auf diese Liste und
wenn einen VPN Verbindung zustande kommt, wird eben nur überprüft ob das
Zertifikat zurückgezogen wurde oder noch gültig ist. Das ist alles.
dieser neue Status jedoch nicht, d.h. ein Verbindungsaufbau ist weiter möglich.
Dann ist etwas falsch "gelaufen" denn, wenn ein Zertifikat zurückgerufen wurdedann muss normalerweise die Verbindung unterdrückt werden.
Gruß
Dobby
Das dazu korrespondierende Forums Tutorial hast du gelesen ??
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
1
Danke für den Hinweis.
Das Tutorial hatte ich durchgesehen gehabt. Wie in den meisten Tutorials wird aber auch dort leider nur der Weg über PSK beschrieben.
Mir geht es um Zertifikate.
Das Tutorial hatte ich durchgesehen gehabt. Wie in den meisten Tutorials wird aber auch dort leider nur der Weg über PSK beschrieben.
Mir geht es um Zertifikate.
OK, das ist richtig, die muss man natürlich vorher noch generieren und entsprechend hochladen.
1
Hallo tantalos,
also die CRL wird normalerweise von einer CA generiert und auch von dieser signiert. Sie enthält dabei die Seriennummern der Zertifikate, die zurückgerufen wurden. Diese Liste kann auf einem einfachen Webserver als Datei (*.pem / *.der / *.crl) abgelegt werden. Beim Erzeugen des Zertifikates der CA sollte diese URL als CRL-Uri hinterlegt werden. Der Mikrotik generiert meines Wissens die Liste nicht selber, zumindest habe ich es damit noch nicht hin bekommen(-edit-: siehe weiter unten in den Kommentaren). Was ich bisher gemacht habe ist folgendes: Erzeuge dir die Zertifikate(CA/Serverzertifikat/Clientzertifikate) nicht im Mikrotik sondern z.B. mit XCA oder OpenSSL (Beschreibung für den Mikrotik) und importiere sie dann in den Mikrotik. Ein Revoke eines Zertifikates machst du dann in XCA oder OpenSSL und generierst dort dann die CRL-Datei, welche du dann dann auf den Webserver (den du im Cert der CA angegeben hast) kopierst.
Der Mikrotik lädt sich diese Liste normalerweise bei "Trusted"-Zertifikaten jede Stunde, und das der CA alle 24 Stunden oder bei einem Revoke-Vorgang in seinen Cache (s. hier). Erst dann wird ein widerrufenes Zertifikat auch beachtet.
Was du unbedingt machen solltest ist das aktuellste OS auf den Mikrotik laden, aktuell ROS6.7. In älteren Versionen 6.5 abwärts hatte ich so manche Probleme mit den Zertifikatsfunktionen.
Ich muss dazu irgendwann mal ein Tutorial schreiben, denn die Doku im Web ist dazu doch sehr sehr dürftig, dies ist vor allem Mikrotik's Doku-Faulheit geschuldet...
Grüße Uwe
also die CRL wird normalerweise von einer CA generiert und auch von dieser signiert. Sie enthält dabei die Seriennummern der Zertifikate, die zurückgerufen wurden. Diese Liste kann auf einem einfachen Webserver als Datei (*.pem / *.der / *.crl) abgelegt werden. Beim Erzeugen des Zertifikates der CA sollte diese URL als CRL-Uri hinterlegt werden. Der Mikrotik generiert meines Wissens die Liste nicht selber, zumindest habe ich es damit noch nicht hin bekommen(-edit-: siehe weiter unten in den Kommentaren). Was ich bisher gemacht habe ist folgendes: Erzeuge dir die Zertifikate(CA/Serverzertifikat/Clientzertifikate) nicht im Mikrotik sondern z.B. mit XCA oder OpenSSL (Beschreibung für den Mikrotik) und importiere sie dann in den Mikrotik. Ein Revoke eines Zertifikates machst du dann in XCA oder OpenSSL und generierst dort dann die CRL-Datei, welche du dann dann auf den Webserver (den du im Cert der CA angegeben hast) kopierst.
Der Mikrotik lädt sich diese Liste normalerweise bei "Trusted"-Zertifikaten jede Stunde, und das der CA alle 24 Stunden oder bei einem Revoke-Vorgang in seinen Cache (s. hier). Erst dann wird ein widerrufenes Zertifikat auch beachtet.
Was du unbedingt machen solltest ist das aktuellste OS auf den Mikrotik laden, aktuell ROS6.7. In älteren Versionen 6.5 abwärts hatte ich so manche Probleme mit den Zertifikatsfunktionen.
Ich muss dazu irgendwann mal ein Tutorial schreiben, denn die Doku im Web ist dazu doch sehr sehr dürftig, dies ist vor allem Mikrotik's Doku-Faulheit geschuldet...
Grüße Uwe
2
Hallo Uwe,
danke für Deine Ausführungen. Nun bin ich beruhigt, dass das Problem offenbar nicht nur in mir begründet zu sein scheint
Ein externes Zertifikatshandling hätte ich gerne vermieden, wenn es aber nicht anders geht, dann soll es eben so sein. Ein paar Sachen sind mir aber noch unklar.
Hattest Du das extern erzeugte CA-Zertifikat in den Mikrotik importiert? Ohne einen solchen Import bestünde ja keine Möglichkeit für den Router, die Info zur CRL-URI zu erhalten, oder steht diese auch in den (bspw. über XCA) ausgestellten Zertifikaten?
Falls Du das CA-Zertifikat importiert haben solltest: Hattest Du mal probiert, CA-Aufgaben auch im Mikrotik zu erledigen, bspw. das Ausstellen neuer Zertifikate (klar, dass das nur bedingt hilft, wenn man ein Revoke dann sowieso extern machen muss und damit dann ein im Mikrotik erzeugtes Zertifikat erst in die externe Anwendung exportieren muss - dann wäre es andersherum auch nicht aufwändiger; aber mich würde interessieren, ob die ganze Sache im Mikrotik funktionieren würde)? Im verlinkten Artikel wurde das CA-Zertifikat nicht importiert.
Was mir grundsätzlich nicht klar ist: Wenn man im Mikrotik eine selbstsignierte CA erstellen kann: Welchen Wert hat dies, wenn ich im Router dann keine Zertifikate zurückziehen kann, der Router also eine CRL nicht lokal erstellen und abprüfen kann? Dann bin ich ja für das eigentliche Zertifikatsmanagement, insbesondere für das Zurückziehen, auf eine externe Lösung angewiesen, die es mir auch ermöglicht, eine selbstsignierte CA zu erstellen (bspw. XCA). Darf man vermuten, dass Mikrotik hier noch am Basteln ist und das CRL-Management derzeit einfach noch nicht richtig funktioniert? Was würdest Du sagen?
Und noch eine Frage zur Handhabung in Windows-Clients, die ein VPN zu einem Mikrotik aufbauen sollen: Funktioniert auf den Clients der Import nur über PKCS12-Dateien oder hast Du es anders hinbekommen? Es reicht ja offensichtlich nicht aus, dem Client nur das CA-Zertifikat bekannt zu machen und das für den Client bestimmte Zertifikat zu importieren, da in diesem ja nur der öffentliche Schlüssel enthalten ist. Man muss dem Client auch den privaten Schlüssel für den Client unterschieben, damit dieser im Rahmen der Authentifizierung am Mikrotik mit diesem privaten Schlüssel verschlüsselte Daten an den Mikrotik übertragen kann, die dieser dann anhand des öffentlichen Schlüssels authentifizieren kann. Und den privaten Schlüssel bekommt man auf den Windows-Client nur über den Import einer PKCS12-Datei. Stimmt das so?
Ich probiere das mit XCA im Neuen Jahr auch mal aus und berichte dann.
Danke einstweilen und einen guten Rutsch!
tantalos
danke für Deine Ausführungen. Nun bin ich beruhigt, dass das Problem offenbar nicht nur in mir begründet zu sein scheint
Ein externes Zertifikatshandling hätte ich gerne vermieden, wenn es aber nicht anders geht, dann soll es eben so sein. Ein paar Sachen sind mir aber noch unklar.
Hattest Du das extern erzeugte CA-Zertifikat in den Mikrotik importiert? Ohne einen solchen Import bestünde ja keine Möglichkeit für den Router, die Info zur CRL-URI zu erhalten, oder steht diese auch in den (bspw. über XCA) ausgestellten Zertifikaten?
Falls Du das CA-Zertifikat importiert haben solltest: Hattest Du mal probiert, CA-Aufgaben auch im Mikrotik zu erledigen, bspw. das Ausstellen neuer Zertifikate (klar, dass das nur bedingt hilft, wenn man ein Revoke dann sowieso extern machen muss und damit dann ein im Mikrotik erzeugtes Zertifikat erst in die externe Anwendung exportieren muss - dann wäre es andersherum auch nicht aufwändiger; aber mich würde interessieren, ob die ganze Sache im Mikrotik funktionieren würde)? Im verlinkten Artikel wurde das CA-Zertifikat nicht importiert.
Was mir grundsätzlich nicht klar ist: Wenn man im Mikrotik eine selbstsignierte CA erstellen kann: Welchen Wert hat dies, wenn ich im Router dann keine Zertifikate zurückziehen kann, der Router also eine CRL nicht lokal erstellen und abprüfen kann? Dann bin ich ja für das eigentliche Zertifikatsmanagement, insbesondere für das Zurückziehen, auf eine externe Lösung angewiesen, die es mir auch ermöglicht, eine selbstsignierte CA zu erstellen (bspw. XCA). Darf man vermuten, dass Mikrotik hier noch am Basteln ist und das CRL-Management derzeit einfach noch nicht richtig funktioniert? Was würdest Du sagen?
Und noch eine Frage zur Handhabung in Windows-Clients, die ein VPN zu einem Mikrotik aufbauen sollen: Funktioniert auf den Clients der Import nur über PKCS12-Dateien oder hast Du es anders hinbekommen? Es reicht ja offensichtlich nicht aus, dem Client nur das CA-Zertifikat bekannt zu machen und das für den Client bestimmte Zertifikat zu importieren, da in diesem ja nur der öffentliche Schlüssel enthalten ist. Man muss dem Client auch den privaten Schlüssel für den Client unterschieben, damit dieser im Rahmen der Authentifizierung am Mikrotik mit diesem privaten Schlüssel verschlüsselte Daten an den Mikrotik übertragen kann, die dieser dann anhand des öffentlichen Schlüssels authentifizieren kann. Und den privaten Schlüssel bekommt man auf den Windows-Client nur über den Import einer PKCS12-Datei. Stimmt das so?
Ich probiere das mit XCA im Neuen Jahr auch mal aus und berichte dann.
Danke einstweilen und einen guten Rutsch!
tantalos
Zitat von @tantalos:
Hattest Du das extern erzeugte CA-Zertifikat in den Mikrotik importiert? Ohne einen solchen Import bestünde ja keine Möglichkeit für den Router, die Info zur CRL-URI zu erhalten, oder steht diese auch in den (bspw. über XCA) ausgestellten Zertifikaten?
Ja das solltest du importieren, außer du hast ein Server-Zertifikat ausgestellt in dem ebenfalls die CRL-Uri eingetragen ist, dann reicht dieses. Das CA-Zertifikat hatte ich in XCA erstellt und auch dort direkt die CRL im Zertifikat hinterlegt.Hattest Du das extern erzeugte CA-Zertifikat in den Mikrotik importiert? Ohne einen solchen Import bestünde ja keine Möglichkeit für den Router, die Info zur CRL-URI zu erhalten, oder steht diese auch in den (bspw. über XCA) ausgestellten Zertifikaten?
Falls Du das CA-Zertifikat importiert haben solltest: Hattest Du mal probiert, CA-Aufgaben auch im Mikrotik zu erledigen, bspw.
das Ausstellen neuer Zertifikate (klar, dass das nur bedingt hilft, wenn man ein Revoke dann sowieso extern machen muss und damit
dann ein im Mikrotik erzeugtes Zertifikat erst in die externe Anwendung exportieren muss - dann wäre es andersherum auch
nicht aufwändiger; aber mich würde interessieren, ob die ganze Sache im Mikrotik funktionieren würde)? Im
verlinkten Artikel wurde das CA-Zertifikat nicht importiert.
Das ganze ist leider sehr dürftig von Mikrotik dokumentiert, habe einiges ausprobiert, bin aber immer wieder damit auf die Schnau.. gefallen.das Ausstellen neuer Zertifikate (klar, dass das nur bedingt hilft, wenn man ein Revoke dann sowieso extern machen muss und damit
dann ein im Mikrotik erzeugtes Zertifikat erst in die externe Anwendung exportieren muss - dann wäre es andersherum auch
nicht aufwändiger; aber mich würde interessieren, ob die ganze Sache im Mikrotik funktionieren würde)? Im
verlinkten Artikel wurde das CA-Zertifikat nicht importiert.
Was mir grundsätzlich nicht klar ist: Wenn man im Mikrotik eine selbstsignierte CA erstellen kann: Welchen Wert hat dies,
wenn ich im Router dann keine Zertifikate zurückziehen kann, der Router also eine CRL nicht lokal erstellen und abprüfen
kann? Dann bin ich ja für das eigentliche Zertifikatsmanagement, insbesondere für das Zurückziehen, auf eine
externe Lösung angewiesen, die es mir auch ermöglicht, eine selbstsignierte CA zu erstellen (bspw. XCA). Darf man
vermuten, dass Mikrotik hier noch am Basteln ist und das CRL-Management derzeit einfach noch nicht richtig funktioniert? Was
würdest Du sagen?
Absolut, da steckt der Router noch etwas in den Kinderschuhen. Es gibt dort aber jetzt in diesem Bereich was neues Namens SCEP was das können soll, bin aber noch dabei das ganze mal damit konfiguriert, auszuprobieren.wenn ich im Router dann keine Zertifikate zurückziehen kann, der Router also eine CRL nicht lokal erstellen und abprüfen
kann? Dann bin ich ja für das eigentliche Zertifikatsmanagement, insbesondere für das Zurückziehen, auf eine
externe Lösung angewiesen, die es mir auch ermöglicht, eine selbstsignierte CA zu erstellen (bspw. XCA). Darf man
vermuten, dass Mikrotik hier noch am Basteln ist und das CRL-Management derzeit einfach noch nicht richtig funktioniert? Was
würdest Du sagen?
Und noch eine Frage zur Handhabung in Windows-Clients, die ein VPN zu einem Mikrotik aufbauen sollen: Funktioniert auf den Clients
der Import nur über PKCS12-Dateien oder hast Du es anders hinbekommen? Es reicht ja offensichtlich nicht aus, dem Client nur
das CA-Zertifikat bekannt zu machen und das für den Client bestimmte Zertifikat zu importieren, da in diesem ja nur der
öffentliche Schlüssel enthalten ist. Man muss dem Client auch den privaten Schlüssel für den Client
unterschieben, damit dieser im Rahmen der Authentifizierung am Mikrotik mit diesem privaten Schlüssel verschlüsselte
Daten an den Mikrotik übertragen kann, die dieser dann anhand des öffentlichen Schlüssels authentifizieren kann.
Und den privaten Schlüssel bekommt man auf den Windows-Client nur über den Import einer PKCS12-Datei. Stimmt das so?
Also ich habe bisher das ganze nur im Zusammenhang mit dem ShrewSoft VPN-Client konfiguriert. Da ist es so das du diesem in der Config einmal das Zertifikat der CA, das Zertifikat des Clients und den privaten Schlüssel des Clients jeweils als separate Dateien übergibst.der Import nur über PKCS12-Dateien oder hast Du es anders hinbekommen? Es reicht ja offensichtlich nicht aus, dem Client nur
das CA-Zertifikat bekannt zu machen und das für den Client bestimmte Zertifikat zu importieren, da in diesem ja nur der
öffentliche Schlüssel enthalten ist. Man muss dem Client auch den privaten Schlüssel für den Client
unterschieben, damit dieser im Rahmen der Authentifizierung am Mikrotik mit diesem privaten Schlüssel verschlüsselte
Daten an den Mikrotik übertragen kann, die dieser dann anhand des öffentlichen Schlüssels authentifizieren kann.
Und den privaten Schlüssel bekommt man auf den Windows-Client nur über den Import einer PKCS12-Datei. Stimmt das so?
Danke einstweilen und einen guten Rutsch!
Gleichfalls Grüße Uwe
1
Hallo an Alle und ein frohes neues Jahr,
@colinardo
Ich bin da jetzt nicht so weit involviert wie Du es bist, aber zwei Punkte sind mir dazu noch eingefallen:
- Bei einigen CRLs muss man nachdem man ein Zertifikate auf die CRL gesetzt bzw. geladen hat
den Dienst eventuell neu starten, sonst wird das nicht neue und zu sperrende Zertifikat erkannt bzw.
richtig geladen oder einfach nur ignoriert.
Des weiteren verhält es sich doch auch so, zumindest meines Wissensstandes nach,
dass zum einen einmal ein VPN Server Zertifikat und Schlüssel (CA) erstellt werden muss
und dann zum anderen ein Zertifikat und ein Schlüssel für den VPN Klienten, das Zertifikat
und der Schlüssel für den Klienten kann man auch zusammen in eine Datei abspeichern
entweder für Windows in eine .pem Datei oder für Unix/Linux in eine .pam Datei.
Bei Deinem letzten Bild steht unter Client Private Key File eingetragen, client_uwe.pem
kann es denn sein dass dort nur die Schlüsseldatei, also der Key File selbst angegeben
werden muss?
Gruß
Dobby
@colinardo
Ich bin da jetzt nicht so weit involviert wie Du es bist, aber zwei Punkte sind mir dazu noch eingefallen:
- Bei einigen CRLs muss man nachdem man ein Zertifikate auf die CRL gesetzt bzw. geladen hat
den Dienst eventuell neu starten, sonst wird das nicht neue und zu sperrende Zertifikat erkannt bzw.
richtig geladen oder einfach nur ignoriert.
Des weiteren verhält es sich doch auch so, zumindest meines Wissensstandes nach,
dass zum einen einmal ein VPN Server Zertifikat und Schlüssel (CA) erstellt werden muss
und dann zum anderen ein Zertifikat und ein Schlüssel für den VPN Klienten, das Zertifikat
und der Schlüssel für den Klienten kann man auch zusammen in eine Datei abspeichern
entweder für Windows in eine .pem Datei oder für Unix/Linux in eine .pam Datei.
Bei Deinem letzten Bild steht unter Client Private Key File eingetragen, client_uwe.pem
kann es denn sein dass dort nur die Schlüsseldatei, also der Key File selbst angegeben
werden muss?
Gruß
Dobby
Hallo Dobby,
Grüße Uwe
Zitat von @108012:
Ich bin da jetzt nicht so weit involviert wie Du es bist, aber zwei Punkte sind mir dazu noch eingefallen:
- Bei einigen CRLs muss man nachdem man ein Zertifikate auf die CRL gesetzt bzw. geladen hat
den Dienst eventuell neu starten, sonst wird das nicht neue und zu sperrende Zertifikat erkannt bzw.
richtig geladen oder einfach nur ignoriert.
Klar, der Mikrotik holt sich die Liste von der angegebenen URL in den o.a. Zeitintervallen. Ein Neustart des Mikrotik war bei meinen Tests dazu nicht erforderlich.Ich bin da jetzt nicht so weit involviert wie Du es bist, aber zwei Punkte sind mir dazu noch eingefallen:
- Bei einigen CRLs muss man nachdem man ein Zertifikate auf die CRL gesetzt bzw. geladen hat
den Dienst eventuell neu starten, sonst wird das nicht neue und zu sperrende Zertifikat erkannt bzw.
richtig geladen oder einfach nur ignoriert.
Des weiteren verhält es sich doch auch so, zumindest meines Wissensstandes nach,
dass zum einen einmal ein VPN Server Zertifikat und Schlüssel (CA) erstellt werden muss
und dann zum anderen ein Zertifikat und ein Schlüssel für den VPN Klienten, das Zertifikat
und der Schlüssel für den Klienten kann man auch zusammen in eine Datei abspeichern
entweder für Windows in eine .pem Datei oder für Unix/Linux in eine .pam Datei.
Bei Deinem letzten Bild steht unter Client Private Key File eingetragen, client_uwe.pem
kann es denn sein dass dort nur die Schlüsseldatei, also der Key File selbst angegeben
werden muss?
Alles richtig was du sagst, nur kann eine *.pem Datei auch nur den private Key enthalten. XCA gibt den private Key halt Standardmäßig mit dieser Erweiterung aus anstatt mit *.key .Funktionieren tut es ja damit, es war ja nur eine Illustration für den TO damit er sieht wie es beim ShrewSoft-Client aussieht.dass zum einen einmal ein VPN Server Zertifikat und Schlüssel (CA) erstellt werden muss
und dann zum anderen ein Zertifikat und ein Schlüssel für den VPN Klienten, das Zertifikat
und der Schlüssel für den Klienten kann man auch zusammen in eine Datei abspeichern
entweder für Windows in eine .pem Datei oder für Unix/Linux in eine .pam Datei.
Bei Deinem letzten Bild steht unter Client Private Key File eingetragen, client_uwe.pem
kann es denn sein dass dort nur die Schlüsseldatei, also der Key File selbst angegeben
werden muss?
Grüße Uwe
1
Hallo tantalos,
habe nochmal einige Tests mit den selbstsignierten Zertifikaten des Mikrotik gemacht und kann Erfolg vermelden. Habe dabei rausgefunden das wenn man beim Signieren des CA-Zertifikates als ca-crl-host die externe (die zu der sich die VPN-Clients verbinden) anstatt die interne IP-Adresse des Mikrotik angibt, er nun zurückgerufenen Zertifikate korrekt beachtet wenn man sie mit
Grüße Uwe
habe nochmal einige Tests mit den selbstsignierten Zertifikaten des Mikrotik gemacht und kann Erfolg vermelden. Habe dabei rausgefunden das wenn man beim Signieren des CA-Zertifikates als ca-crl-host die externe (die zu der sich die VPN-Clients verbinden) anstatt die interne IP-Adresse des Mikrotik angibt, er nun zurückgerufenen Zertifikate korrekt beachtet wenn man sie mit
issued-revoke client_1 in der Konsole zurückruft. Probier das mal aus.Grüße Uwe
2Signieren des CA-Zertifikates als ca-crl-host die externe anstatt die interne IP-Adresse des Mikrotik angibt,
Meinst Du damit die IP Adresse des WAN Interfaces, also die feste bzw. statische IP Adresse für denVerbindungsaufbau der VPN Verbindung?
Gruß
Dobby
Zitat von @108012:
> Signieren des CA-Zertifikates als ca-crl-host die externe anstatt die interne IP-Adresse des Mikrotik angibt,
Meinst Du damit die IP Adresse des WAN Interfaces, also die feste bzw. statische IP Adresse für den
Verbindungsaufbau der VPN Verbindung?
genau die zu welcher der Client connected.> Signieren des CA-Zertifikates als ca-crl-host die externe anstatt die interne IP-Adresse des Mikrotik angibt,
Meinst Du damit die IP Adresse des WAN Interfaces, also die feste bzw. statische IP Adresse für den
Verbindungsaufbau der VPN Verbindung?
1
