Die Sache dabei ist allerdings, dass der 600SeriesAndroidUploader eine https Verbindung haben möchte.
Ohne diese, kann ich die Daten vom Contour Next Link nicht an Nightscout schicken.
Ich probiere schon seit 2 Tagen rum und komme auf keinen grünen Zweig...
Ich weiß nicht wirklich, ob es so geht (ich benutze LetsEncrypt mit meiner richtigen Domain), aber ich würde folgendes probieren:
Dann müsste es hoffentlich mit der HTTPS-Verbindung funktionieren.
Die Idee ist gut, das könnte funktionieren!
Also ich bin aktuell soweit, dass ich das Self Signed Certificate habe.
Ich habe in meinem Pi-Hole einen DNS Server Eingerichtet, der mir z.b. 192.168.10.135 auf nightscout.local übersetzt.
In der Nginx Konfiguration habe ich nun das drin:
https://pastebin.com/0R2VLinP
Wenn ich jetzt https://nightscout.local/ in den Browser eingebe, komme ich auf die Seite von Nginx wo steht
nginx/1.14.0 (Ubuntu)
Füge ich am Ende der Adresse noch den Port 1337 hinzu kommt folgendes:
Fehler: Gesicherte Verbindung fehlgeschlagen
Beim Verbinden mit nightscoutvp.local:1337 trat ein Fehler auf. SSL hat einen Eintrag erhalten, der die maximal erlaubte Länge überschritten hat.
Fehlercode: SSL_ERROR_RX_RECORD_TOO_LONG
Scheint ja schon ein Schritt weiter zu sein, aber so richtig funktioniert es noch nicht. 
Das erste, was mir auffällt, ist, dass deine Namen in der nginx-Konfiguration (nightscoutkp.local) nicht identisch sind mit dem vorher genannten nightscout.local. Der Server_Name im Webserver muss identisch sein zum Domain-Namen des Zertifikats. Funktioniert also nicht, wenn das Zertifikat nightscout.local enthält, der Servername dann aber anders heißt.
Auf Port 1337 dürfte es auch nicht funktionieren, weil dein nginx darauf ja gar nicht lauscht. Ich vermute, 1337 ist der Port deiner Nightscout-Instanz? Ich habe bei mir (allerdings in Apache, nicht Nginx), die entsprechende Weiterleitung von Port 443 auf den Nightscout-Port mit ProxyPass konfiguriert. Ich gehe also immer auf den normalen HTTPS-Port.
Also ich habe da oben nur das "kp" vergessen im Text. Im Aufruf geht es nicht.
Ja 1337 ist der Port der Nightscout Instanz.
Gehe ich ohne S auf die Webseite, also http://nightscoutkp.local:1337 erreiche ich die Seite und alles läuft.
Nehme ich https://nightscoutkp.local sagt mir der Browser, dass die Seite nicht vertrauenswürdig ist, was bei einem Selbstsigniertem Zertifikat normal ist.
Akzeptiere ich das, kommt der 404 Fehler von nginx.
Füge ich den Port 1337 hinten dran, kommt der Error:
Fehler: Gesicherte Verbindung fehlgeschlagen
Beim Verbinden mit nightscoutvp.local:1337 trat ein Fehler auf. SSL hat einen Eintrag erhalten, der die maximal erlaubte Länge überschritten hat.
Fehlercode: SSL_ERROR_RX_RECORD_TOO_LONG
Ich vermute, dass irgendwas mit der Serverkonfiguration nicht passt.
Nach deiner derzeitigen Konfiguration leitet er von Port 443 ja noch nicht zu Nightscout weiter, sondern soll nur die index-Datei in dem entsprechenden Verzeichnis anzeigen. Liegen denn in /var/www/nightscoutkp.local/html überhaupt eine der Dateien index.html oder index.htm oder index.nginx-debian.html? Wenn nicht, ist das 404 ja normal.
Der SSL_ERROR... auf Port 1337 sagt eigentlich nur, dass dort keine SSL-Verbindung erstellt werden kann. Du kannst wohl in dem node.js für Nightscout auch SSL einrichten (SSL_KEY, SSL_CERT, SSL_CA). In dem Fall bräuchte man die Nginx-Brücke eigentlich gar nicht, sondern würde direkt mit ssl über den Port 1337 gehen.
Genau kann ich es dir aber auch nicht beschreiben, weil ich tatsächlich nur von außen auf Port 443 vom Apache mit SSL gehe und das ProxyPass dann unverschlüsselt mache (INSECURE_USE_HTTP=true), was ich für unkritisch halte, weil die Nightscout-Ports bei mir von außerhalb des Pi gar nicht erreichbar sind.
Was die Meldung beim Browser bezüglich des unsicheren Zertifikats angeht: das kannst du eliminieren, indem du das Zertifikat im Browser zu den sicheren Zertifikaten importierst.
Auf dem Smartphone mit AndroidAPS würde ich davon ausgehen, dass man das Zertifikat in den Android-Einstellungen importieren muss, damit AndroidAPS die Verbindung als sicher akzeptiert. Bei mir ist das unter "Biometrische Daten und Sicherheit:Andere Sicherheitseinstellungen:Von USB-Speicher installieren:CA-Zertifikat". Aber das ist ja auf den Smartphones sehr unterschiedlich. Mit der Suche in den Einstellungen sollte aber bestimmt etwas zu "CA-Zertifikat" zu finden sein.
Wenn dein Self-Signed-Certificate da importiert ist, sollte es eigentlich auf dem Gerät für alle Apps als vertrauenswürdiges Zertifikat gelten.
Ich habe das jetzt bei mir mal ausprobiert.
Das INSECURE_USE_HTTP in meinem Nightscout-Startskript habe ich weggenommen, meinen Nightscout-Port nach außen sichtbar gemacht und im Nightscout-Startskript die Umgebungsvariablen SSL_CA und SSL_CERT auf mein Chain-Zertifikat (bei dir müsste es das selbst signierte Zertifikat sein) und SSL_KEY auf den Private Key zeigen lassen (dazu muss der User, der Nightscout startet, natürlich Zugriff auf die Dateien haben). Damit funktioniert auch die SSL-Verbindung zum direkten Nightscout-Port einwandfrei.
Ich könnte dir leider nur Apache-Konfigurations-Zeilen präsentieren. Ich weiß nicht, ob dir das was für Nginx bringt...
Danke für die Mühe.
Ich habe den Webserver mitlerweile hinbekommen auf https.
Er ist jetzt unter https://nightscoutkp.local/ erreichbar im Browser.
Jetzt macht aber noch das Uploader Handy blöd.
Der 600SeriesAndroidUploader für die Minimed 640g sagt da nun noch: Unable to resolve host "nightscoutkp.local": No address associated with hostname.
Vorher war es immer "java.security.cert.CertPathValidatorException: Trustanchor for certification path not found"
Die Konfiguration vom nginx sieht wie Folgt aus:
Erst dachte ich auch ich brauche die Zertifikate irgendwie auf dem Handy, aber scheinbar ist das jetzt ein anderes Problem?
Bei meinem alten Heroku Server habe ich nur die Herokuapp.com Adresse eingegeben "https://name.herokuapp.com"
Der 600SeriesAndroidUploader für die Minimed 640g sagt da nun noch: Unable to resolve host "nightscoutkp.local": No address associated with hostname.
Das sieht erstmal nach einem reinen Namensauflösungsproblem aus. Ich würde die hosts-Datei auf dem Smartphone mit dem 600SeriesAndroidUploader mit dem nightscoutkp.local-Eintrag ergänzen. Dann sollte das Problem schon mal weg sein.
Ich würde auf dem 600SeriesAndroidUploader-Smartphone auf jeden Fall das Zertifikat in den Android-Einstellungen importieren. Ansonsten wird es für die HTTPS-Verbindung sicherlich nicht als vertrauenswürdig angesehen und der 600SeriesAndroidUploader wird die Werte dann wohl doch nicht in Nightscout schicken.
Ich weiß nicht wirklich, ob es so geht (ich benutze LetsEncrypt mit meiner richtigen Domain), aber ich würde folgendes probieren:
- Einen Phantasie-FQDN benutzen (sowas wie "Nightscout.MeisterQ.de"), diesen FQDN auf allen beteiligten Geräten in der localhost-Datei mit der IP deines Nightscout-Gerätes auflösen, falls das nicht über einen von dir verwendeten DNS im VPN geht.
- Ein Self-Signed-Certificate mit diesem FQDN erstellen.
- Das Self-Signed-Certificate bei allen beteiligten Geräten in die Liste der vertrauenswürdigen Root-Certificates importieren.
- Das Self-Signed-Certificate zusätzlich in die Webserver-Konfiguration auf dem Nightscout-Gerät aufnehmen.
Dann müsste es hoffentlich mit der HTTPS-Verbindung funktionieren.
Oder innerhalb des VPN per DHCP nen DNS liefern der diese Addressen innerhalb des VPNs auflöst
Außer natürlich das wäre zu hart zu implementieren. Aber dann könnte man auch einen LetsEncrypt Domainnamen nehmen und alles ist konfigurationsfrei.
Ja scheinbar. Über die IP komme ich vom Smartphone auf die NS Seite per https, per Name aber nicht. In der Uploaderapp sagt er mir mit Namen No address associated, mit IP sagt er mit Port 1337 hinten dran Handshake failed, und ohne Port CertPathValidatorException.
Wie funktioniert das mit dem Zertifikat? Aus dem Verzeichniss vom Server holen und aufs Smartphone kopieren und dann unter Zertifikate hinzufügen?
Ich hab mir ein Pi-Hole eingerichtet und den im DHCP Server als DNS Server eingestellt und dort einen Manuellen DNS Eintrag zwischen der IP und dem Namen erstellt.
Scheint trotzdem nicht gescheit zu funktionieren.
Ich verzweifel langsam und bin kurz davor weiterhin für heroku zu bezahlen
Ich wollte hier nochmal ein Feedback geben wie ich das ganze jetzt gelöst habe:
Nightscout läuft als LXC Container auf Proxmox unter Port 1337.
Jeder Container hat seine eigene IP.
Ich habe einen DYNDNS Dienst genommen und habe im nginx Server ein Letsencrypt-Zertifikat auf die DYNDNS Adresse erstellt.
In meinem Router habe ich jetzt eine Portweiterleitung von den Lokalen IP Adressen der LXC Contrainer mit Port 1337 auf einen Externen Port der DYNDNS Adresse.
So erreiche ich unter 2 Ports und meiner DYNDNS Adresse die 2 NS Instanzen meiner beiden Kinder.
Der 600 Series Uploader ist damit sehr zufrieden und alles läuft Problemlos.
Danke an eure Hilfe und großes dank an Michael Schlömp für die Anleitung und Hilfe bei Facebook!
Mit dem Eco Abo bei heroku wäre ich im leben nicht über den Monat gekommen.
Nach nur 5 Tagen hatte ich schon 10% Nutzung voll.
Bei Fragen gerne Kontaktieren, dann poste ich gerne auch meine Serverkonfiguration und versuche zu helfen
Wie kann ich auf dem RasPI Nighscout aktualisieren ? habe das noch Nightscout 14.2.2 drauf
Wie kann ich auf dem RasPI Nighscout aktualisieren ? habe das noch Nightscout 14.2.2 drauf
Wie hast du es installiert? Als Container, manuell?
Manuell auf dem Pi4 wie hier am Anfang beschrieben
Manuell auf dem Pi4 wie hier am Anfang beschrieben
Hab die Beschreibung jetzt nicht gefunden, egal.
Wenn du es als git heruntergeladen hast (per "git clone"), dann musst du nur ein "git pull" machen.
Falls du NSv15 brauchst/willst dann ist das aktuell der dev Branch, also nach dem pull noch "git checkout dev" machen.
Wenn du es statt per git als Zip heruntergeladen hast, dann einfach die neue Zip runterladen und die Dateien überschreiben.
Ich habe ja immer gern ein Fallback und mache bei Nightscout immer ein neues Verzeichnis, das ich dann verlinke. Wenn was nicht funktioniert, biege ich den Link wieder auf's alte Verzeichnis. Das sieht im Moment so bei mir aus:
Mit anderen Worten: ich mache immer ein "git clone" im neuen Versions-Verzeichnis und setze dann den cgm-remote-monitor Link auf das neue Verzeichnis. Meine beiden Start-Skripte, die die Umgebung entsprechend setzen (ns_alina.sh und ns_ulf.sh) benutzen nur den Link. Wenn der Link wieder auf's alte Verzeichnis zurückgesetzt wird, läuft es also wie vorher im Problemfall.
Nach dem git clone war dann noch das npm install im neuen Versions-Verzeichnis notwendig (das müsste man nach einem update aber selbst im alten Verzeichnis ja wohl auch machen, oder?). Muss aber zugeben, ich mache es so selten, dass ich mich nicht mehr an alle Einzelheiten erinnere.