VPNCenter 1.2-2414 - Zertifikate funktionieren nicht mehr richtig!

[DRIV3R]

Ich mache hier mal einen neuen Thread zum Thema VPNCenter 1.2-2414 auf.
Der ursprüngliche Thread war ja eigentlich für 1.2-2413 gedacht. --> HIER ZU FINDEN <--

Ich habe heute den ganzen Tag experimentiert und muss sagen, dass ich doch irgendwie enttäuscht bin, was Synology da mit dem Update des VPNCenters gemacht hat.

Punkt 1 --> Nach vielen Tests ist es NOTWENDIG, nach einspielen eines SSL Zertifikats und bevor man sich die Konfiguration und das Zertifikat exportiert, die Diskstation neu zu starten. Wenn man nicht neu startet, erhält man nur ältere eingespielte Zertifikate, auch wen unter "Sicherheit" das aktuelle Zertifikat richtig angezeigt wird. Das VPNCenter exportiert aber irgendein altes Zertifikat.

Punkt 2 --> Der aber entscheidende, gravierendere Punkt ist, dass scheinbar von VPNCenter beim klick auf exportieren das FALSCHE Zertifikat exportiert wird. Ich habe getestet und getestet und getestet und habe einfach keine Connection hin bekommen.
Nun hab ich mir mal das exportierte Zertifikat, was ich unter VPNCenter per klick auf exportieren bekommen habe, genauer angeschaut. Und die ist NICHT mein Zertifikat, mit meinem Namen usw. sondern scheinbar das intermediate oder so. Denn im exportierten Zertifikat aus dem VPNCenter heißt es: ausgestellt für "StartSSL". Normalerweise steht dort aber: ausgestellt für: meinname.topleveldomain.123

Kann das wirklich sein. Oder bin ich der einzige mit diesen Ergebnissen.
Bin auch bereit die DS auf Werkseinstellungen zu bringen, wenn ihr andere Erfahrungen gemacht habt.
Ich kann nur sagen, dass unter 1.2-2412 alles super lief. Unter 1.2-2414 ist alles murks.

Vielleicht entwickelt sich ja eine kleine Diskussion, die eventuell meine Ergebnisse untermauert.
Ich werde mich mal an den Synology Support wenden.

Allen einen schönen Abend
Timo

 

[till213]

Also bei mir hat das mit der aktuellen DSM 4.3 (Update 2) mit allen aktuellen Paketen funktioniert (ebenfalls erst nach einem Neustart der DiskStation): ich habe mir via Systemeinstellungen -> DSM -> Zertifikat ein neues, selbstsigniertes Zertifikat erstellt, DS neu gestartet und dann die Konfiguration als ZIP Archiv mittels VPN Server -> OpenVPN -> Konfiguration exportieren exportiert. Die darin enthaltene ca.crt enthielt mein Zertifikat (z.B. einfach zu überprüfen auf Mac OS X mittels "Schlüsselbundverwaltung".

Als proof-of-concept habe ich die Daten der ca.crt (aus dem heruntergeladenen ZIP-Archiv) in meine iOS.ovpn Konfigurationsdatei (von der DiskSation von /var/packages/VPNCenter/target/etc/openvpn/keys/iOS.opvn - diese Datei enthielt noch das alte, von Synology selbst signierte Zertifikat!), diese Konfigurationsdatei via iTunes auf das iPhone gesynct und erfolgreich mittels OpenVPN Klient mit meiner DiskStation via OpenVPN verbunden (als Gegentest hatte ich zuvor daselbe mit dem alten Zertifikat versucht, und der OpenVPN Klient hatte "erfolgreich" die Verbindung verweigert).


Siehe auch meinen eigenen thread hierzu: http://www.synology-forum.de/showthread.html?53173-OpenVPN-und-heartbleed-Zertifikate-erneuern

 

[till213]

Ach ja, wie gesagt unter der aktualisierten DSM 4.3 - dort heisst mein installiertes Paket übrigens "VPN Server" und läuft in der aktuellen Version 1.2-2318.

Aber deinen genannten Versionsnummern zufolge (und der Tatsache, dass du dich auf "VPNCenter" beziehst) nehme ich an, dass du die DSM 5.0 am Start hast. Dazu kann ich nicht viel sagen

 

[DRIV3R]

Hi Till,

danke für deinen Beitrag. Ja ich habe DSM 5.0 drauf.
Ein selbst signiertes Zertifikat, erstellt per DSM unter Sicherheit, läuft bei mir auch. Wenn ich das im VPN Bereich exportiere, kann ich mich verbinden.
Ich habe aber eine Zertifikat von StartSSL. Ich erstelle key und CSR per DSM oder Terminal (beides versucht) und übermittelt diese dann an StartSSL.
Zurück bekomme ich mein eigenes Zertifikat und das intermediate von StartSSL.
Diese beiden und meinen key lade ich dann über DSM auf die Diskstation hoch.
Und da tritt dann der Fehler auf. Egal ob ich neustarte oder nicht. Wenn ich im VPN Menü export drücke, bekomme ich ein Zertifikat (ca) und die config für openvpn.
Wenn ich das ca dann am Mac öffne, dann ist "ausgestellt für" nicht auf mich, sondern auf StartSSL und die Gültigkeit ist nicht wie üblich ein Jahr sondern viele Jahre.

Es scheint also etwas falsches im VPN Menü exportiert zu werden. Was auch immer. Ich hab drei SSL Zertifikate von StartSSL, davon liefen zwei Stück unter DSM 5.0 und VPNCenter 2412. Unter 2414 laufen die Zertifikate auch, ich kann aber mit den exportierten Zertifikaten im VPNCentern nichts anfangen, weil es nicht die richtigen sind.
Deshalb wohl auch die Fehler beim Connect.

Ich habe bei weiteren Test mal geschaut, was passiert, wenn ich die Zertifikate im Bereich Sicherheit wieder exportiere.
Nutze ich ein selbst signiertes, bekomme ich dort 2 Dateien exportiert. Spiele ich mein Zertifikat, key und intermediate ein, bekomme ich 4 oder 5 Dateien exportiert (hier jetzt im Bereich Sicherheit unter DSM gemeint, nicht im VPNCenter)

Leider hat sich Synology noch nicht bei mir gemeldet. Solange nutze ich ein selbst signiertes Cert.
Würde aber doch gerne meine eigenen Zertifikate benutzen.

Oder kennt vielleicht jemand die genauer Ordnerstruktur per terminal?
Dann würde ich die entsprechenen Files selber suchen. Ich brauche ja nur das "richtige" Zertifikat wieder. Wo finde ich das, wenn der export mir das falsche ausspuckt.

Grüße
Timo

 

[dany]

Du findest die OpenVPN Zertifikate im folgenden Ordner:

/volume1/@appstore/VPNCenter/etc/openvpn/keys

bez. in der OpenVPN Conf hast du folgende Pfade:

dh /var/packages/VPNCenter/target/etc/openvpn/keys/dh1024.pem
ca /var/packages/VPNCenter/target/etc/openvpn/keys/ca.crt
cert /var/packages/VPNCenter/target/etc/openvpn/keys/server.crt
key /var/packages/VPNCenter/target/etc/openvpn/keys/server.key

Da ich nur selbst-signierendes Zertifikat nutze kann ich dir nicht weiterhelfen.

Gruss Dany

 

[strassenbahn]

Hallo Zusammen,

bei meiner DS funktioniert OpenVPN auch nicht. Auch Paket-Deinstallation, mit anschließendem löschen des Verzeichnisses `/usr/syno/etc/packages/VPNCenter/openvpn', Neustadt der Maschine und Neuinstallation des VPN-Paketes brachte nichts. Allein, bis sich OpenVPN starten ließ brauchte es mehrere dieser Deinstallation- und Installations-Vorgänge. Ich habe nun das Paket wieder gelöscht. Dabei musste ich feststellen das im Pfad '/usr/syno/etc/packages/' von jedem je installiertem Paket Verzeichnisse zurückbleiben. Ich hasse das. Wie unter Windows, grausam. Ich habe alle leere Pfade gelöscht. Übet nebenbei den Umgang mit der Console wie früher unter M$-DOS 3.x, Toll!!
Wenn mein dEnglisch besser währe würde ich ja einen langen, sich einprägenden Fehlerreport an Synologie schreiben, wenn ...
Nun, das Packe ist gelöscht, und auch wenn es mir nicht gefällt, muss jetzt die Fritzbox den VPN-Server spielen.

Viele Grüße

Meinolf

 

[Micha-J]

Abend,

ich schließe mich hier an. Habe genau das gleiche Problem mit dem VPN Server.
Welches der Zertifikate müsste ich denn nun nehmen und in den iOS Client einpflegen, damit das Ganze wieder funktioniert?


Grüße
Michael

 

[DRIV3R]

Schön zu hören, dass ich nicht der einzige bin.
Aber bis jetzt muss ich euch wohl enttäuschen.
Ich habe viele Stunden mit der Version 1.2-2414 getestet und es läuft NICHT mit eigenen Zertifikaten, z.B. StartSSL.
Nur selbst per DSM erstellte Zertifikate lassen sich via VPNCenter exportieren.

Klar, sowas kann bei nem Update passieren. Aber ich habe am 22.04 schon Synology informiert. Bis heute aber keine Antwort. Normalerweise antwortet Synology innerhalb 2-4 Tagen. In der automatischen Antwort stand 3-5 Tage. Naja vielleicht gibt es noch eine Rückmeldung.

Es ist echt verrückt, dass man beim export per VPNCenter irgendein eingespieltes Zertifikat erhält, nur nicht sein eigenes.
Aber auch der Versuch, die Zertifikate per Terminal rauszukopieren und dann in OpenVPN zu benutzen, hat auch nicht funktioniert.
Wenn die in 2414 nicht auch ein Bugfix bzgl. Heartbleed drin hätten, würd ich ja wieder auf 2412 gehen. Dort lief alles 1A, auch der export der RICHTIGEN Zertifikate.


Wünsch euch nen schönen Abend. Und wenn jemand das richtige Zertifikat findet, bzw. einen Weg, wie ein eigenes, eingespieltes Zertifikat erfolgreich für OpenVPN genutzt werden kann....... her mit der Lösung

Timo

 

[7ynolge]

Hallo Zusammen,

ich lese hier seit Wochen fleissig im Forum mit.

Ich kann die ganzen Probleme überhaupt nicht bestätigen.

Ich hatte auf meiner alten 212j immer von außen per openvpn zugreifen können.

Nach der Migration auf eine neue Syno habe ich alles importiert.

Dann habe ich sämtliche Updates des vpn Pakets inklusive der neuesten Version von DSM 5 gemacht.

Neustart, und das alte Zertifikat mit meinen Einstellungen funktioniert weiterhin problemlos.

Übersehe ich ein Sicherheitsrisiko??

Danke für Eure Antworten.

Vg

 

[DRIV3R]

Hi 7ynologe,

also wenn du noch alte Zertifikate verwendest, die du vor dem Heartbleed Update ( also DSM 5 4458 Update 2) verwendet hast, solltest du diese dringend tauschen.
Ebenso wie deine Passwörter. Dazu der passende Beitrag von Synology:

Nach dem Update von DSM empfehlen wir die Erneuerung des SSL-Zertifikats, da Ihre SSL-Verschlüsselungsschlüssel gekapert worden sein könnten.

Als Vorsichtsmaßnahme können Sie Ihre DSM-Passwörter ändern, auch wenn es keine Beweise dafür gibt, dass Ihre Daten über diese Sicherheitslücke abgerufen wurden

Quelle: http://www.synology.com/de-de/support/security

Wobei du aufpassen musst, dass das einspielen von eigenen Zertifikaten (z.B. StartSSL) zurzeit zwar möglich ist, aber ein sauberer Konfigurations-Export per VPNCenter aber nicht richtig funktioniert. Das geht bis jetzt scheinbar nur mit per DSM selbst signierten Zertifikaten.

 

[7ynolge]

Danke fuer die Antwort.

Ja ich habe mein Passwort nach dem Heartbleed Update geaendert.

Da ich aber keine aussergewoehnlichen Verbindungen in den Aufzeichnungen der Syno sehe, oder gar ungewoehnliche uploads von meinem Server sehe, glaube ich nicht davon betroffen zu sein.

Blockierte IP's von der Firewall nach Fehlversuchen auch nicht.

Also fuehle ich mich sicher.

Vg

 

[DRIV3R]

Meiner Meinung nach, reicht das nicht aus. Aber das musst du natürlich selber wissen.
Ich habe da hier im Forum mal einen kleinen Beitrag zu geschrieben.

Sagen wir mal frei übersetzt durch den Bug konnte ich mir eine Kopie deines Haustürschlüssels machen.
Nun ist der Bug zu, ich kann mir keine Kopie mehr machen. Aber:
Ich hab deinen Schlüssel ja schon. Und damit geh ich jetzt munter ein und aus bei dir.

Wenn du dein Passwort geändert hast, den Schlüssel aber nicht, bringt das nichts.

Und der Heartbleed Bug steckte so tief im System, dass du weder Loginversuche siehst, noch ne Firewall hilft.

Gruß
Timo

 

[DRIV3R]

Ich hab noch einmal eine Frage an alle, die ihre eigenen Zertifikate mit dem VPNCenter 2414 zum laufen bekommen.
Ich habe heute wieder 2 Stunden getestet. Egal wie und was ich anstelle, das VPNCenter exportiert mir nur die config und das intermediate. Hab dann die openvpn config und ein ca.crt.

Das ca.crt ist 100%ig nicht mein Zertifikat, was ich hochgeladen habe, sondern das intermediate, was ich ja auch von StartSSL bekommen habe.
Also meine Frage an die, die ihre eigenen Zertifikate mit 2414 erfolgreich nutzen.

Habt ihr auch ein intermediate hochgeladen, oder nur den key und das Zertifikat?
Die Frage richtet sich natürlich an alle, die NACH dem Update auf das VPNCenter 2414 auch die Zertifikate neu exportiert haben. (So wie Synology das gefordert hat.)

Ich danke euch

Gruß
Timo

 

[mausbieber]

Hallo,
ich stand vor dem gleichen Problem und habe für mich eine Lösung gefunden.
Ich werde die Schritte im folgenden wiedergeben, eventuell hilft Euch dies weiter:
1. Ausgangsverzeichnis /usr/syno/etc/ssl
2. Die Datei mkcert.sh unter mkcert.openvopn.sh kopieren
3. Die folgenden 3 Zeilen in der Kopie ändern
sslcrtdir="/usr/syno/etc/ssl/ssl.crt" --> sslcrtdir="/usr/syno/etc/ssl/mssl.crt"
sslcsrdir="/usr/syno/etc/ssl/ssl.csr" --> sslcsrdir="/usr/syno/etc/ssl/mssl.csr"
sslkeydir="/usr/syno/etc/ssl/ssl.key" --> sslkeydir="/usr/syno/etc/ssl/mssl.key"
4. Falls noch Clientzertifikate gebraucht werden die Zeilen der Schritte 4,5,6 duplizieren und in den Duplikaten überall!! server durch client ersetzen
5. Dann ./mkcert.openvpn.sh im Verzeichnis /usr/syno/etc/ssl starten.
6. Es werden drei Verzeichnisse neu angelegt (mssl.crt, mssl.key und mssl.csr), wo nun jeweils ca.*,server.*,(client.*) liegt
7. Da bei jedem Neustart ca.crt,server.crt und server.key in /usr/syno/etc/packages/VPNCenter/openvpn/keys/ überschrieben werden,
muss man den Verweis in /usr/syno/etc/packages/VPNCenter/openvpn/openvpn.conf anpassen:
#ca /var/packages/VPNCenter/target/etc/openvpn/keys/ca.crt
#cert /var/packages/VPNCenter/target/etc/openvpn/keys/server.crt
#key /var/packages/VPNCenter/target/etc/openvpn/keys/server.key
ca /usr/syno/etc/ssl/mssl.crt/ca.crt
cert /usr/syno/etc/ssl/mssl.crt/server.crt
key /usr/syno/etc/ssl/mssl.key/server.key
8. in der exportierten openvpn.zip wird auch das falsche ca.crt eingebunden, dieses ist durch /usr/syno/etc/ssl/mssl.crt/ca.crt zu erseten
9. Falls man die client.crt und client.key braucht, muss man die (wenn man 4. beachtet hat) aus /usr/syno/etc/ssl/mssl.crt und /usr/syno/etc/ssl/mssl.key verwenden.

Bei mir übersteht dieses vorgehen auch einen Serverneustart.
Der Webserver läuft weiterhin unter dem anderen Zerifikat bei mir RapisSSL.

 

[DRIV3R]

Hi Mausbieber,

danke für deine ausführliche Antwort und die Idee für eine Problemlösung.
Ich glaube aber, dass ich warten werden, bis Synology einen Fix für 2414 raus bringt.
Ich will mich eigentlich nicht so tief ins System einarbeiten, nur um mein VPN zum laufen zu bekommen.
Ich denke, Synology hat mit dem VPNCenter schon eine sehr gute Lösung gebaut, sofern diese funktionieren würde. Das hat mit 2412 ja auch einwandfrei funktioniert.
Ich werde am WE noch einmal testen, ob ich per Terminal meine importierten Zertifikate raus kopieren kann, damit ich mein Zertifikat mit nem OpenVPN Client nutzen kann, und ich nicht immer dieses doofe intermediate ZwischenZertifikat exportiert bekommen.

Verstehe nur nicht, wieso Synology sich zu dem Bug nicht äußert, bzw. ich dieses Mal keine Support Antwort bekommen.

Trotzdem danke für deine Mühe.

Gruß
Timo

 

[7ynolge]

Danke für die Antworten. Vielleicht bin ich ja ein wenig unvorsichtig.

Mir ist nicht ganz schlüssig, warum die Attacke so tief im System drin sein soll, und trotz Update und Passwortänderung, ich nicht in der Lage sein sollte fremde Zugriffe im Protokoll zu sehen.

Egal, ich habe jetzt ein neues Zertifikat ausgestellt und exportiert.

Dann habe ich noch meine Domain eingetragen, und auf meinem iphone eingespielt.

Danach reboot der Syno.

Vorher habe ich zur Sicherheit mich mit dem Altem einwählen wollen. Was natürlich nicht ging.

Mit dem Neuem klappt jetzt alles wieder.

Jetzt sollte mein VPN Tunnel wieder sicher sein. Die Anleitung von Mausbieber habe ich übrigens nicht gebraucht.

Viele Grüsse

 

[mausbieber]

Hallo 7ynologe,
Es freut mich, dass es bei Dir geklappt hat. Das Problem besteht ja auch nicht bei selbstausgestellten Zertifikaten, sondern bei fremdzertifizierten. Meine Anleitung ermöglicht die Verwendung der fremdzertifizierten Zertifikate für den Nas außer OpenVpn. Hierfür wird mittels der Anleitung quasi das ursprüngliche selbstausgestellte Zertifikat des NAS neu generiert aber wo anders abgelegt und die Verweise der OpenVpn Installation auf diese umgebogen.

 

[Frogman]

...Mir ist nicht ganz schlüssig, warum die Attacke so tief im System drin sein soll, und trotz Update und Passwortänderung, ich nicht in der Lage sein sollte fremde Zugriffe im Protokoll zu sehen.
...

Ich weiß nicht, wer die Beschreibung "tief im System" aufgebracht hat, sie mag auch ein wenig verwirren. Beim Heartbleed-Bug handelt es sich um ein grundsätzliches Verhalten der betroffenen OpenSSL-Versionen, auf gewisse Anfragen zu antworten - das Problem tritt damit bei allen verschlüsselten Verbindungen des betreffenden Servers auf, ist damit also "tief im System".
Beim beschriebenen Verhalten geht es um sog. Heartbeat-Anfragen (deswegen auch Heartbleed für den Bug) eines Clients, die dafür sorgen sollen, dass eine einmal etablierte SSL-Session aufrechterhalten wird, um nicht bei jeder weiteren Anfrage des Clients erneut das Handshaking durchführen zu müssen. Diese Kommunikation zwischen Client und Server wird eben nicht geloggt, so dass Du später dazu keine Spuren auf dem Server findest. Unter Umständen lassen sich auffällige Pakete nur durch Filter im Datenstrom einer Firewall o.ä. nachvollziehen.

 

[7ynolge]

Wo ist der Vorteil bei fremdausgestellten Zertifikaten?

 

[mausbieber]

Vielleicht sollte man eher von fremdsigniert sprechen. Der Vorteil ist, dass man beim Webzugriff mittels https bzw. Bei anderen SSL/TSL Verbindungen keine Meldung wegen einer nicht beglaubigen Verbindung bekommt, man kann in solchem Fall nicht sicher sein, ob sich einer zwischen dem Zielserver und dem Client gehängt hat. Ich würde bei keinem Shop kaufen der nur ein selbstsigniertes Zertifikat hat. Für den Privatgebrauch kann es reichen, die Verbindung wird genauso verschlüsselt, wie bei fremdsignierten Zertifikaten, dies ist die Hauptsache. Es bleibt ebend dass kleine Restrisiko. Für die Fremdzertifizierung gibt es entsprechende Zertifizierungsstellen z.B. StartSSL, RapidSSL...