VPN mit Zertifikaten: LAN-LAN und Client-Einwahl

[steveurkel]

Hallo,

wir nutzen zur Zeit noch (ändert sich dank All-IP bestimmt ) zwei 1721 VPN mit Firmware 8.00.

Die beiden Lancom sind mittels LAN-LAN Kopplung (dynamisches VPN mit UDP-Paket) verbunden.

- da ist die erste Frage die sich stellt: dynamisches VPN basiert auf einer ISDN-Verbindung bei der die öffentlichen IP per UDP-Paket ausgetauscht werden-spätestens bei der Umstellung auf All-IP würde das nicht mehr funktionieren, daher kommen ja nur Zertifikate in Frage-ist doch richtig?

Ich würde das dann ganz gerne auf Einwahl mit Zertifikaten umstellen. Wenn ich die Knowledgebase richtig deute bekommt der Router auf den sich eingewählt wird das Root-Zertifikat der CA. Dementsprechend dann die Clients das von der Root CA unterschriebene Client-Zertifikat.

-die zweite Frage: ich muss doch dann den Router der sich zu dem anderen hin verbindet zertifikatstechnisch so behandeln wie einen Client? (und ihm ein Client-Zertifikat der Root-CA geben die im Zielrouter hinterlegt ist)

Jetzt sollen sich auch mehrere PCs/Ipads und Co auf -beiden- Routern wahlfrei per VPN einwählen können. Bisher geschieht die Einwahl im Aggressive-Mode (für IOS+Mac zusätzlich mit XAUTH) was ja nicht mehr sicher ist, daher könnte/sollte man das ja hier auch auf Zertifikate umstellen.

-die dritte Frage: wie stell ich das am geschicktesten an? Auf dem Haupt-Router wäre das ja ganz einfach: einfach weitere Client-Zertifikate ausstellen damit sich Laptop/Mac+Ipad dort einwählen können. Muss ich dem Client-Router einfach ein eigenes Root-Zertifikat in den VPN Container2 hochladen und die mobilen Clients dann mit passenden Client-Zertifikaten dagegen authentifizieren?

Oder kann man bei beiden Router in Container1 das jeweils eigene Root-Zertifikat hochladen und beiden Routern dann das jeweils passenden Client-Zertifikat dazu in Container zwei laden so das man sich bei der mit einer Anpassung der Konfiguration letztlich aussuchen kann welcher Router sich bei wem einwählt?

Kann ich dem Router eigenlich auch ein weiteres Root-Zertifikat mitgeben so das ich irgendwann mal Clients von externen Mitarbeitern mit den dazugehörigen Zertifikaten aussperren kann ohne "interne Mitarbeiter" bzw die LAN-LAN-Kopplung zu beeinträchtigen?


Danke!

[Bernie137]

Hallo steveurkel,

dynamisches VPN basiert auf einer ISDN-Verbindung bei der die öffentlichen IP per UDP-Paket ausgetauscht werden

Aber nicht, wenn eine der beiden Seiten eine feste IP hat. Das funktioniert dann völlig ohne ISDN und ohne Zertifikate als dynamisches VPN.

spätestens bei der Umstellung auf All-IP würde das nicht mehr funktionieren, daher kommen ja nur Zertifikate in Frage-ist doch richtig?

Haben wirklich beide Seiten eine dynamische IP, dann helfen Zertifikate auch nicht weiter. Woher weis der VPN Partner, welche aktuelle IP er gerade anrufen soll? Da bliebe nur ein dynDNS Dienst übrig. Das kann man mit oder ohne Zertifikate bewerkstelligen.

Wenn ich die Knowledgebase richtig deute bekommt der Router auf den sich eingewählt wird das Root-Zertifikat der CA.

Niemals. Das ist immer das Heiligtum der Zertifizierungsstelle und wird überhaupt nicht für einen Verbindungsaufbau benutzt. Das Zertifikat verbleibt in der Zertifizierungsstelle und dient in erste Linie dazu, weitere Zertifikate auszustellen. Welche Anleitung hast Du Dir denn angesehen aus der Knowledgebase?

-die dritte Frage: wie stell ich das am geschicktesten an? Auf dem Haupt-Router wäre das ja ganz einfach: einfach weitere Client-Zertifikate ausstellen damit sich Laptop/Mac+Ipad dort einwählen können.

Das bezweifle ich, dass das so geht. Du verwechselst das bestimmt mit "Lancom Smart Certificate", was aber nur ab Firmware 9.10 möglich ist und das hast Du nicht.

Muss ich dem Client-Router einfach ein eigenes Root-Zertifikat in den VPN Container2 hochladen und die mobilen Clients dann mit passenden Client-Zertifikaten dagegen authentifizieren?

Oder kann man bei beiden Router in Container1 das jeweils eigene Root-Zertifikat hochladen und beiden Routern dann das jeweils passenden Client-Zertifikat dazu in Container zwei laden so das man sich bei der mit einer Anpassung der Konfiguration letztlich aussuchen kann welcher Router sich bei wem einwählt?

Wie gesagt, es geht nicht um Root Zertifikate, sondern um Zertifikate, die für VPN-Verbindungen taugen. Die Benennung meine ich, ist je nach PKI Struktur unterschiedlich bzw. resultiert aus Vorlagen. Das können Clientzertifikate sein, können aber auch ganz anders bezeichnet werden. Stell es Dir so vor: Es gibt eine Root-CA, diese stellt zwei Zertifikate aus, eines für Router1 und eines für Router2. Diese können dann untereinander zertifikatsbasierend VPN betreiben - beide vertrauen der gleiche CA. Jedem VPN Client, welchem Du ebenfalls ein Zertifikat dieser CA verpasst, kann dann mit beiden Routern zertifikatsbasierendes VPN betreiben.

Womit möchtest Du denn überhaupt Zertifikate erstellen?

vg Bernie

[steveurkel]

Hallo Bernie,

Ich würde mangels der 25er VPN Option und weil die Firmware das nicht hergibt XCA nutzen. Dazu habe ich mir den KB Eintrag mit der Nummer 1108.1713.4236.RHOO -V 1.70 "Erstellen von X.509 Zertifikaten mit XCA" angesehen. (kann das hier vom Smartphone leider nicht verlinken)In diesem Beispiel wird das Root-Zertifikat in den Router geladen, das darunterliegende Client-Zertifikat kann man dann mit einem VPN-Tool nutzen.

Leider haben ausnahmslos alle beteiligten dynamische IP-Adressen, die zugehörige IP wird über die Namensauflösung ermittelt. (Hatte ich vergessen dazuzuschreiben)

Du meinst also ich kann eine CA mit einem Root-Zertifikat aufsetzen, für alle beteiligten damit unterschriebene Client-Zertifikate erstellen und auf Router und Clients verteilen?

[steveurkel]

inzwischen hab ich selbst noch mal Google bemüht und es scheint das ich mich auf dem Holzweg war. Das Root-Zertifikat kommt natürlich nicht in den Router.

Schade das es in der KB kein passendes Beispiel gibt. Ich habe aber hier etwas gefunden:

http://www.mhslabs.de/index.php

Etwas ahnungslos bin ich jetzt nur noch wie man das bei LAN-LAN-Kopplung konfiguriert. Sicherlich auch mit einem Client-Zertifikat...

[Bernie137]

Etwas ahnungslos bin ich jetzt nur noch wie man das bei LAN-LAN-Kopplung konfiguriert. Sicherlich auch mit einem Client-Zertifikat...

Korrekt. Dann in den VPN-Container (VPN1) hochladen. Per putty mit dem Router verbinden und mit "show vpn cert" prüfen, was unter "Subject: ..." steht. Das ist dann die lokale Identität des Routers, z.B: "CN=VPN-ZENTRALE" - je nachdem, wie es in XCA benannt wurde und ob noch zusätzlich OUs angegeben wurden, wird der Ausdruck dann entsprechend länger.

vg Bernie

[Hagen2000]

Hallo steveurkel,

Wenn ich die Knowledgebase richtig deute bekommt der Router auf den sich eingewählt wird das Root-Zertifikat der CA.

Niemals. Das ist immer das Heiligtum der Zertifizierungsstelle und wird überhaupt nicht für einen Verbindungsaufbau benutzt. Das Zertifikat verbleibt in der Zertifizierungsstelle und dient in erste Linie dazu, weitere Zertifikate auszustellen. Welche Anleitung hast Du Dir denn angesehen aus der Knowledgebase?

Hallo Bernie,

das verstehe ich nicht. Root-Zertifikate sind doch kein Heiligtum sondern werden doch öffentlich verteilt, damit beispielsweise ein Browser ihm angebotene Gerätezertifikate überprüfen kann.

Wie sollen denn die beteiligten Router die Gerätezertifikate überprüfen ohne das Root-Zertifikat zu kennen?

Oder meintest Du den privaten Schlüssel der CA?

[Bernie137]

Hallo Hagen,

Oder meintest Du den privaten Schlüssel der CA?

Ja, ich meine den privaten Schlüssel. Und den exportiert/importiert man ja bei PKCS #12 mit.

Wie sollen denn die beteiligten Router die Gerätezertifikate überprüfen ohne das Root-Zertifikat zu kennen?

Bei zwei Client Zertifikaten wissen beide, von welcher root sie ausgestellt wurden - nämlich von der Gleichen. Denn beide Client Zertifikate besitzen neben ihrem privaten Schlüssel (den sie zum verschlüsseln der Verbindung benötigen) den gleichen öffentlichen Schlüssel.

vg Bernie

[Hagen2000]

Ja, ich meine den privaten Schlüssel. Und den exportiert/importiert man ja bei PKCS #12 mit.

Da stimme ich nicht zu. In der PKCS #12-Kette sind enthalten:
- Der Private Schlüssel des Geräts
- Das Gerätezertifikat
- Das Root-Zertifikat (aber nicht dessen privater Schlüssel).

Das deckt sich dann auch mit dem KB-Artikel 1307.0415.5125.RHOO - V1.50 (VPN LAN-LAN Kopplung mit Zertifikaten zwischen zwei LANCOM Routern).

Bei zwei Client Zertifikaten wissen beide, von welcher root sie ausgestellt wurden - nämlich von der Gleichen. Denn beide Client Zertifikate besitzen neben ihrem privaten Schlüssel (den sie zum verschlüsseln der Verbindung benötigen) den gleichen öffentlichen Schlüssel.

Da stimme ich ebenfalls nicht zu. Beide Client-Zertifikate haben unterschiedliche private und damit auch unterschiedliche öffentliche Schlüssel. Unterschrieben sind sie hingegen mit dem selben Root-Zertifikat und daher wird dieses auch zur Überprüfung der Zertifikatskette benötigt.

[steveurkel]

Ich zitiere mal aus dem Handbuch:

Durch das Aktivieren der vereinfachten Zertifikate-Einwahl können sich alle Clients mit einem gültigen Zertifikat, das vom Herausgeber des im Gerät befindlichen Root-Zertifikats signiert ist, in das entsprechende Netzwerk einwählen

Es wird also nicht mehr nach dem Subject ausgewertet welcher User sich einwählt sondern nur nach dem signierten Zertifikat das auch noch gültig sein muss.

[Bernie137]

Hallo Hagen,

Da stimme ich ebenfalls nicht zu. Beide Client-Zertifikate haben unterschiedliche private und damit auch unterschiedliche öffentliche Schlüssel.

Ja, das mag stimmen. Muss mir die Thematik auch mal wieder reinziehen. War wohl nicht mein Tag gestern.

Unterschrieben sind sie hingegen mit dem selben Root-Zertifikat und daher wird dieses auch zur Überprüfung der Zertifikatskette benötigt.

De fakto funktioniert VPN zwischen zwei Routern mit zwei XCA Client Zertifikaten, ohne das ein Root Zertifikat benötigt wird - das läuft so beim mir mit XCA.

Da stimme ich nicht zu. In der PKCS #12-Kette sind enthalten:
- Der Private Schlüssel des Geräts
- Das Gerätezertifikat
- Das Root-Zertifikat (aber nicht dessen privater Schlüssel).

Dann exportiere bitte mal das Root Zertifikat per PKCS#12, dann lege mit XCA eine völlig neue (leere) Datenbank an und importiere das Root Zertifikat wieder. Nun kannst Du in der "geklonten" PKI weitere Zertifikate ausstellen und vermutlich werden alle Zertifikate, welche in der originalen DB existieren, den neuen Zertifikaten aus der (feindlich übernommen) Klon-DB vertrauen. Also ich würde das Root Zertifikat nicht verwenden, damit es womöglich eine andere Person noch in den Router laden soll. Ein Sichern aus dem Router wieder heraus wird ja auch angeboten. Allerdings ist mir das noch nie gelungen.

vg Bernie

[Micha81]

Dann exportiere bitte mal das Root Zertifikat per PKCS#12, dann lege mit XCA eine völlig neue (leere) Datenbank an und importiere das Root Zertifikat wieder. Nun kannst Du in der "geklonten" PKI weitere Zertifikate ausstellen und vermutlich werden alle Zertifikate, welche in der originalen DB existieren, den neuen Zertifikaten aus der (feindlich übernommen) Klon-DB vertrauen. Also ich würde das Root Zertifikat nicht verwenden, damit es womöglich eine andere Person noch in den Router laden soll. Ein Sichern aus dem Router wieder heraus wird ja auch angeboten. Allerdings ist mir das noch nie gelungen.

vg Bernie

Das wird nicht funktionieren. Ein Root-Zertifikat das aus einer PKCS#12-Datei importiert wird, wird als nicht vertrauenswürdig eingestuft. Damit lassen sich keine Client- oder Serverzertifikate ausstellen. Nur ansehen, nicht anfassen ...

[Bernie137]

Dann mach einen Rechtsklick auf "Vertrauen" bitte.

[Hagen2000]

Um mit einem Zertifikat A ein weiteres Zertifikat B "auszustellen" (d.h. zu signieren), wird immer der private Schlüssel des Zertifikats A benötigt. Diesen kann und sollte man auch innerhalb des xca-Programms mit einem Passwort schützen. So wird man automatisch auf jede Verwendung des privaten Schlüssels aufmerksam gemacht, weil man dann nämlich das Passwort eingeben muss. Der private Schlüssel des Zertifikats A muss unbedingt geheim gehalten werden, nicht jedoch das Zertifikat A selbst.

Anm.: Zertifikat A ist nicht notwendiger Weise ein Stammzertifikat, wenn mit Zwischenzertifizierungsstellen gearbeitet wird. Für eine kleine PKI kann man jedoch auf Zwischenzertifizierungsstellen verzichten und direkt mit dem Stammzertifikat die Gerätezertifikate (= Endstellenzertifikate) signieren.

Beim Erstellen einer PKCS#12-Datei muss man daher aufpassen, nur das eigentliche Zertifikat zu exportieren und nicht versehentlich den privaten Schlüssel mit zu exportieren! Mir sind daher die separaten PEM-Dateien (mit Endungen .crt, .key usw.) lieber als die .p12-Container.

Root-Zertifikate (= Stammzertifikate) werden keinesfalls geheim gehalten, sondern vielmehr öffentlich verteilt und regelmäßig über Browser-Updates (z.B. Firefox) oder Betriebssystem-Updates (z.B. Stammzertifikate für Windows, Mac OS, Linux) verteilt. Die Stammzertifikate kann jedermann jederzeit in seinem Browser oder der Zertifikatsverwaltung ansehen und auch exportieren. Deswegen kann er noch lange nicht damit eigene Zertifikate signieren, weil ihm nämlich die privaten Schlüssel nicht bekannt sind.

Das mit dem "Vertrauen" aussprechen ist beispielsweise für ein selbst erstelltes Stammzertifikat erforderlich, das händisch den Stammzertifikaten hinzugefügt wird und nicht über den normalen Updatemechanismus auf den Rechner gelangt. Warum es diese Einstellung innerhalb des xca-Programms gibt, leuchtet mir nicht ein, denn warum sollte man einem selbst erstellten Stammzertifikat nicht vertrauen?

[Micha81]

Dann mach einen Rechtsklick auf "Vertrauen" bitte.

Das kann man zwar machen, bringt aber nichts. Denn die PKCS#12 enthält nicht den privaten Schlüssel des Root-Zertifikats. Und ohne den geht es einfach nicht. Daher wird dein Klon-Versuch ins Leere laufen.

[Bernie137]

Hallo,

schön, dass wir miteinander zu dem Thema diskutieren hier. Ist ein spannendes Thema.

In der Anleitung der Lancom KB wird bei Punkt 4.2 das Format PCKS#12 verwendet, weil man dieses Format für den Import in den Lancom Router benötigt. XCA kann aber nur *exportieren, wenn man auch den privaten Schlüssel mit exportiert - egal ob man dafür noch ein separates Passwort innerhalb von XCA vergibt. Dieses Passwort wird halt beim Export verlangt, oder aber der Export abgebrochen.

XCA_Export.jpg

Für das exportierte Zertifikat samt privaten Schlüssel muss dann ein Passwort vergeben werden - eben um den privaten Schlüssel zu schützen. Genau dieses Passwort benötigt man aber wieder, um den Upload in den Router zu machen. Ist es im Router, dann ist dort auch der private Schlüssel eben dieses Root Zertifikates mit abgelegt. Jeder, der das Router Passwort kennt, kann wiederum einen Export durchführen. Zumindest wird das in den Tools angeboten - ich hatte bisher damit keinen Erfolg und hatte auch schon an andere Stelle hier nachgefragt, aber bisher hat sich dazu niemand geäußert.

Die Anleitung in der Lancom KB ist richtig im Sinne von funktional. Dennoch finde ich es bedenklich, wenn man gerade das Root Zertifikat samt seinen privaten Schllüssel in Umlauf bringt. Das war es, was ich damit sagen wollte. Ich habe nur die Begrifflichkeiten nicht korrekt verwendet.

Um mit einem Zertifikat A ein weiteres Zertifikat B "auszustellen" (d.h. zu signieren), wird immer der private Schlüssel des Zertifikats A benötigt. Diesen kann und sollte man auch innerhalb des xca-Programms mit einem Passwort schützen. So wird man automatisch auf jede Verwendung des privaten Schlüssels aufmerksam gemacht, weil man dann nämlich das Passwort eingeben muss. Der private Schlüssel des Zertifikats A muss unbedingt geheim gehalten werden, nicht jedoch das Zertifikat A selbst.

Ja, ich bin ganz Deiner Meinung.

Beim Erstellen einer PKCS#12-Datei muss man daher aufpassen, nur das eigentliche Zertifikat zu exportieren und nicht versehentlich den privaten Schlüssel mit zu exportieren! Mir sind daher die separaten PEM-Dateien (mit Endungen .crt, .key usw.) lieber als die .p12-Container.

Aber das nützt nichts für den Lancom Router.

Root-Zertifikate (= Stammzertifikate) werden keinesfalls geheim gehalten, sondern vielmehr öffentlich verteilt und regelmäßig über Browser-Updates (z.B. Firefox) oder Betriebssystem-Updates (z.B. Stammzertifikate für Windows, Mac OS, Linux) verteilt. Die Stammzertifikate kann jedermann jederzeit in seinem Browser oder der Zertifikatsverwaltung ansehen und auch exportieren. Deswegen kann er noch lange nicht damit eigene Zertifikate signieren, weil ihm nämlich die privaten Schlüssel nicht bekannt sind.

Und genau der kommt beim Export von XCA mit heraus bzw. wüsste ich nicht, wie es verhindert werden könnte. Selbst wenn man es an der Stelle den Export des privaten Schlüssels verhindern könnte, im Ref Manual steht ganz konkret, dass im Gerät ein privater Schlüssel benötigt wird. Und wenn mit dem Root Zertifikat selbst als Gerätezertifikat gearbeitet wird, ist es nun mal dessen privater Schlüssel, der benötigt wird.

Das kann man zwar machen, bringt aber nichts. Denn die PKCS#12 enthält nicht den privaten Schlüssel des Root-Zertifikats. Und ohne den geht es einfach nicht. Daher wird dein Klon-Versuch ins Leere laufen.

Du siehst es selbst im Bild. Natürlich musst Du es im Klon auch wieder mit importieren, aber das ist kein Hindernis.

vg Bernie