Jump to content

https Website für Media Server?


pib751

Recommended Posts

1 hour ago, MaM said:

Dazu muss man dem Browser (oder Betriebssystem) das Stammzertifikat der eigenen Zerfizierungsstelle beibringen, danach akzeptieren sie auch die ausgestellten Clientzertifikate ohne Murren.

Mit einem "einsamen self signed cert" stehst Du demnächst im Regen, wie Du richtig erkannt hast, wird es viele tausend Firmen hart treffen und ihnen viel Geld kosten um teuere Leute anzuheuern, die ihre Kisten wiederbeleben.

Ich versteh das Problem nicht. Die Firmen arbeiten einfach weiter wie bisher, weil die das alles jetzt schon betreiben. Die importieren einfach per policy auf jedem Rechner das Root Zertifikat.

Was auch immer du mit einem "einsamen self signed cert" meinst, jedem steht frei sich eine CA selbst zu erstellen und diese dann zu verwenden.

Du machst hier einfach Probleme wo keine sind, um https sicher zu betreiben ändert sich nix.

Link to comment
Am 2.10.2019 um 11:49 schrieb Griga:

Das Streamen von Dateien via HTTPS klappt ebenfalls, aber nicht das Live Streaming.

 

Der war übel >_< Die SSL/TLS-Implementation in der ICS Netlib ist nicht threadsicher, und ein Stream aus einer Live-Quelle kommt natürlich in einem separaten Thread einher. Da knallt es dann an allen Ecken und Enden, und man muss erst mal darauf kommen, woran es liegt. Da ich mich nicht berufen fühle, den SSL-Teil der Netzwerkbibliothek neu zu schreiben, bleibt nur, TV/Radio-Puffer im (Haupt-)Anwendungsthread auszuliefern, was etwas Synchronisation mit dem Streaming-Thread erfordert, der den Puffer füllt. Programmtechnisch nicht schön, aber machbar - in der Hinsicht bin ich ja Kummer gewöhnt. Kurz gesagt ist jetzt der gesamte Webserver HTTPS-fähig.

 

Zum selbst-signierten (oder von wem auch immer) Zertifikat: Zur Zeit habe ich hier drei Dateien namens 01cert.pem, 01key.pem und cacert.pem provisorisch im SVCweb-Ordner untergebracht. In der SSLContext-Datenstruktur muss ich alle drei angeben. Ist das immer so ein Dreierpack oder kann das variieren?

 

Link to comment

Das cacert.pem ist das Zertifikat deiner CA.

Der Dreierpack ist schon ok, könnte aber auch evtl ohne das cacert.pem file gehen.

 

In den DVBViewer clients sollte es jetzt reichen nur das cacert.pem irgendwie deiner netlib beizubringen und die Verbindung müsste als sicher akzeptiert werden.

Wenn das so klappt könntest du schon alle http kommunikation zwischen DVBViewer clients und DMS auf https umstellen.

 

Aber für ein Release solltest du nicht die dummy Zertifikate verwenden ?

Link to comment
vor 28 Minuten schrieb Griga:

Zum selbst-signierten (oder von wem auch immer) Zertifikat: Zur Zeit habe ich hier drei Dateien namens 01cert.pem, 01key.pem und cacert.pem provisorisch im SVCweb-Ordner untergebracht. In der SSLContext-Datenstruktur muss ich alle drei angeben. Ist das immer so ein Dreierpack oder kann das variieren?

 

Das variiert eigentlich weniger, Du hast da 2 verschiedene Zertifikate vor Dir, die nur geringfügig mit einander zu tun haben...

 

cacert.pem ist das Zertifikat der Stammzertifizierungsstelle (deshalb "ca..."). Die Datei enthält den öffentlichen Schlüssel derselben. Normalerweise brauchst Du diese Datei NICHT, bzw. sie ist Teil des Browsers oder Betriebssystems. Deine gelbe Meckerwarnung stammt daher, dass sie eben nicht dort ist, sondern Du sie hier einfach rumliegen lässt.

 

01cert.pem ist der öffentliche Schlüssel für Deinen Srver. Er wurde ausgestellt von der obigen "ca". Deshalb verweist er als Kette auf cacert.pem und ist nur zusammen mit ihr gültig.

Er dient zum ENTschlüsseln Deiner Daten.
Dieser Schlüssel kann beliebig weitergegeben werden (was automatisch passiert beim TLS Handshake)

 

01key.pem ist der private Schlüssel für Deinen Server. Er dient zum VERschlüsseln Deiner Daten und wird niemals weitergegeben. Die Datei ist auch üblicherweise noch mit einem Passwort geschützt (für den Serverbetrieb jedoch seeehr hinderlich, deshalb kann man auch nach viel Abbitte diese Datei OHNE Passwort erzeugen lassen). Auch hier ist natürlich ein Bezug auf cacert.pem

 

 

Die Grundidee aller Zertifkate ist:

 

* es gibt bekannte Stammzertifizierungsstellen, denen alle vertrauen

* ein Klientenzertifikat (in diesem Falle das Deines Servers) besteht aus zwei Teilen, einem öffentlichen, den jeder kennen darf und der nur zum ENTschlüsseln dient und einem privaten, der bei Dir verbleibt und zum VERschlüsseln benutzt wird.

* die Gültigkeit eines Zertifikates wird überprüft, indem man die Stammzertifizierungsstelle überprüft (die kann auch sogenannte Revoke Listen führen und damit ausgestellte Zertifkate vorzeitig ungültig machen) und die Laufzeit überprüft.

 

Dein Problem besteht darin, dass niemand Deine cacert.pem kennt. Dadurch kannst Du zwar die schönsten und gültigstens Zertifikate für Deinen Server haben, aber niemand akzeptiert sie.

@VinoRosso schlägt vor, das cacert fest mit im DVBViewer unterzubringen. Das wäre theoretisch machbar, aber dann wäre er auch die einzige Applikation, die davon Nutzen hätte. Ich betrachte das als großen Fehler.

 

Was Du machen kannst, ist bei der Installation sowas mit einzubauen (Auszug aus meiner automatischen Windows Installation)

rem unser Stammzertifikat hinzufuegen
echo *** Stammzertifikat einfuegen...
certutil -addstore "Root" "%SYSTEMDRIVE%\Werries\SETUP\MRootCA.cer"
echo :

 

Du packst das cacert.pem irgendwo hin und importierst es mit certutil in den Stammpfad jedes Rechners. Damit werden davon abgeleitete Zertifikate dann gültig.

 

Für Firefox musst Du allerdings noch in die Config mit aufnehmen:

lockPref("security.enterprise_roots.enabled", true);

Das sorgt dafür das Firefox nicht nur seinen eigenen Zertspeicher nimmt, sondern den vom Betriebsystem mitverwendet.

 

 

Edited by MaM
Link to comment

@Griga

wenn du das cacert.pem in Windows importierst sollte Chrome die Verbindung nicht mehr mit dem gelben Ausrufezeichen versehen.

Firefox benutzt seinen eigenen Speicher da muss man das wieder extra machen.

 

Sollte per Google leicht zu finden sein wie das in Windows funktioniert ?

Edited by VinoRosso
Link to comment

@MaMDas die Zertifikate vom user austauschbar sein müssen hatte ich schon zu Beginn geschrieben. Trotzdem muss ein default ausgeliefert werden, nicht jeder user will sich damit rumschlagen.

Link to comment

ach ja, noch 2 Ergänzungen für Griga:

 

1) es gibt auch die Variante, wo beide (öffentlicher+privater) Schlüssel in einer einzigen Datei sind, der Klient gibt dann immer nur den öffentlichen Teil automatisch weiter

 

2) solltest Du wirklich die cacert.pem mitverteilen und installieren lassen wollen, so achte bitte darauf, dass sie eine lange Lebensdauer hat. 50 Jahre sind üblich für CAs (auch wenn das unlängst zu erheblichem Stress geführt hat, als ein schwarzes Schaf totgelegt werden sollte und es keine einfache Möglichkeit gab, das CACert für ungültig zu erklären...)

 

3) die Klientenzertifikate dürfen allerdings nicht so lange laufen, sonst mag sie niemand. Deshalb darfst Du dann alle 2 Jahre neue generieren und bei den Updates mit ausliefern lassen...

 

Link to comment

Danke für die Erläuterungen :)

 

vor 5 Stunden schrieb VinoRosso:

Der Dreierpack ist schon ok, könnte aber auch evtl ohne das cacert.pem file gehen

 

Geht auch ohne, gerade probiert.

 

vor 5 Stunden schrieb MaM:

01key.pem ist der private Schlüssel für Deinen Server. Er dient zum VERschlüsseln Deiner Daten und wird niemals weitergegeben. Die Datei ist auch üblicherweise noch mit einem Passwort geschützt

 

In der Codevorlage (ein minimaler Beispiel-Server) war "password" als Passwort vorgegeben. Kann ich aber auch aus dem SSLContext streichen. Die von mir verwendeten .pem-Dateien sind hier im Unterordner Samples\Delphi\SslInternet\ des ICS 8.62 Downloads zu finden. Dort gibt es eine Reihe weitere .pem-Dateien, die ich mir noch nicht angeschaut habe.

 

vor 5 Stunden schrieb VinoRosso:

In den DVBViewer clients sollte es jetzt reichen nur das cacert.pem irgendwie deiner netlib beizubringen und die Verbindung müsste als sicher akzeptiert werden.

 

Nicht nötig. Die Synapse Netlib und der DVBViewer akzeptieren bei Live Streams ohnehin alles, was kommt - siehe hier. Ein Problem ist eher, dass der DVBViewer als Client für das Streamen von TS Dateien (Aufnahmen) die WinInet-Schnittstelle verwendet (also quasi die Codebasis des Internet Explorers), die sich nicht überreden lässt, das selbstsignierte Zertifikat zu akzeptieren, obwohl ich schon alle SECURITY_FLAG_IGNORE_XXX und INTERNET_FLAG_IGNORE_XXX gesetzt habe. Als Folge scheitert das Herstellen der Verbindung, so dass der DVBViewer die Datei nicht mit dem DVBViewer Filter verarbeiten kann. Deshalb landet die Angelegenheit schließlich beim LAV Sourcefilter als Fallback, der es (wahrscheinlich auf FFmpeg-Basis) hinkriegt, ohne die Vertrauenswürdigkeit zu prüfen.

 

Die Frage, die sich mir jetzt stellt, ist: Was sollte für den Anwender in den DMS-Optionen für HTTPS mit dem Webserver konfigurierbar sein? Es sollte flexibel, aber nicht zu kompliziert werden. Sollte er Dateipfade zum Zertifikat/zum Schlüssel festlegen können? Bislang habe ich nur provisorisch einen Tweak für den HTTPS Port vorgesehen, Standard 0 (HTTPS deaktiviert) und ihn  hier auf 8088 konfiguriert, was funktioniert.

 

Link to comment
vor 9 Minuten schrieb Griga:

Geht auch ohne, gerade probiert.

Das ist ein Denkfehler. Das CA cert muss einmalig importiert werden. Wahrscheinlich hast Du das irgendwann mal gemacht (wider besseres Wissen?). Es wird im Betriebsystem und/oder im Browserstore permanent gespeichert. Deshalb ist klar, dass Du es nun nicht mehr brauchst.

 

vor 11 Minuten schrieb Griga:

Die Frage, die sich mir jetzt stellt, ist: Was sollte für den Anwender in den DMS-Optionen für HTTPS mit dem Webserver konfigurierbar sein? Es sollte flexibel, aber nicht zu kompliziert werden. Sollte er Dateipfade zum Zertifikat/zum Schlüssel festlegen können? Bislang habe ich nur provisorisch einen Tweak für den HTTPS Port vorgesehen, Standard 0 (HTTPS deaktiviert) und ihn  hier auf 8088 konfiguriert, was funktioniert.

Also:

* es muss ein Zertifikat auswählbar sein. Die Idee mit dem direkten Pfad finde ich nicht sehr prickelnd. Die Auswahl sollte aus dem normalen Zertifikatsspeicher erfolgen (da gibts Dialoge für). Der User soll selber zusehen, mit welchen Standardtools er das da reinbekommt (Tipp: "certutil" ist Dein Freund...)

* Das Port sollte natürlich auch auswählbar sein, wobei dafür gesorgt sein muß, dass der User nicht das "normale" HTTP Port doppelt belegen kann. Zur Sicherheit sollte man vielleicht noch checken, ob auf der Kiste ein Standard Webserver auf Port 80/443 sein Unwesen treibt und diese dann auch der möglichen Auswahl entziehen.

* wenn Du wirklich selbstsignierte Zerts zulassen und ausliefern willst, musst Du natürlich auch die Tools mitliefern, um diese zu erzeugen...

 

(wegen dem letzten Punkt würde ich an Deiner Stelle davon Abstand nehmen, sonst lieferst Du einen ganzen OpenSSL Port mit aus... Sollen die Leute selber an ihre Zertifikate kommen und sie dann hier einstellen. Es ist nicht Dein Job die Dinger auch mitzuliefern)

 

Link to comment
Gerade eben schrieb MaM:

Wahrscheinlich hast Du das irgendwann mal gemacht (wider besseres Wissen?).

 

Habe ich nicht gemacht. Ich habe nur https://127.0.0.1:8088 in Firefox zugelassen. Und jetzt ohne cacert.pem-Bezug probiert, was Chrome macht. Es funktioniert nach dem Zulassen, wenn auch nur so:

 

Zwischenablage02.png

 

Link to comment

Du unterliegst irgendwie einem permanenten Denkfehler ?

Du hast nicht "127.0.0.1:8088" zugelassen, sondern das dort ausgelieferte Zertifikat.

Wobei die IP Adresse selber gar nicht gültig ist, in dem Zertifikat steht ein (DNS) Name (oben, unterstrichen) es können auch noch Alternativname ("SAN Certificate") enthalten sein, im Beispiel im roten Kasten.

Die Webseite muss mit einem dieser Namen übereinstimmen, sonst findet jeder Browser sie anrüchig.

 

(Du profitierst im Moment vom Sonderstatus von "localhost", das funktioniert aber auch nur lokal... Du solltest für Deine Tests schon eine andere Kiste über LAN benutzen, sonst legst Du Dir nur selber Fallen...)

 

Beispiel.jpg

Link to comment
vor 14 Stunden schrieb MaM:

Du unterliegst irgendwie einem permanenten Denkfehler ?

Du hast nicht "127.0.0.1:8088" zugelassen, sondern das dort ausgelieferte Zertifikat.

 

Vielleicht besser, wenn der Theoretiker es ausprobierst, bevor er solche Behauptungen in die Welt setzt. :)Firefox verlangt die Genehmigung pro Site. Ich muss die Genehmigung für https://localhost:8088 mit dem selben Zertifikat wie zuvor erneut erteilen.

 

vor 14 Stunden schrieb MaM:

Du solltest für Deine Tests schon eine andere Kiste über LAN benutzen, sonst legst Du Dir nur selber Fallen...

 

Wieso? Wenn ich das DMS Mobil-Webinterface auf einem Android Tablet mit Firefox via https://[Webserver-IP]:8088/ios aufrufe,  kommt die gleiche Warnung. Ich sehe da keinen Unterschied. Das Zertifikat wird überall auf gleiche Weise als nicht vetrauenswürdig angesehen, und ich kann überall trotzdem die Genehmigung erteilen. Der IE fasst z.B. die verschiedenen Zertifikatfehler, die ich aus dem WinInet API kenne, nur zu einer pauschalen Anzeige "Zertifikatfehler" zusammen. Um was für Unstimmigkeiten es sich genau handelt, ersparen die Browser dem Anwender.

 

Link to comment
vor 1 Stunde schrieb Griga:

und ich kann überall trotzdem die Genehmigung erteilen

Eigentlich war meine initiale Warnung "DAS WIRD NICHT MEHR SO LANGE FUNKTIONIEREN!" vergiss das nicht.

Du reitest ein totes Pferd, sattel lieber vorher um.

 

Link to comment

Das erinnert mich an den Propheten, der zu Vista-Zeiten bekanntgab, die nächste Windows-Version (also Windows 7) würde die Ausführung von 32-Bit-Anwendungen nicht mehr unterstützen, womit der DVBViewer weg vom Fenster wäre. :D Oder an den, der das Überleben des DVBViewers ohne explizite Unterstützung von 3D-TV-Sendungen für unmöglich hielt. Weltuntergangs-Wahrsagerei  dieser Art gab es in den letzten 17 Jahren massenweise im Forum.

 

Ist aber auch egal. Wie bereits gesagt befindet sich die HTTPS-Angelegenheit zur Zeit in einer experimentellen Phase, in der es keine Rolle spielt, was in einem oder zehn Jahren los ist. Eine Festlegung auf selbstsignierte Zertifikate ist in keinem Fall geplant. Warum auch? Der DMS soll nur die grundsätzlichen (generischen) Voraussetzungen für die Verwendung von HTTPS mitbringen. Insofern betreibst du hier sinnfreie Schwarzmalerei und unterstellst Vorhaben, die überhaupt nicht bestehen. Besinne dich lieber auf deine fachliche Kernkompetenz.

 

Link to comment
vor einer Stunde schrieb Griga:

Verwendung von HTTPS mitbringen. Insofern betreibst du hier sinnfreie Schwarzmalerei und unterstellst Vorhaben, die überhaupt nicht bestehen. Besinne dich lieber auf deine fachliche Kernkompetenz.

Ich mal da nix Schwarz. les mal die Ankündigungen von FireFox und Chrome für die nächsten Releases...

 

aber egal, sorg nur dafür, dass man ein https port einstellen kann und irgendwie ein Zertifkat zuweisen kann (wobei "irgendwie" bei einem reinen Windows Programm dann wohl die Benutzung des Windows Zertifikatsspeicher bedeutet). Dann ist Dein Job zu diesem Thema voll erledigt.

 

Link to comment
vor 10 Stunden schrieb MaM:

Dann ist Dein Job zu diesem Thema voll erledigt.

 

Nein. Dir fehlt der Überblick, was alles im DVBViewer-/DMS-Kontext damit verbunden ist. Fortschritte gibt es jetzt erst mal beim DVBViewer:

  • Er kann jetzt vom DMS gelieferte TS-Dateien mit HTTPS-URLS über den DVBViewer Filter abspielen, auch wenn das Zertifikat selbstsigniert oder sonstwie "schräg" ist. Das ging vorher nur mit dem LAV Sourcefilter (siehe vorherige Posts zu dem Thema). Mir ist es jetzt gelungen, die WinInet-Schnittstelle entsprechend zu frisieren.
  • Unter Optionen -> DVBViewer Media Server kann man festlegen, dass die Kommunikation zwischen DVBViewer und DMS (genauer gesagt: mit dem DMS API) mittels HTTPS verschlüsselt ablaufen soll. Dazu braucht man der Adresse in der Eingabezeile nur ein https:// voranstellen. Bislang war hier keine Protokollangabe vorgesehen. Fehlt sie, wird aus Kompatibilitätsgründen http:// angenommen. Zum Einsatz kommt hier dvbviewerseits die Synapse Netlib, der die Vertrauenswürdigkeit von Zertifikaten egal ist.

Das heißt aber noch lange nicht, dass der DVBViewer als DMS-Client mit durchweg TLS-verschlüsselter Kommunikation dienen kann. Alles was bei der Kommunikation über andere Protokolle als HTTP läuft, bleibt außen vor:

  • Die vom DMS via UDP Multicast an DVBViewer Clients verbreiteten Botschaften (z.B. wenn sie ihre Timer- oder Aufnahmelisten aktualisieren sollen).
  • TV via Sat>IP.  Eine Transportverschlüsselung ist im Standard nicht vorgesehen. Ich wüsste auch nicht, dass es sie bei RTSP gibt. Wer also will, dass der DVBViewer nur via HTTPS mit dem DMS kommuniziert, muss eine HTTPS-Senderliste in den Senderlisten-Editor importieren. Das funktioniert bereits soweit. Ein Senderlisten-Download aus dem Webinterface liefert automatisch eine M3U mit HTTPS URLs, wenn das Webinterface über HTTPS aufgerufen wird.
  • Die automatische Erkennung von DMS-Instanzen im Netzwerk und ihrer Adressen:Ports. Sie läuft über UPnP, d.h. UDP Multicast. Der DVBViewer erhält auf diese Weise eine description.xml und liest darin die vom Server angegebene Presentation URL (= URL des Webinterface). Damit kennt er auch IP und Port des DMS API. Die Presentation URL kann man jedoch in diesem Kontext schlecht auf HTTPS umstellen, weil sich ihrer vielleicht Geräte bedienen, die kein HTTPS können. Kurz gesagt wird deshalb einem automatisch erkannten DMS immer eine HTTP-Adresse zugeordnet, die man manuell in den Optionen mitsamt dem dazugehörigen Port auf HTTPS umschreiben muss, wenn man das braucht. Ändern ließe es sich nur mit einem proprietären zusätzlichen Eintrag in der description.xml, die die HTTPS-Adresse des Webinterface angibt.
  • Der Media Server Wizard. Er bietet keine Adresseingabe, sondern setzt nur auf automatische Erkennung und konfiguriert deshalb den Kontakt zum DMS immer mit einer HTTP-Adresse.

 

Link to comment
vor 32 Minuten schrieb Griga:

Nein. Dir fehlt der Überblick, was alles im DVBViewer-/DMS-Kontext damit verbunden ist. Fortschritte gibt es jetzt erst mal beim DVBViewer:

Dann ändere mal den Titel des Threads. Was Du da alles willst, hat nix mehr mit "https-website-für-media-server" zu tun.

 

Du solltest Dich mal ruhig zurücklehnen und überlegen, was davon überhaupt jemals zum Tragen kommen könnte.

 

Alles, was auf UDP basiert, kann nicht TLS verschlüsselt werden, da TLS eine Session vorraussetzt und keinen Paketverlust verkraftet. Also vergiß Sat-IP, UPnp und Multicastkram. DAS GEHT NICHT!

 

Um URLs zu übermitteln bietet sich einfach eine Zweitanwort an. Ein "anderer" DMS antwortet auf die Anfrage des Klienten und liefert die HTTPs URLs (auch unter anderem Namen) aus. So sieht es für den Klienten aus, als existierten ZWEI Server, ein "DMS-normal" und ein "DMS-verschlüsselt". Der Klient/Anwender kann dann selber aussuchen, mit welchem er reden will.

 

(womit sich Dein Wizzard Problem gleich mitgelöst hat, sofern der eine Auswahl des Zielservers anbietet)

 

Guck mal hier, was die VLC Entwickler von Deinen Ideen halten: https://forum.videolan.org/viewtopic.php?t=147135

("not useful" ist noch die harmloseste Beschreibung ?)

 

Edited by MaM
Link to comment
7 minutes ago, MaM said:

Guck mal hier, was die VLC Entwickler von Deinen Ideen halten: https://forum.videolan.org/viewtopic.php?t=147135

("not useful" ist noch die harmloseste Beschreibung ?)

 

36 minutes ago, Griga said:

Das heißt aber noch lange nicht, dass der DVBViewer als DMS-Client mit durchweg TLS-verschlüsselter Kommunikation dienen kann. Alles was bei der Kommunikation über andere Protokolle als HTTP läuft, bleibt außen vor:

 

Für mich hört sich das jetzt nicht so schwachsinnig an ?

Link to comment
vor 40 Minuten schrieb VinoRosso:

Für mich hört sich das jetzt nicht so schwachsinnig an ?

Das kommt drauf an, was er damit meint:

 

a) die genannten Punkte gehen nicht und werden nicht angepackt -> OK

b) die genannten Punkte gehen NOCH nicht und er arbeitet dran -> sinnlos

 

Seine Aussage kann man so oder so interpretieren...

Edited by MaM
Link to comment
vor 2 Stunden schrieb VinoRosso:

Für mich hört sich das jetzt nicht so schwachsinnig an ?

 

MaM will mir gerne Dinge erklären, die mir bereits klar sind, Maßnahmen ausreden, die ich gar nicht vorhabe und Fragen beantworten, die sich mir nicht stellen :)Jetzt habe ich aber wirklich eine Frage.

 

Zwecks Praxiserfahrung habe ich mir die Aufgabe gestellt, ein selbstsigniertes Zertifikat zu erzeugen. Das hat soweit gemäß diesen Anleitungen geklappt:

 

http://root.bbs-duew.de/ca/OpenSSL-Windows-Zertifikat-Erstellung.htm

https://www.thenativeweb.io/blog/2017-12-29-11-51-the-openssl-beginners-guide-to-creating-ssl-certificates/

http://wiki.cacert.org/FAQ/subjectAltName

 

Ich hatte etwas Probleme mit der OpenSSL Konfigurationsdatei für die Certificate Signing Request, weil alle Welt voraussetzt, man hätte sie bereits, habe dann aber hier ein brauchbares Exemplar gefunden, das ich modifizieren konnte:

 

https://jamielinux.com/docs/openssl-certificate-authority/appendix/root-configuration-file.html

 

Jedenfalls konnte ich so eine privatekey.pem, certificate.pem und ca.pem erzeugen. Jetzt möchte ich das Root-Zertifikat auf anderen PCs in meinem Netzwerk importieren, so dass das HTTPS DMS Webinterface von den Browsern klaglos akzeptiert wird. Dabei spielt ja der Common Name (CN) eine wichtige Rolle, oder inzwischen eher gemäß dem Hinweis von @waldi801 der Subject Alternative Name. Dafür wird i.a. ein Domainname angegeben. Aber was gebe ich in meinem Heimnetz an? Der Server PC hat hier ja keinen Domainnamen, oder? Kann ich ersatzweise 192.168.xxx.xxx:8088 nehmen?

 

Link to comment
vor 2 Minuten schrieb Griga:

Dabei spielt ja der Common Name (CN) eine wichtige Rolle, oder inzwischen eher gemäß dem Hinweis von @waldi801 der Subject Alternative Name. Dafür wird i.a. ein Domainname angegeben. Aber was gebe ich in meinem Heimnetz an? Der Server PC hat hier ja keinen Domainnamen, oder? Kann ich ersatzweise 192.168.xxx.xxx:8088 nehmen?

So langsam kommst Du zu den Problemen, vor denen ich Dich die ganze Zeit bewahren wollte....

 

Die Antwort ist schlichtweg: NEIN!

 

Da gehört nur ein Name rein.  Adressen haben da nix zu suchen, Portnummern noch weniger (das Port wird eh nirgendwo überprüft).

 

Ohne Domäne wirds schwierig, Du kannst den NETBIOS Namen nehmen, sofern der Klient im LAN ein Chance hat, ihn aufzulösen.

 

CN und SAN sind additiv, beide werden zum Vergleich rangezogen. Der CN ist meist Teil der SAN Liste (hättesse aus meinem Screenshot erraten können, aber was solls).

 

Wie Du unschwer erraten kannst, macht "localhost" wenig Sinn, es muss schon ein richtiger Name sein. Deshalb ist es langsam unerlässlich, einen richtigen DNS Server zu betreiben, DynDNS einzusetzen oder sich sonstwo einen gültigen Namen zu geben.

 

Zur Not dann auch mit internen Adressen. Mach mal "ping mamvcr.dyndns.tv" und wundere Dich, wofür das gut sein könnte...

 

 

Link to comment
vor 37 Minuten schrieb MaM:

Du kannst den NETBIOS Namen nehmen, sofern der Klient im LAN ein Chance hat, ihn aufzulösen.

 

Danke, das scheint durchweg zu funktionieren. Ich habe probeweise in DMS URLs die IP durch den Computernamen ersetzt, der ja dem NetBios-Namen entspricht, oder? Firefox, DVBViewer, LAV Sourcefilter sowie Firefox auf einem Android Tablet können das auflösen.

 

vor 41 Minuten schrieb MaM:

CN und SAN sind additiv, beide werden zum Vergleich rangezogen.

 

Habe ich gerade im Web anders gelesen. CN wird ignoriert, wenn SAN vorhanden, weil nur letzterer RFC-konform ist. Oder anders gesagt: CN wird nur aus Kompatibilitätsgründen beachtet (außer von Chrome), wenn es nicht anders geht.

 

vor 43 Minuten schrieb MaM:

So langsam kommst Du zu den Problemen, vor denen ich Dich die ganze Zeit bewahren wollte....

 

Nichts ist so lehrreich wie Probleme... :)

 

Link to comment
vor 2 Stunden schrieb Griga:

Habe ich gerade im Web anders gelesen. CN wird ignoriert, wenn SAN vorhanden, weil nur letzterer RFC-konform ist. Oder anders gesagt: CN wird nur aus Kompatibilitätsgründen beachtet (außer von Chrome), wenn es nicht anders geht.

Du musst nicht alles glauben, was Du irgendwo liest ?

Sonst würde es ja mit den NETBIOS Namen auch nicht klappen dürfen, denn die sind nun wirklich nicht RFC konform.

(was aber richtig ist: der CN darf ein einzelner (NETBIOS) Name sein, in den SAN Einträge sollte man nur volle DNS Namen finden)

 

vor 2 Stunden schrieb Griga:

durch den Computernamen ersetzt, der ja dem NetBios-Namen entspricht

Der Computername IST der Netbios Name. Allerdings können Nicht-Windows Geräte damit natürlich auch nix anfangen...

Wenn Du also mit Händies usw rumspielen willst, landest Du doch wieder bei "richtigen" DNS Namen.

 

Deshalb der Tipp mit dem (externen) DynDNS Eintrag der eine interne Adresse liefert. Den können ALLE auflösen, aber nur die Leute im LAN auch erreichen.

 

Link to comment
vor 28 Minuten schrieb MaM:

Allerdings können Nicht-Windows Geräte damit natürlich auch nix anfangen...

 

Hatte ich nicht oben geschrieben, dass Firefox unter Android das kann? Chrome übrigens ebenso.

 

vor 28 Minuten schrieb MaM:

Deshalb der Tipp mit dem (externen) DynDNS Eintrag der eine interne Adresse liefert.

 

Keine Ahnung, wie das geht, und keine Lust und Zeit, mich damit auch noch zu befassen. Persönlich brauche ich den Kram nicht. Nur kurzfristig als Testszenario. Danach wird es nur noch angefasst, wenn Debugging nötig ist. Ich probiere es erst mal ohne. Wenn das nicht reicht, werde ich es ja merken. Höre bitte auf zu drängeln.

 

Habe ich das jetzt richtig verstanden, dass es genau drei Konfigurationsmöglichkeiten in den DMS-Optionen geben muss? HTTPS Port, Server Key und Server-Zertifikat?

 

Link to comment

Etwa so:

 

Zwischenablage02.png

 

Zwischenablage01.png

 

Braucht das nicht eventuell noch ein Passwort, falls das Zertifikat verschlüsselt ist? Oder macht man das nur beim Root Zertifikat?

 

Ich glaube, die Pfade speichere ich lieber in der svcuserdata.xml, sonst tauchen die in den hier angehängten support.zips auf ;)

 

 

Link to comment

Warum fragst Du eigentlich, wenn die Antworten alle schon gegeben wurden, und/oder sie Dir nicht gefallen?

 

Dein Zertifikat ist FALSCH! mach ein neues, mit den richtigen Parametern!

 

a) beide Schlüssel in eine Datei (dann brauchst Du nur einen Pfad bei den Eingabefelder)

b) ohne Passwort

c) CN=NetBios Name, SAN mit DNSName[n]

 

Stöber mal weiter in Deinen Dokus bis Du die richtigen Parameter gefunden hast... Google ist sicherlich Dein Freund ?

 

Ob die Pfade in irgendwelchen Logs auftauchen ist völlig irrelevant. Nur der Inhalt der Datei ist wichtig, und den wirst Du ja wohl kaum mit ins Log kopieren wollen, oder?

 

Link to comment
vor 2 Stunden schrieb MaM:

Du musst nicht alles glauben, was Du irgendwo liest ?

 

Vor allem in deinen Posts ;)

 

vor 6 Stunden schrieb MaM:

Da gehört nur ein Name rein.  Adressen haben da nix zu suchen,

 

https://security.stackexchange.com/questions/160787/ip-address-in-subjectaltname

https://tools.ietf.org/html/rfc5280#section-4.2.1.6

 

Zitat

The subject alternative name extension allows identities to be bound
   to the subject of the certificate.  These identities may be included
   in addition to or in place of the identity in the subject field of
   the certificate.  Defined options include an Internet electronic mail
   address, a DNS name, an IP address, and a Uniform Resource Identifier
   (URI). 

 

Ich recherchiere mal lieber selbst...

 

Link to comment

Firefox macht das jetzt nach Import des Stammzertifikats und

 

[alt_names]
DNS.1 = msi-win7-64
DNS.2 = localhost
IP.1 = 192.168.xxx.xxx
IP.2 = 127.0.0.1

 

klaglos mit allen angegebenen Namen und Adressen:

 

Zwischenablage01.png

 

aber in Chrome (ebenfalls nach Stammzertifikat-Import) keine Chance. Es wird noch nicht mal das Zulassen angeboten. Das Server-Zertifikat ist ungültig und damit basta. Das Web ist voll von Berichten anderer, die daran gescheitert sind, und von HInweisen, was man in dem Fall machen soll, was aber hier alles nicht funktioniert... da trifft sich ein extrem restriktiver Browser mit den kaum zu durchschauenden Konfigurations-Optionen von OpenSSL. Ein absolut anti-intuitives Linux-Gewächs von Nerds für Nerds und sonst niemand.

 

Immerhin kann ich in Chrome unter Android (ohne Stammzertifikat-Import) die oben abgebildete Adresse nach einer Warnung zulassen, aber das ist auch eine etwas ältere Version des Browsers.

 

Link to comment
vor 45 Minuten schrieb Griga:

aber in Chrome (ebenfalls nach Stammzertifikat-Import) keine Chance. Es wird noch nicht mal das Zulassen angeboten. Das Server-Zertifikat ist ungültig und damit basta. Das Web ist voll von Berichten anderer, die daran gescheitert sind, und von HInweisen, was man in dem Fall machen soll, was aber hier alles nicht funktioniert... da trifft sich ein extrem restriktiver Browser

Heute Chrome, morgen Firefox (und Edge usw...) WARUM GLAUBST DU MIR EIGENTLICH NICHT???

Du sitzt auf einem Ast, der abgesägt wird, mit jedem Update ein Stückchen mehr...

 

Der Browser kann übrigens mit dem cacert wenig bis gar nix anfangen (es liegt da nur ungenutzt rum, Ausnahme: Firefox ohne Config Änderung). Du mußt stattdessen einen beherzten Doppelklick auf die Datei machen und einen Import ins Betriebssystem durchführen. "Ort automatisch wählen" sollte funktionieren, im Zweifelsfall (also bei Dir ?) den Ort manuell auswählen und in "Stammzertifizierungsstellen" packen lassen.  Alle Browser (ausser Firefox ohne Tritt) gucken hier rein und akzeptieren nur CAs aus diesem Speicher!

(und vergiss endlich diese OpenSSL Dokus, die sind für Linux und haben nur seehr begrenzte Relevanz auf Windows)

 

Edited by MaM
Link to comment
vor 2 Stunden schrieb MaM:

WARUM GLAUBST DU MIR EIGENTLICH NICHT???

 

Ich halte deine Angaben nicht für vertrauenswürdig, ebensowenig wie Chrome mein selbstgebautes Server-Zertifikat. :) Zu viele deiner Behauptungen haben sich als falsch herausgestellt. Man kann sich  bei dir nicht mal auf das Gegenteil verlassen, weil manchmal schreibst du ja auch was richtiges. Also der Worst Case, sozusagen. Ich könnte ebensogut eine Münze werfen.

 

vor 2 Stunden schrieb MaM:

Du mußt stattdessen einen beherzten Doppelklick auf die Datei machen und einen Import ins Betriebssystem durchführen.

 

Habe ich probiert, nützt bei Chrome auch nichts. Du glaubst ja gar nicht, was ich schon alles probiert habe. Ich denke, es liegt an der OpenSSL -Konfiguration bei der Erzeugung der Zertifikate. Das selbstsignierte Zertifikat, das der Netlib beiliegt, nimmt Chrome ja an, wenn auch widerstrebend.

 

vor 2 Stunden schrieb MaM:

und vergiss endlich diese OpenSSL Dokus, die sind für Linux und haben nur seehr begrenzte Relevanz auf Windows

 

Diese Behauptung ist mal wieder gründlich falsch. Der Inhalt der OpenSSL-Konfigurationsdateien unterscheidet sich überhaupt nicht, und die Kommandoparameter sogar noch weniger :)

 

Link to comment
vor 15 Minuten schrieb Griga:

Das selbstsignierte Zertifikat, das der Netlib beiliegt, nimmt Chrome ja an, wenn auch widerstrebend.

 

...und dabei ist es noch schlechter als meines, weil es kein subjectAltName enthält.

 

Aber gerade habe ich herausgefunden, was Chrome an meinem Zertifikat stört: Es ist ja nicht selbstsigniert, sondern mitttels CA-Zertifikat, das auch von mir stammt und wirklich selbstsigniert ist! Chrome stellt also fest, da garantiert jemand, dem Chrome nicht vertraut, die Echtheit des Server-Zertifikats. Und das ist offenbar schlimmer als ein von vornherein nicht vertrauenswürdiges Server-Zertifikat. Nicht mal der Import dieses CA-Zertifikats kann Chrome beschwichtigen.

 

Jetzt fragt sich nur noch, ob Chrome das grundsätzlich so sieht oder ob die OpenSSL-Konfiguration bei der CA-Zertifikat-Erzeugung nicht stimmt.

 

Link to comment
vor 2 Stunden schrieb Griga:

Diese Behauptung ist mal wieder gründlich falsch. Der Inhalt der OpenSSL-Konfigurationsdateien unterscheidet sich überhaupt nicht, und die Kommandoparameter sogar noch weniger

Ich hab nicht von den Konfigurationen oder den Kommandozeilenparametern geredet. Es ist einfach so , dass Windows eine eingebaute Zertifikatsverwaltung hat, und sich openssl einen Dreck darum schert. Also reden die beiden aneinander vorbei. Klar, die Zertifikate sind dieselben, auch der Inhalt. Es ist aber entscheidend WO sie abgelegt werden!

 

vor 2 Stunden schrieb Griga:

Aber gerade habe ich herausgefunden, was Chrome an meinem Zertifikat stört: Es ist ja nicht selbstsigniert, sondern mitttels CA-Zertifikat, das auch von mir stammt und wirklich selbstsigniert ist!

Wie oft muss ich noch runterbeten, dass Du das CA Zertifikat in Windows imortieren mußt ???

Dort ist der einzige, als "legal" betrachtete Speicherort für diese Dinger.

Danach wird auch Chrome das Klientenzertifikat schlucken, allerdings immer mit Warnung.

 

(und auch nur bis zum 20.8.2020 wie ich eben gelesen habe. An dem Tag schaltet Let'sEncrypt das Cross Signing ab und bis dahin werden dann alle Browser den eigenen Kram ablehnen/ignorieren.)

 

Edited by MaM
Link to comment
vor 2 Stunden schrieb MaM:

Wie oft muss ich noch runterbeten, dass Du das CA Zertifikat in Windows imortieren mußt ???

 

Schon wieder falsch. So langsam kann man sich auf deine Aussagen verlassen :D

 

Wie auch immer - Chrome ist jetzt auch glücklich:

 

Zwischenablage02.png

 

Haben es alle mitbekommen? Ihr könnt dem DVBViewer Media Server eure Passwörter und Kreditkartennummern anvertrauen. Oder auch gleich mir und Christian, das läuft auf das gleiche hinaus... :)

 

Es fehlte tatsächlich nur eine verdammte Zeile in einer der OpenSSL-Konfigurationsdateien. Danach zeigte der Import des Stammzertifikats in Chrome  (oder auch in Windows, geht beides) Wirkung. Alle für den DMS als subjectAltName angegebenen Domainnamen und IP-Adressen gelten nun in Chrome als sicher. Man kann in Chrome übrigens auch ein selbst-signiertes Server-Zertifikat als "vertrauenswürdige Stammzertifizierungstelle" mit gleicher Wirkung importieren, ohne dass irgendwo ein CA-Zertifikat im Spiel ist. Firefox lässt das leider nicht zu und verweigert schon den Import (falscher Zertifikatstyp).

 

Fazit dieser tagelangen Session: Es besteht jetzt die Möglichkeit, zukünftigen Media Server Releases Standard-Zertifikate und einen Schlüssel beizulegen, so dass Anwender HTTPS nutzen können, ohne sich mit OpenSSL das Gehirn verrenken zu müssen. Nur die Konfiguration in den Media Server-Optionen sowie der Zertifikats-Import in die Browser oder auch in Windows ist dann noch zu bewerkstelligen.

 

Edited by Griga
Falsche Aussage gestrichen, s.u.
Link to comment
vor 27 Minuten schrieb Griga:

Es besteht jetzt die Möglichkeit, zukünftigen Media Server Releases Standard-Zertifikate und einen Schlüssel beizulegen

 

Oder auch nicht. Das geht ja praktisch nur für localhost, weil da individuelle Domainnamen / IP-Adressen rein müssen. Ich bin von den ganzen Zertifikaten inzwischen auch schon ganz wirr im Kopf (wenn auch nicht so schlimm wie MaM :)) .... aber egal. Irgendwas werden wir uns einfallen lassen, das die Sache erleichtert.

 

Link to comment
vor 2 Stunden schrieb Griga:

Oder auch nicht. Das geht ja praktisch nur für localhost, weil da individuelle Domainnamen / IP-Adressen rein müssen. Ich bin von den ganzen Zertifikaten inzwischen auch schon ganz wirr im Kopf (wenn auch nicht so schlimm wie MaM :))

Gääähn.... ?

Im Gegensatz zu Deinem planlosen Chaos da, funktioniert der Kram hier ohne Meckern, ohne Handarbeit, auf allen Betriebssystemen, mit allen Browsern... Die Leute merken gar nichts davon, dass sie Zertifikate verabreicht bekommen und die Kommunikation verschlüsselt ist (na gut, ich gebe zu, bei Android ab 8.0 gibts etwas Stress. Das will dann nur noch im "Hochsicherheitsmodus" starten und gibt bei jedem Boot eine Warnung aus, dass da "unbekannte Zertifizierungsstellen" installiert wurden. Ist aber egal, es passiert nichts und die Nachricht kommt nur einmal nach jedem Reboot)

Aber ich sagte ja gleich: "Lernen durch Schmerzen" (nirgendwo anders findet man so lange Sackgassen, ohne Warnung am Eingang)

Link to comment
On 10/6/2019 at 10:21 PM, MaM said:

Gääähn.... ?

Im Gegensatz zu Deinem planlosen Chaos da, funktioniert der Kram hier ohne Meckern, ohne Handarbeit, auf allen Betriebssystemen, mit allen Browsern... Die Leute merken gar nichts davon, dass sie Zertifikate verabreicht bekommen und die Kommunikation verschlüsselt ist (na gut, ich gebe zu, bei Android ab 8.0 gibts etwas Stress. Das will dann nur noch im "Hochsicherheitsmodus" starten und gibt bei jedem Boot eine Warnung aus, dass da "unbekannte Zertifizierungsstellen" installiert wurden. Ist aber egal, es passiert nichts und die Nachricht kommt nur einmal nach jedem Reboot)

Aber ich sagte ja gleich: "Lernen durch Schmerzen" (nirgendwo anders findet man so lange Sackgassen, ohne Warnung am Eingang)

Das hier aber von 2 völlig unterschiedlichen Dingen die Rede ist kapierst du einfach nicht. Du hast einfach nen Proxy server davor über den du auf den DMS zugreifst. Und das gilt nur für die Website, um auch verschlüsselte Kommunikation zwischen den clients zu ermöglichen hilft das rein gar nichts, da stört dein Browser blabla gelaber einfach nur.

 

Das DMS Zertifikat müsste egtl bei der Installation generiert werden und der user müsste den hostnamen dabei angeben

 

 

Link to comment
vor 1 Stunde schrieb VinoRosso:

Das hier aber von 2 völlig unterschiedlichen Dingen die Rede ist kapierst du einfach nicht.

Ich schon, ihr offensichtlich nicht. Das Thema (Reverse) Proxy war ja schon lange abgehakt.

 

Mir ist schon klar, dass es nun direkt gehen soll, aber euch noch nicht, dass es SO nie gehen wird.

 

Es darf kein Zertifikat generiert werden, der User muß sich das "woanders" her besorgen. Jede Installation ist anders, es wird euch nicht gelingen auch nur 20% der möglichen Fälle abzudecken. "Automatik" hat hier nix zu suchen.

 

Die Ideen sind zwar löblich, aber vergebens, denn jeder will was anderes drinstehen haben...

 

Link to comment
vor 3 Stunden schrieb VinoRosso:

Das DMS Zertifikat müsste egtl bei der Installation generiert werden und der user müsste den hostnamen dabei angeben

 

Der Hostname müsste dann einer OpenSSL-Konfigurationsdatei hinzugefügt werden. Das Problem dabei: Ich weiß immer noch nicht genau, welchen Regeln sie folgt, obwohl sie hier inzwischen macht, was sie soll, und ich problemlos per Hand IP-Adressen und Domainnamen hinzufügen kann. Ein automatisches Hinzufügen müsste die Datei jedoch auch lesen, um zu sehen, was schon drinsteht. Es wäre ja blöd, bei jeder Installation den Domainnamen erneut abzufragen und der Datei hinzuzufügen. Das erhöht den Aufwand beträchtlich.

 

Was ich bislang zusammengestellt habe:

  • Konfigurationsdateien, die standardmäßig nur localhost und 127.0.0.1 (quasi als Vorlage) enthalten. Da müsste der Anwender zunächst per Texteditor eingreifen.

[alt_names]
DNS.1 = localhost

DNS.2 = ...
IP.1 = 127.0.0.1

  • Eine Batch-Datei, die mittels OpenSSL cakey.pem, cacert.pem, serverkey.pem und servercert.pem in einem neuen Unterordner Certificates des DMS-Installationsordners erzeugt und abschließend zur Kontrolle den Inhalt von servercert.pem im Klartext anzeigt (also nicht als Hex-Wüste). Der DMS benutzt die serverkey.pem und servercert.pem aus dem Certificates-Unterordner standardmäßig, sofern man nicht in den Optionen -> Web Einstellungen etwas anderes bestimmt.
  • Eine Batch-Datei, die sich mit cacert.pem in einem gemeinsamen Verzeichnis des Client-PCs befinden muss, das CA Zertifikat dem Windows Store hinzufügt und Firefox veranlasst, es beim nächsten Start seinem Store ebenfalls hinzuzufügen (per Registry Key, womit ich noch nicht so ganz glücklich bin).

Das erleichtert die Sache beträchtlich, aber so richtig schön ist es noch nicht ;) Demnächst wird es erst mal als interne Version zur Verfügung stehen. Dann hätte ich gerne eine Beurteilung von dir und eventuell auch anderen Betatestern.

 

Link to comment
vor 11 Stunden schrieb MaM:

Mir ist schon klar, dass es nun direkt gehen soll, aber euch noch nicht, dass es SO nie gehen wird.

 

Das erinnert mich an einen Fachmann, der uns vor ein paar Jahren erzählte, dass WebM als Format für Live TV Streaming nicht geeignet wäre. Das könne so nicht gehen. Es handelte sich nicht um einen Möchtegern-Fachmann mit etwas Halbwissen, sondern um jemand, der in der Technik einer großen Medienanstalt arbeitete. Bei seinen Kenntnissen war es für in klar, dass man sowas gar nicht probieren braucht. Das war auch nicht von der Hand zu weisen. WebM ist ein Format, das Google für seine Zwecke von MKV abgeleitet hat - bekanntermaßen ein Datei-Containerformat.

 

Nur - zu dem Zeitpunkt lief die WebM-TV-Wiedergabe in Chrome und Firefox mit dem damaligen Recording Service bereits bestens. Ich hatte es implementiert, um von Flash wegzukommen. Hätte der Fachmann ein halbes Jahr früher seine Meinung kundgetan, hätte ich ihm womöglich geglaubt, und der Media Server wäre immer noch auf das ab 2020 nicht mehr verfügbare Flash für TV-Wiedergabe in Desktop-Browsern festgenagelt.

 

Link to comment

...nur das wir hier nicht von irgendwelchen Modeerscheinungen reden, sondern von genormten Dingen...

 

Mach, was Du willst, aber "beglücke" uns auf keinen Fall automatisch mit dem Mist!

Nicht bei Installation oder Update ein Zertifikat generieren und auch noch direkt auf die Welt loslassen!

Es gibt (zum Glück) reichlich Leute, die sowas bereits haben und nur einspielen müssen.

Und die wissen, wie es geht und wie es auszusehen hat.

 

(und die anderen, um die Du Dich sorgst, wissen eh nix damit anzufangen und brauchen es überhaupt nicht)

 

 

 

 

 

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...