Hier tauschen wir uns über alles aus, was das System selbst betrifft und kein eigenes Unterforum hat. Also Login, Nutzerverwaltung, Bedienung, Menüstruktur, OS-Updates usw.
Forumsregeln
Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln
Ich habe mit einer App timberwolf407.local und timberwolf407 angepingt. Bei .local braucht die erste Antwort immer ca. 4-5s. Ohne .local kommt die Antwort schneller.
Wo sehe ich denn welche URLs im Zertifikat hinterlegt sind? Sind das die unter „Subject Alt Names" in dem Screenshot oben?
Stefan: Danke nochmals für deine Zusammenfassung, genau diese drei punkte habe ich mit Julian bereits geklärt (siehe von Julian gepostete Screenshots), und von den Einstellungen her ist alles korrekt erledigt. Das Zertifikat ist heruntergeladen und installiert. Die Einstellung zum Vertrauen des Zertifikats ist erledigt, und der Zugriff auf den TWS erfolgt über den korrekten Namen (=ergo Namensauflösung scheint zu funktionieren, sonst wäre die Fehlermeldung keine Zertifikatsmeldung sondern dass gar keine Verbindung aufgebaut werden kann).
Allerdings: die Ausgabe des Zertifikats in den letzten Screenshots zeigt, dass das Gerät dem Zertifikat trotzdem nicht vertraut. Das wird durch das kleine rote X auf den Zertifikatsnamen angezeigt. Das sollte da eigentlich nicht sein. Genau das ist definitiv die Ursache dafür, dass es nicht funktioniert.
Laut den Screenshots, sowohl von iPad als auch iPhone, ist das "Volles Vertrauen für Rootzertifikate" für die "Timberwolf Web CA" aktiviert, und trotzdem ignorieren die beiden Geräte dieses.
Das einzige was ich mir im Moment Vorstellen kann, ist irgend eine zusätzliche Sicherheitssoftware die das unterbindet. Hast du irgendwas auf deinen Geräte in dieser Richtung installiert?
Nur um die Namensauflösung nochmals ganz sicher 100%ig auszuschließen: Installiere mal noch die App "Ping - network utility" und gib dort oben "timberwolf407.local" ein. Wenn die Namensauflösung funktioniert bekommst du anschließend im Abstand von einer Sekunde ein grünes Viereck gefolgt von der IP-Adresse des TWS sowie der Zeit die der TWS zum Antworten benötigt hat.
Geht die Namensauflösung nicht, sollte sofort die Meldung "Can't resolve host" erscheinen.
VG
Earl
Wiregate#1504 + PBM Timberwolf 950Q #233
Timberwolf 3500XL #1459 + PBM/ VPN aktiv / Reboot OK
EFH mit KNX, 1-Wire, DMX, MQTT (RTC PV, OpenWB, AWtrix, OpenDTU), HTTP API (Tibber)
Docker: MQTT Broker, Unifi WLAN Controller, NodeJS, CometVisu
ah, du warst schneller und hast schon genau gemacht was ich von dir wollte während ich es geschrieben hab
Namensauflösung funktioniert also definitiv.
Du kannst den Zugriff wie von Dante vorgeschlagen mal noch versuchen, man soll ja nichts unversucht lassen, aber es erschließt sich mir gerade technisch nicht, warum das gehen sollte und timberwolf407.local nicht, während die Namensauflösung hierfür jedoch funktioniert.
ja, die gültigen Hostnamen stehen unter Subject Alt Names im Zertifikat.
VG
Earl
Zuletzt geändert von EarlBacid am Do Feb 13, 2020 1:47 pm, insgesamt 1-mal geändert.
Wiregate#1504 + PBM Timberwolf 950Q #233
Timberwolf 3500XL #1459 + PBM/ VPN aktiv / Reboot OK
EFH mit KNX, 1-Wire, DMX, MQTT (RTC PV, OpenWB, AWtrix, OpenDTU), HTTP API (Tibber)
Docker: MQTT Broker, Unifi WLAN Controller, NodeJS, CometVisu
Was beim Pingen auffällig ist, ist das es bei timberwolf407.local nach dem Starten des "Pingvorgangs" ca 4-5s dauert, bis die erste Antwort kommt (dort steht dann allerdings trotzdem 20-30ms als Antwortzeit). Bei timberwolf407 oder timberwolf407.fritz.box ist das nicht der Fall.
Wenn ich allerdings timberwolf407 oder timberwolf407.fritz.box im Safari verwende meldet Safari "Diese Verbindung ist nicht privat", also auch mal wieder ein Hinweis auf ein ungültiges Zertifikat, nur mal wieder in anderer Form.
Zuletzt geändert von JulianD am Do Feb 13, 2020 2:06 pm, insgesamt 1-mal geändert.
Okay, von dem her bin ich mir sicher, dass wir das Thema Namensauflösung abhaken können.
Bleibt dementsprechend nur das Thema Vertrauensstellung. Wie deine Screenshots zeigen, sind die Einstellungen zwar korrekt, aber der Screenshot vom Zertifikat zeigt trotzdem, dass der CA nicht vertraut wird. Dieses Problem gilt es aufzulösen, wobei ich hier allerdings mit meinem Latein am Ende bin, da wie gesagt deine Einstellungen hierzu korrekt sind.
Hast du irgend eine Sicherheitssoftware, Virenscanner, zentrales Management (MDM) auf den Geräten? Irgend etwas muss es geben, was auf deinen Geräten in die (Zertifikats-)Suppe spuckt.
VG
Earl
Wiregate#1504 + PBM Timberwolf 950Q #233
Timberwolf 3500XL #1459 + PBM/ VPN aktiv / Reboot OK
EFH mit KNX, 1-Wire, DMX, MQTT (RTC PV, OpenWB, AWtrix, OpenDTU), HTTP API (Tibber)
Docker: MQTT Broker, Unifi WLAN Controller, NodeJS, CometVisu
Ach ja, habe ich vorher vergessen zu schreiben.
Nein, ich hab keinerlei Sicherheitssoftware, Virenscanner oder sowas auf meinen Geräten. Vor allem das iPad ist noch relativ "naturbelassen". Das einzige etwas komplexere was ich an meinen Geräten konfiguriert (außer einfache Apps zu installieren) habe ist die Familienfreigabe. Allerdings wüßte ich nicht, dass ich damit irgendwelche Beschränkungen aktiviert habe...
Anforderungen an vertrauenswürdige Zertifikate in iOS 13 und macOS 10.15
Hier erhalten Sie Informationen zu den neuen Sicherheitsanforderungen an TLS-Serverzertifikate in iOS 13 und macOS 10.15.
Alle TLS-Serverzertifikate müssen in iOS 13 und macOS 10.15 die folgenden neuen Sicherheitsanforderungen erfüllen:
TLS-Serverzertifikate und ausstellende Zertifizierungsstellen, die RSA-Schlüssel verwenden, müssen Schlüsselgrößen größer oder gleich 2048 Bit verwenden. Zertifikate mit RSA-Schlüsselgrößen kleiner als 2048 Bit werden für TLS nicht mehr als vertrauenswürdig angesehen.
TLS-Serverzertifikate und ausstellende Zertifizierungsstellen müssen im Signaturalgorithmus einen Hash-Algorithmus aus der SHA-2-Familie verwenden. SHA-1-signierte Zertifikate sind für TLS nicht mehr vertrauenswürdig.
TLS-Serverzertifikate müssen den DNS-Namen des Servers in der SAN-Erweiterung (Subject Alternative Name) des Zertifikats angeben. DNS-Namen im CommonName eines Zertifikats sind nicht mehr vertrauenswürdig.
Darüber hinaus müssen alle nach dem 1. Juli 2019 ausgestellten TLS-Serverzertifikate (wie im NotBefore-Feld des Zertifikats angegeben) den folgenden Richtlinien entsprechen:
TLS-Serverzertifikate müssen eine ExtendedKeyUsage (EKU)-Erweiterung enthalten, die die "id-kp-serverAuth OID" enthält.
TLS-Serverzertifikate müssen eine Gültigkeitsdauer von 825 Tagen oder weniger haben (wie in den Feldern "NotBefore" und "NotAfter" des Zertifikats angegeben).
Verbindungen zu TLS-Servern, die gegen diese neuen Anforderungen verstoßen, schlagen fehl und können Netzwerkausfälle und das Fehlschlagen von Apps verursachen. Außerdem ist es möglich, dass Websites in Safari in iOS 13 und macOS 10.15 nicht geladen werden.
Die letzte Neuerung ist, dass Zertifikate mit Ausstellungsdatum nach dem 1.7.2019 (trifft bei dir zu) nicht mehr länger als 825 Tage gültig sein dürfen. Die von Elabnet für die Wölfe ausgestellten Zertifikate sind jedoch 20 Jahre lang gültig und entsprechend somit nicht diesen Anforderungen und werden als nicht Vertrauenswürdig eingestuft, selbst wenn der CA (für die diese Beschränkung nicht gilt) vertraut wird.
Dementsprechend spiele ich den Ball hier mal an @StefanW rüber, da du daran nichts ändern kannst.
Diese Entscheidung ist übrigens vom CAB Browserforum als verbindliche Richtlinie bereits vor 2 Jahren entschieden worden, und auch davor waren es 39 Monate ab 2015 und 60 Monate seit 2011. Es ist also nur eine Frage der Zeit, bis andere Browser ebenfalls nachziehen, und die Vertrauenswürdigkeit ebenfalls an diesem Parameter festmachen.